開発と並走したいQAが開発の各工程でやっていること

今回は、普段の振り返りがてら開発の各工程でやっていることをまとめたいと思います。基本的にはシフトレフトを意識しながらテストを進めています。

シフトレフトなスケジュールのイメージ

ウォーターフォールもアジャイルも経験していますが基本的にどちらでもやることは変わりません。
少しでも参考になれば幸いです。

前提

前提として私はテスト担当者の主な役割は「情報を見つけだすこと」だと考えています。ここには以下のような情報を含みます。

• 現在地の情報

  • ＝プロジェクト（の成果物）が現在どのような状況か

• 目的地の情報

  • ＝プロジェクト（の成果物）がどのような状況になればよいか

• 障害物の情報

  • ＝プロジェクトがどんなところで躓きがちか

• 進み方の情報

  • ＝どんなツール、考え方、方法論を使うと良いか

この後見ていく各工程ではいろいろなことをやっていますが、結局のところ考え方は同じです。実際に見ていきましょう。

要件定義

要件定義の段階で行っていることは以下のとおりです。

• システムのユースケースについての情報を調べる

• システムの変更によって起こりうるリスクを洗い出す

• 過去の類似案件の進め方や苦労したところを調べる

「プロダクトを使ってこんなことをしたい」という要求を知った時点で、ある程度慣れてくるとその機能のユースケース（誰が何をできるのか）や、その変更を行うことにより発生しうるリスクを想定できる場合があります。

結果として、上記で得た情報に対する考慮がPRD（プロダクト要求仕様書）から漏れていた場合はその指摘をすることがあります。また、テスト工程で使うテスト分析はこの段階から走り出し、実装に入る前にはほぼ全体像を作り終えています。

設計

システム設計の段階で主に行っていることは以下のとおりです。

• 要求から導き出される設計書のあるべき姿を考える

• 実際に書かれている設計書の内容を調べる

• テスト分析を行い、その内容を開発チームへ連携する

• 設計書に漏れや誤りがあれば報告する

成果物に書かれていることが間違っていたこと以上に、必要なものが漏れていたという経験は多いです。個人的なおすすめはAs-Is To-Beのフレームワークを用いて分析を行うことで、自分の中で正解を作ってから成果物と比較するので漏れを見つけやすいです。

また、わざわざ成果物ができてからその誤りを指摘をするのではなく、あらかじめ変更範囲やリスクへの対応方法がわかっているのであれば、その情報を開発チームに連携することで設計に役立ててもらうこともあります。最近はATDD（受け入れテスト駆動開発）も取り入れてみています。

実装

システム実装の段階で主に行っていることは以下のとおりです。

• 変更コード（テストコード含む）を取得する

• コードを実際に手元の環境に取り込んで動かせるようにする

• E2Eテストを実装orメンテナンスし、デグレを防ぐ

• コードに誤りがあったり、コンポーネントごとに期待しない動きがあった場合は報告する

変更コードを取得した上で、可能な限りレビューしています。コードレビューについては以前こんな記事を書いたことがあるのでよろしければ読んでみてください。

この工程では、開発エンジニアが行うのと同じような机上確認や動作チェックをするのが主な動きです。そのためには、可能な限り開発エンジニアの方が参加されるMTGに参加して情報をキャッチしたり、時間があればペアプロ、モブプロに混ざってみたりします。プルリクエストの段階でE2Eへの影響を察知してメンテナンスに動くこともあります。

テスト

さて、テスト担当者が主役たるテスト工程ですが、基本的にはここの工程が重くなりすぎないように先々の工程で動いてきています。仕様の漏れは要件定義や設計の段階で潰せているはずですし、実装の設計との食い違いは実装の段階で潰しているはずです。

が、それでも全部繋げてみないとわからないような想定外の動きはあり得るわけで、それをこの工程で拾います。なので行うのは、

• ユーザーの実際の動きを想定して通しで現在の動きを確認する

基本的にはこの一点になります。
また最近は、

• バグを分析・分類し、チームにフィードバックする

ということを中間報告的に行うことがあります。リリース後だとチームが解散してしまったり、次のプロジェクトに目が向いていたりしてなかなか役立てづらいです。「現在のバグの状況はこうだが、ここにリリースに向けての改善点はないか？」という方向性で話し合ったりします。

終わりに

実際何をやっているかというと、結局のところテスト工程も含めて全て目的までに必要な情報を拾い上げて開発チームに伝え、開発をサポートしているというのが個人的な認識です。

そのためにはPdM的な知識も開発者的な知識も求められるところがあり、現在そのすべてが身についているとは到底言い難いので、実際の現場のPdMや開発エンジニアと協力しながら、知識を吸収していきたいと考えています。

ここまでお読みいただきありがとうございました。