こんにちは。ヒューマンクレストの山口です。
2021年3月15日（月）〜16日（火）に開催のJaSST Tokyoで、「テストエンジニアへインタビュー　〜アジャイルプロジェクト〜」という内容をお伝えしました。
今回はその全貌をお届けします。

テストエンジニアの背景

エンジニア歴：3年
アジャイルプロジェクトへの参画時期：2018年〜

Bich Phung Thi（フォンティビック）さん

※以降、アジャイルプロジェクトへ参画しているテストエンジニアを「アジャイルテスター」、それ以外のテストエンジニア「テスター」と記載します。

参加しているプロジェクトのスケジュールは？

プロジェクトのスプリントは1週間サイクルで、一般的なスクラムイベントの「プランニング」「レトロスペクティブ」「スタンドアップMTG」等は全ておこなわれています。
その中で、アジャイルテスターとしてはこの表に書かれているようなスケジュールで行動しています。アジャイルスクラムイベントの中では「リファインメント」のみに参加しているため、リファインメントがある木曜日からテスト分析と設計を実施しています。

どんなテストをしていますか？

手動では主に機能テストとシナリオテストを実施していますが、アジャイルプロジェクトでは、機能を全網羅するようなテストは難しいです。そのため、スプリント内で必要なテストを見極めてテストしています。また、別チームで自動テストも実施していて、常に連携を取っています。

アジャイルプロジェクトで気を付けていること、意識していることは何ですか？

まず始めに、テスターとアジャイルテスターの違いを意識しています。テスターはドキュメントやシステムができてから、テストを作ることが多いですが、アジャイルプロジェクトの場合、ドキュメントがあまりなく、必要なところからテストを作成しています。そのため、コミュニケーション（ソフトスキル）がとても重要だと思っています。

コミュニケーションが必要な場面はどのようなところですか？

特にリファインメント会議内で行われるレビューの場面で重要です。例えば、テスターの場合、仕様バグはドキュメントレビューやテスト設計時に発見することが多いです。その一方で、アジャイルプロジェクトでは開発対象の機能が決まる「プランニング」、その後ユーザストーリの見積もり・必要な機能等を話し合う「リファインメント」があり、私はこのリファインメントに参加しています。仕様の把握や影響範囲の確認・開発機能の価値を考えながら会議に参加することで、開発者が実装を始める前に仕様バグを指摘し、バグの混入を防ぐことができます。ただ、書かれた内容をレビューするだけなら誰でもできますが、影響範囲や目的まで意識していることで、様々な観点でフレキシブルに指摘ができます。もちろん再度設計を読んだり、テストを実施して仕様バグを見つけることもあります。

また、アジャイルプロジェクトでは開発者とアジャイルテスターがQA表のみでやりとりするような、質問して回答を待つだけということはありません。この方法だとフィードバックが遅く、1週間のスプリント内にテストを完了できないからです。指摘は会議の場ですることが多いですが、それ以外の場でも常に指摘歓迎という状態なので、質問があればその場でディスカッションするようにしています。

コミュニケーションの取り方を意識していて、良かったと思うことはありますか？

チームメンバーと信頼関係が構築できることです。信頼関係があることで、レビュー時の指摘も信用度が高いと思います。また、会議ではなく雑談などの場から話を聞き、新たな発見をすることもあります。

今までプロジェクトに参加していて、難しかったこと困ったことはありますか？

まず、一番最初にプロジェクトに参加したとき、ドキュメントが少ないのでプロジェクトの理解が難しかったです。私は、リファインメントから情報を得たり、分かったフリをせず遠慮なく質問したりすることで少しずつ理解していきました。やはりここでもコミュニケーションが重要で、アジャイルプロジェクトならではの、「共有」「共感」「協力」を実感することができたと思います。一気に全てのことを覚えるのは難しいですが、少しずつ一歩ずつ進んでいく意志が大事だと思います。

情報共有で困ったこともありました。機能の追加や変更はチケットに紐付いているのですが、知らないうちに私が見ていたチケットだけではなく、新たなチケットが作成されていて、変更内容に気が付かなかったことがありました。おそらく参加していない他のスクラムイベントで話がされていたのだと思います。ですので、会議に参加できる立場にいる場合は、スタンドアップMTG等の他の会議にも参加した方がいいと思います。私達のプロジェクトでは、議事録があるため、そこを見ることで最低限の内容は理解できるようになっています。チーム全体で知識や全体像を常に共有しておくことが必要ですね。

参考になった資料・書籍はありますか？

一番参考になったのは、「ISTQBシラバス　アジャイルテスト担当者」です。その中でもテスト担当者の役割（P.26）はとても参考になりました。

最後に一言お願いします！

Don’t just do Agile, Be Agile.
日本語だと『ただアジャイルプラクティスを実施するのではなく、その価値・原則に沿った「状態」になっていることが大事。』という意味合いがあります。この通り、型にとらわれすぎず、現場のプロジェクトに合わせて適応していくことが大事だと思います。今回の話も、その参考の1つになれば嬉しいです！