QA初心者をお迎えするときに気をつけていること

2002年に社会人としてデビューしていろんな業種業界を渡り歩いてきました。
その経験から言えることなんですが、QAという職種はIT業界では「入り口」になりやすいんですよね。

で、その入り口で自分に関わった方には「ソフトウェアテスト」という仕事で食べていけるようになって欲しいと思っています。

日頃、気をつけていることをバーっと書き出してみました。
説教くさくなりましたが、何かのご参考になれば！

ソフトウェアテストに必要なこと

システムテストでスキルを磨く

• バグへの感度を上げる
  • 経験ベースのテスト観点を増やす
    • 「私個人」の値段を上げて欲しいと思います。
    • 見たことのあるバグ、テストしたことのある類似機能、、、全部あなただけの経験です。
  • ありがちな観点（標準的な観点）だけでも抑える
    • ベテランQAは、テキストボックスを見たら入力すべき文字が反射的に浮かぶと思います。これが「ありがちな観点」です。
• テスト技法を習得してほしい
  • まずは同値分割と境界値分析だけで良い
    • AとBは同じコンポーネントの使い回しだから、Aだけ入念に見れば良い…etc,
  • 同値と境界値は、他の様々なことに応用の効く考え方なので、まずはこれだけでも！
  • 習得した技法を使って上流のレビューを行う
    • 「シフトレフト」が業界の主流になっていますが、テスト技法が使えないまま参画してもあまり意味はありません。上流での「システムを動かさないテスト」のためにはやはり技法が必須です。行き当たりばったりの「感想」に終始しないことが大事。
  • 優秀なQA＝論理的にケースを削れる（先人達が開発した「技法」という巨人の肩の上に立って仕事する）
• ユーザーの利用パターンを知る（想像する）
  • 複数端末（ゲームのガチ目なユーザー）
  • 弱い回線（東京ドーム5万人が一斉にスマホ使う）
  • 途中で離脱（LINEきたり、飽きたりする）…etc,
• プロダクトドメインを好きになる
  • 「自分なら、こう使う」の引き出しを増やすことが大事
    • 余談）私は現場に行ってみて、そこで使ってみる。周囲の人の動きを観察するなど、プライベートで自腹でやっています。そこまでする必要はないですが…良いものを作りたい思いから、そういう動きをすることが多いです。

チェックとテストの違いは理解したい

チェック

• 仕様書に書いてあることを確認する
• 仕様書「〜〜であること」▶︎ ケース「〜〜であること」をなぞって確認する
  • この仕事は、数年でAIや自動化にほとんどの仕事を奪われると思います。
• 開発者に安心感を与えることができる
  • 自信を持って次の機能開発に進めるので、開発生産性向上に寄与できる
  • 受け入れテスト基準を作る（スモークテスト）ことで、重要なチェック項目を確認して、「大丈夫でしたよ」「重要なユーザーストーリーにバグありました」を早くフィードバックしたいですね

テスト（QAの価値）

• 影響ありそうなのに、仕様書に書いていないことを見つける
  • テストは「仕様にないこと」を見つけるお仕事と言っても過言ではないくらい大事
• プロダクトの問題点を探索する
• テスト設計技法を駆使する
  • 観点ツリー、CFDなど
• テストアプローチを駆使する
  • リスクベースド、欠陥ベース、経験ベース、シナリオテスト…etc,

教育時のソフトスキル

相手に届く言葉を使う

• 製品の価値（「こんな人が喜ぶ」などユーザーの解像度を上げる）を涵養する
• 「作った人」を意識してもらう
  • 大人の事情で出来ないことが多いのを理解してもらう
  • 「バグ出た！やった！」をオブラートに包んでもらう
    • エンジニアさんも人間ですから
• テスト用語はちょっとずつ使う
  • 業界標準だからと言って、正義の拳で殴らない
• 相手の好みに合わせた例えを多用する
  • ex), メカ好きには「システムをぶち壊すお仕事です」と刷り込むとか
  • 対話…だと重苦しいので、頻繁に「会話」する
  • 最初は一方通行でOK（信頼関係ができるまで粘り強く待ちましょう）