【第5回】1人目QAアンチパターン

本連載では、ここまで主に「1人目のQAがやるべきこと」について、経験ベースでお伝えしてきました。
今回は少し視点を変えて、1人目のQAがやるべきではないこと、アンチパターンについてご紹介したいと思います。

やるべきことは組織の状況などによって変化することもありますが、アンチパターンは状況によらずある程度共通する部分がある、と考えているためです。

本記事では、代表的なアンチパターンを4つ説明します。

目の前のタスクに集中しすぎる

一つは、目の前のタスク、「すぐに実施できて達成感が得られそうなタスク」に集中しすぎてしまうことです。
とくに組織にJoinした直後のQAは、できる仕事がたくさんある状態だと思います。

そこで【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqriptsでご紹介したように組織の現状把握をしつつタスクの取捨選択を行うわけですが、このときに個々のタスク、とくに達成感・「仕事をした感」が得やすいタスクを選び取りがちです。

たとえばリリース後に見つかる不具合が多い開発チームに入っていき、テスト設計・実行やリリース前の探索的テストに注力したとします。もちろんこれ自体は良いことです。しかし、そこでバグを見つけたり開発チームに感謝されたりしながら、1か月2か月と過ごしていったとして、それは1人目QAとしてのミッションに沿っているのでしょうか？

会社として、問題のあるチームに入って立て直してほしいという狙いがあれば、動き方としては良さそうです。しかし、広く会社全体の品質保証のやり方を考えてほしい、といった狙いがある場合はどうでしょうか。

目の前のタスクを行って一定の成果が出ることは良いのですが、ついそこにハマってしまう危険もあります。1人目QAとして期待される動きや成果を考慮したうえで、場合によっては広く組織全体にアプローチするようなやり方が必要かもしれません。

得意なやり方、実績あるやり方に頼りすぎる

なんらかの課題に対して、自分の得意なやり方や実績あるやり方を当てはめてしまうというのもよく目にするアンチパターンです。

テスト技術に自信がある、テストプロセスの整備の経験が豊富など、QAエンジニアそれぞれにはなんらかの得意なジャンルや手法があるかと思います。

そして、とくに入社直後のQAの場合は目に見える成果が欲しくなるため、つい自分の得意技で攻めようとしてしまいがちです。しかし、たとえばシステムテストの自動化が得意だからといって、なんでもかんでも自動化によって解決できるわけではありません。