この記事は、CYBOZU SUMMER BLOG FES '24 (Newcomer Stage) DAY 3の記事です。
はじめに
こんにちは。Garoon開発でQA（品質保証）エンジニアをしているreoです！!
私は、2024年度新卒QAエンジニアとしてサイボウズに入社しました。新たな環境でQAエンジニアとしてキャリアをスタートする中で、作成した成果物に対してレビューを依頼する機会が非常に多くあると感じています。また、これらのレビューを通じて、自分なりの気づきや学びを多く得ることができています。
そんな新卒QAエンジニアである私が、レビュー依頼者の視点から、テスト活動で「良いレビュー」を受けるために心がけていることについて紹介します💪
テスト活動について
この記事で取り上げる「テスト活動」とは、プロダクトの品質を確保するために行われる活動のことを指しており、基本的な活動の手順としてはテストプロセスに沿って行います。ISTQB (International Software Testing Qualifications Board) の用語集によると、テストプロセスは以下のように定められています。
*1相互に関連する活動のセット。テスト計画作業、テストモニタリングとコントロール、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了といった活動から構成される。
本記事では、テストプロセスで行うテスト計画作業、テスト分析、テスト設計、テスト実装といった一連の活動の最終成果物や作成するまでの「過程」をドキュメント化したものをテストドキュメントと呼びます。テストドキュメントは、テストの実施において重要な指針とし、テストの一貫性と効率性を確保するために使用します。
私の考える「良いレビュー」
記事のタイトルにも含めましたが、そもそも「良いレビュー」とはどのようなレビューのことを指すのでしょうか？？
抽象的な言葉であるため、人によって「良いレビュー」への解釈が異なってくると思います。私自身は「良いレビュー」を受けるために必要なポイントの1つとして、成果物だけでなく、その作成過程や意思決定のプロセスも含めてレビューしてもらえることがあると考えています。（本記事では、「良いレビュー」をこのように定義します）
上のように考える理由は、レビュー者が成果物の思考プロセスや意思決定の過程を知ることで、レビュー依頼者が抱える課題に対して原因を理解しやすくなるため、より具体的なアドバイスをすることができるからです。また、レビューを通じて、依頼者自身も思考プロセスを振り返ることができるため、次回以降の作業においても改善点を取り入れやすくなるというメリットもあります。
もちろん、レビュー依頼者だけが「良いレビュー」を意識すれば良いというわけではありません。しかし、私は、依頼者が少しだけ意識を変えるだけで、レビューの質が向上することにつながるのではないかと考えています。
ドキュメントレビューにおけるこれまでの課題
私がこれまでに抱えていたテストドキュメントレビューの課題についてざっくり説明します。
これまでのテストドキュメントを机上でレビューしていただく際には、テスト設計の項目で「何を確認したいのか」や「何を伝えたいのか」がわからないことや、レビュー依頼者である私自身が抱える「わかりづらい」と思っている箇所が不明瞭であることを頻繁に指摘されました。
また、対面でテストドキュメントレビューで自分の考えを口頭で説明する際にも、テスト設計での思考プロセスをうまく説明できず、テスト観点を考える過程などでにおいての自分がつまずいてしまったポイントの根本解決に至らないケースがありました。
テスト設計で「良いレビュー」を受けるために心がけたこと
これらの課題を解決するために、私がテストドキュメントを作成する際に「良いレビュー」を受けるために心がけたこと3点について紹介します。
1. 「気づき」と「考えたこと」を記入
テスト設計とテスト分析とは別に「気づき」と「考えたこと」を記入することを心がけました。
先ほども触れたのですが、私は、テスト設計を行う際に、「何を確認したいのか」や「何を伝えたいのか」をうまく伝えることができないといった課題を抱えていました。そのため、成果物を作成する過程でどのような気づきがあったのか、逆に、どこに躓いてしまったかなどを、レビュー者に伝えることを意図して、「気づき」と「考えたこと」の項目をテストドキュメントに記載し、私の思考プロセスをレビュー者に伝えるようにしました。
これにより、テスト設計を対面で説明する際に自分の考えを説明しやすくなるだけでなく、机上でのレビューにおいても、なぜ自分がこのテスト観点を入れたのかなどの理由がログとして残るため、「考えたこと」や「気づき」に関してもアドバイスをいただける機会が増え、段階的なフィードバックを受けやすくなりました。結果、より効果的なテストケースを作成するための新たな視点を得ることができ、テストドキュメントの質が少し向上しました。
2. まずテスト目的を記入し、それを見失わない
これまでのテスト分析では、テスト目的を明示し、それを見失わないことを意識しました。
これまでのテスト分析を行う際において、テスト目的を見失なってしまい、テスト観点がテスト目的とずれてしまうケースが頻繁にありました。そのようなケースを防ぐために、テストドキュメントにテスト目的を明確に記入し、それを見失わないように常に意識してテスト分析を行うことで、ゴールを意識してテスト観点を洗い出せるようになり、より一貫性を持ったテストドキュメントを作成することができるようになりました。
上のように、テストの一貫性が保たれたことにより、レビュー者もテストの意図を理解しやすくなります。また、テスト目的を明確にすることで、テストの優先順位をつけやすくなり、重要な機能やリスクの高い部分に集中してテストを行うことができるようになったと実感しています。
3. レビュー依頼のタイミング
指摘箇所を少なくするために、テストプロセスに沿った活動のタイミングで適切にレビューを依頼することを意識しました。
これまで私は、テストケースを作成し終わるタイミングでテスト分析やテスト設計の成果物もまとめてレビューを依頼していました。
このレビュー依頼のタイミングだと、テスト目的やテスト分析の方向性が、レビュー者の期待されていた結果とずれていない場合は問題ないのですが、テスト分析の段階で期待されていた結果とズレが生まれていた際に、多くの手戻りが発生してしまい、時間を浪費してしまうことになります。
その経験から、レビューごとの指摘箇所を少なくするために、また、ズレが生まれた際に直ちに修正できるために、「テスト分析を終えた段階で、まずレビュー依頼する」ことを意識的に取り組むようになりました。
具体的なプロセスは以下のようになっています。
上の図でも記載があるように、基本的にテスト分析が完了したタイミングでレビューを依頼するように心がけています。また、必要に応じて、 テスト目的のみを出したタイミングやテスト観点を出したタイミング、テストプロセスのそれぞれの活動が終わったタイミングといった、テスト設計でずれが生まれてしまっている可能性があるタイミングで柔軟にレビューを依頼するようにしました。 レビュー依頼の回数を無駄に増やさずに済み、テストドキュメント作成時にズレが生まれにくくなりました。
おわりに
最後まで読んでいただきありがとうございます！
今回の記事では、私がテスト活動で「良いレビュー」を受けるために心がけていることについて紹介しました。自分自身、レビュー以外にも日々周りの方々に助けてもらいながら日々の業務をこなしています。これからもレビューをいただく際や、レビューをする側の立場になった際にも、「良いレビュー」を受けるための取り組みを意識していきたいと感じています。
本記事が少しでも皆さんの参考になれば幸いです🙏
