普段の仕事では「システムテストはQAが担当!」のようにスコープ切って一部分を担当している形ではなく、開発者がテストを行うのが基本で、QAがフォローしたりレビューに入ったりする(全てではない)形でやっています。
なので開発者が作成したテストケースをレビューする機会がちょこちょこあるのですが、その中で意識していることをいくつか挙げておきます。
より少なく、しかしより良く
コレの概念です。
うまくできているかは別にしていつも心がけねばと思っているのが、より少なく、しかしより良く、です。
テストのレビューの際に「この観点が足りない」とか「このケースも」みたいな指摘をしがちです。もちろんやるべきことはやらなければならないのですが、同時に「QAがレビューに入るとやることが増える」と思われないような工夫も要ると考えています。
なので、単純にテストケースを増やそうというコメントをするだけではなくて、テスト技法を使うと効率的になるとか、このケースは実質重複だから省けるとか、そういった効率化・ 省力化側のコメントも併せてできると、双方ハッピーになります。
全体を見て足りないところを補う
開発者に限らずQAでも陥るときがありますが、「テストを考える」というときに特定のテストレベルやテストタイプに偏ることがあります。
例えば画面単位での個々の機能について細かいテストケースを挙げているけれども、画面間の遷移やユースケースをあまり意識していない、とか。あるいはその逆である程度のシナリオは考慮されているけれども、異常系やエッジケースが考慮されていないとか。
これは個人・チーム・組織においてある程度傾向があると思っていて、ひとりめQAとしてJoinした場合などはその組織において「テスト」と言った際の傾向やクセを早めに把握するといいですね。
テストQA用語の使い所に気をつける
ひとりめQAをやっていて「いい訓練になるな」というポイントでも書いたのですが、テストケースのレビューのようなシチュエーションでは、テストやQAの用語をむやみに使わないように気をつけています。
仕事のコミュニケーションを取る上では、「相手の辞書で話す」のがとても大事だと考えています。開発者に対してJSTQBの用語で話し続けても「?」となることのほうが多いと思うんですよね。わからない単語使ってくる相手の話はふつう聞きたくないですし、ましてやそれを「これが標準ですが?」みたいなスタンスで来られたら嫌ですよね。レビューのコメントなどはただでさえ言い方に気をつけないといけないところなので、なるべくテスト用語を使わずに一般的なことばを使うほうがよいと考えています。
ただし、テスト用語を使ってはいけないという話ではない点に注意です。組織の中でテスト等に関することばを浸透させていくことは大事だと思いますし私もやっています。 ただ、浸透させる取り組みはまた別でやるべきで、ふわっとしてる状態だったり相手が知らない状態だったりでむやみに使うのは違いますよ、ということです。
他にもいろいろありますが、主だったものを3つ挙げてみました。自分自身も常にできているわけではないものの、引き続き意識していくということで。