この記事はRachel Kiblerによるゲスト投稿です。
私はテストが好きです。そう聞いて驚く人はいないと思います。でも、私は自分が門番になったような気にさせられるのが好きではありませんし、コードをどのように改善するかについて開発者と話すという避けがたい会話を楽しんでいるとも言えません。
私が今の会社で働き始めて2週間目のある日、チームの5人の開発者のそれぞれが私にテストしてもらいたものを用意していました。通常、私は1日に２つから５つのものをリリースしていましたが、その日は何もリリースできませんでした。５つのストーリーはどれも複数のバグがあり、そのバグが修正されても、また別のバグが出てきました。チームの誰にとっても意気消沈させられる日で、私は状況を良い方へ変えようと決意しました。
最初のステップとして、手戻りをどのように計測するかを考えました。簡単なメトリクスとして、かんばんフローで後戻りした回数を計測することにしました。たとえば、何かの作業が開始された後にもっと情報や議論が必要だとわかり、作業アイテムが「To Do」に戻されたなら、手戻りとしてカウントされます。多くの場合、「In testing」が「In dev」になったときをカウントすることになりましたが、このケースだけでなくもっと多くの問題を捕捉するため、より広い定義を選択することにしました。
私はこのメトリクスをチームと共有し、なぜ作業が後戻りしたのかを議論してもらうようにしました。
議論で得られた情報を元にして、私は手戻りを減らすためにいくつかの試みを考えだしました
- リファインメントミーティングでもっとはっきりと主張する
- 設計をレビューし、チームにもレビューしてもらう
- 開発者がプルリクエストを作成する前に、開発者とペアで作業する
- より多くの（そしてより優れた）単体テストおよびインテグレーションテストを作成してもらう
- 互いのコードをテストするのに慣れてもらう
最初の1つ、そして2番目も部分的には、私が勇気を出せばいいだけでした。
私は人に好かれたいと思っていますし、衝突は好きではありません。テスターにとってすばらしい特質ではありませんか？私は、目的を果たす優れたコードがリリースされることを誰もが望んでいるという前提からスタートし、そのことがさまざまな会話でプラスになりました。そうした心構えにより「テスト 対 開発」という思考を断ち切り、全員が同じ側に立つことになります。
リファインメントミーティングではっきりと—それも大いに—主張することはかなり役に立ちました。それと並行して、リファインメントミーティング中に設計に目を通してくれるよう依頼するようにしました。
特に記憶に残っているリファインメントミーティングでは、プロダクトオーナーは新しい機能に非常に興奮していました。私はあらゆる文章、あらゆる設計要素について質問し、チームも触発されてさらに多くの疑問を出し、結局、機能はもっと検討や調査、他のチームとのコラボレーションを要するとして差し戻されたのです。プロダクトオーナーは、追加の調査をすべて完了すると文書にまとめ、穴がないか厳しくチェックするよう、わざわざ私に依頼してきました。プロダクトオーナーは、皆が同じゴールを目指しており、ただゴールに至るうえでの役割が違うだけだと理解しました。
私たちは設計をレビューする準備ができたら送ってくれるよう設計者に依頼し、プロダクトオーナーだけでなく、皆が個別に、またチームとしてレビューできるようにしました。私は、画面がすでにコーディングされてから、画面上の言葉づかいや、ボタンのサイズや、ユーザビリティの問題について疑問を投げかけるのに飽き飽きしていました。私のリードに従って、設計で問題を見つけると手戻りを防ぐことになるということを皆がたちまち理解しました。誤字が修正され、ぎこちないコピーが変更されました。さらに、リファインメントミーティングで意見を出すようにし始めたときと同様、私たちはいざ実装する段になったとき、より確信を持てるようになりました。
開発者とのペア作業は、軌道に乗るまで難航しました。この試みの背後にあるアイデアは、コーディング中に開発者と話し合うことで、バグが作りこまれる前に捕捉しようというものです。現在の作業について質問し、何を試すかについて提案を行い、ネガティブテストケースを多数提供します。開発者が一人で、あるいは別の開発者と組んでコーディングするよりは時間がかかりますし、この試みが成功だと証明する確固としたメトリクスはありません。それでも、これが良いことだと示すメトリクスあるいはじゅうぶんな経験的エビデンスを集められるのではないかと考え、続けていくつもりです。
4番目のアイデアについてですが、チームには単体テストを作成するのを好まない開発者もいます。単体テストに価値を見出していないのです。これは、良い単体テストを作成する方法について、しっかりしたトレーニングを受けたことがないからではないかという疑いを強く持っています。開発者から開発者への単体テストおよびインテグレーションテストの作成方法についての教育はまだ進行途中です。それでも、単体テストに積極的でない開発者の態度は変わりつつあります。
最後の、互いのコードをテストするのに慣れるという試みもまだ途中です。私はおおぜいの開発者と個人的に会話し、私がどのようにテストを行っているか、互いのコードに問題がないことをどのように確認できるかについて話し、またトレーニングとしてまとめてもいます。私が休暇でいない間も開発者たちが問題なくやっていけるようになること、それが私のゴールです。
最近の1週間で、私は依然として多くの作業アイテムを差し戻しましたが、たいていは一回だけで、何もかもというわけでもありません。私たちは進歩しています！
Rachel Kibler は 1-800 Contacts で働くテスターです。オンラインでは racheljoi.com および Twitter @racheljoi で活動しています。
（この記事は、開発元Gurock社の Blog 「Tester’s Diary: Five Experiments for Reducing Rework」2020年7月16日の翻訳記事です。）
