タスクボードに"テスト中(In test)"のような欄があると、進行中の作業の数が多く、実際に完了した作業の数が少なくなることがよくある。このような欄は取り払ってしまった方が、テスタと開発者のコラボレーションが増え、デリバリが早くなる。
BBC iPlayer & SoundsチームのプリンシパルテスタであるJit Gosai氏がLean Agile Exchange 2020で、テスト欄を削除することでデリバリ速度を向上した自身の経験について講演した。
一般的なタスクボードには、テスタが作業中であることを示す"テスト中"や、"開発終了"した作業を集約するための"テスト待ち(Waiting for test)"といった欄がある。テスタは次に何をする必要があるのか分かっている、とGosai氏は言う — テスタの作業完了を待つ間、開発者は別の仕事に取り掛かればよい。そうすれば、チームメンバを十分に活用し続けることができるのだ。
問題が見つからなければ、タスクを次の欄に移動することが可能になる。一般的には"完了(Done)"か、あるいは"リリース待ち(Waiting for release)"だ。だが、テスタが問題を見つけた、あるいは、さらに情報が必要になった場合はどうだろうか？選択肢はたくさんある — "開発中(In Dev)"に戻すか、バックログにプッシュバックするか。あるいは待機場所として、今度は"開発待ち(Waiting for Dev)"の欄を作るだろうか？これらの選択肢は、いずれも進行中の作業を増やすか、あるいは開発者にコンテキストをスイッチする結果になる、とGosai氏は言う。
その間、テスタは何をすればよいのだろう？別の作業項目が欄に入ってくるのか、それとも開発者の作業を待つのか？どちらを選択したとしても、タスクを完了させる上で、テストが常に最大のボトルネックになるだろう。チームにはテスタよりも多くの開発者がいるのが常だからだ、とGosai氏は主張する。
"テスト中"の欄を取り除いてしまえば、テスタがテストしている間も開発者は作業に留まることになるので、運用まで協力して作業に当たることができる、とGosai氏は言う。開発者はテスタと協力して、次に何が必要なのかを理解し、一緒に作業を完結しなければならなくなる。
適切なプロセス改善プラクティスが実践されれば、チームの行う作業に伴うリスクを軽減する上で、テスタと開発者がどのように連携できるかが分かるようになる。こうすることで、テスト中に発見された洞察は、バグレポートとして開発者に引き継がれるのではなく、前述のプロセスへと組み込まれていくようになっていくのだ、とGosai氏は締め括った。
講演を終えたJit Gosai氏に話を聞いた。
InfoQ: タスクボードにテスト欄があることのデメリットは何でしょうか？
Jit Gosai: "テスト中"や"テスト待ち"といった欄はよいアイデアに見えるかも知れませんが、講演で説明したように、進行中の作業が増えるなどの問題につながるのです(詳細は私の記事">issues the "In test" column causes"を参照してください)。
この問題の解決方法は、通常はテスタを増員する、あるいはエンドツーエンドのUIテストで一般的な自動化を行う、といったものになります。前者は費用がかかり過ぎますし、後者については、例えば分離性の低い、フルスタックを使用するような統合的なテストを書くようになったり、テストが他者の責任とされたり、テスト工程が開発ライフサイクルの後の方に押しやられたり等々、別の好ましくない開発習慣を引き起こすことになります。自動化の引き起こす問題については、私の記事"The unintended consequences of automated UI tests"でも詳しく取り上げています。
InfoQ: テストの欄を取り除いてもテストを意識し続けることは、どうすればできるのでしょう？
Gosal: テスト欄を削除するというのは、テストが重要ではない、あるいはテストを実施しないという意味ではありません。新たな作業を始めることよりも、現在の作業の完了を重視するという共通の目標に対して、チームが集中すると、いうことなのです。
実行すべき作業ステップが少ないということは、開発者が作業に長く留まれる、あるいは他の作業者を手伝うことができる、という意味でもあります。結果としてこれが、テスタと開発者に対して、何が完了しているのか、あと何をテストしなければならないのか、ということを理解できるようになる機会を与えてくれるのです。
InfoQ: テスト欄を取り除くとデリバリが早くなるのはなぜでしょう？
Gosai: 主に2つあります。ひとつは、進行中の作業が少なくなり、作業を完了することにより集中するからです。これによって当然、より多くの作業が完了することになります。欠陥や、その他の予期しない状況によって再作業が必要な場合は、特にそうです。もうひとつは、開発者とテスタが共同で作業することにより、コード変更に関連するリスクの低減が可能になることです。
このステージで共同作業するということは、変更に関して事前に認知していることや、変更作業を通じて理解したことなど、情報を共有できるということになります。これにより個々の作業者が、他のメンバの知識を活用し、基盤とすることが可能になります。単独で作業していたのでは得られなかったかも知れない、新たなアイデアを生み出すことができるのです。これらの緩和策を自動化、あるいは他のプロセスを通じて開発プロセスに組み入れられるかどうか見極めるには、今が絶好のチャンスです。同時にこれは、(実際の環境で問題が見つかったなどの理由で)タスクが実際に再作業されているかどうかを確認して、この問題が再発しないように学ぶことのできる機会でもあります。
これらの改善がすぐに確認できるメリットであるのに対して、長期的な改善として、タスクのリードタイムを大幅に改善できる可能性があります。これにより、チームが同じタイムフレーム内でより多くの作業を行うことが可能になり、結果としてデリバリの迅速化につながります。
このような短期間化には、ただし、いくつかの仮定があります。おもな2つのうちのひとつは、開発者とテスタが、隠れた形でミニdev/testハンドオーバプロセスに移行するのではなく、相手の行ったこと、行っていることを理解するためのコラボレーションを実現することであり、もうひとつは、互いの分野と、運用環境まで到達した障害の種類から学ぶための、効果的かつ継続的な改善プログラムが存在することです。
InfoQ: タスクボードに表示されているものを使ってテストを改善するには、どうすればよいのでしょうか？
Gosai: これまで説明したような作業上のコラボレーションがチームにとってまったく新しいものであり、継続的改善の戦略をまだ実施していない場合でも、このプロセスを開始するためのテクニックはいくつかあります。テストがチームにとって、リリース上の最大のボトルネックであることが実際に分かっているのであれば、アドバンテージとして"テスト中"欄を使用することが可能です。
テスタは単にこの欄を仕事を拾って完了まで作業するだけではなく、チームと一緒に作業して、テストに対するアプローチ方法、テストを通じて探索するもの、さらにテストを通じて得たものを、チームが理解できるように支援することが必要です。いくつかのタスクでこれを行えば、作業の中の重要なテーマを特定する上で、何らかの役に立つかも知れません。例えば、ユーザビリティとアクセシビリティ上の問題に共通するような根本原因があるでしょうか、あるいは、特定のハードウェアとソフトウェアの組み合わせがいつもバグを生んでいるようなことはないでしょうか？変更を行う場合に、開発側で注意できることが何かあるでしょうか？こういったテーマを使用すれば、チームが取り掛かることのできるタスクのバックログを作成して、開発サイクル内のもっと早い段階で対応できないか確認することが可能になります。
人ではなくプロセスに注目することで、テスタが何をしているのか、この作業をライフサイクル内の早い段階で軽減するために開発者とテスタには何ができるのか、などを話し合うことが簡単になり、それが継続的改善プログラムの出発点となるのです。
このプロセスにおいては、リーダシップが非常に重要です。リーダはテスタがチーム内の"問題"として標的にされることなく、安心して作業ができるように配慮する必要があります。テスト時にチームがどのようなリスクを探すのかを教育する上で、テスタこそがそのソリューションなのです。さらに開発者は、コミュニケーションに関するコーチングや、他の役割を彼らが置き換えようとしているのではなく、ともにプロセス改善のために作業しているのだ、という事実に基づいた共感の確立を通じて、他の分野のメンバとも緊密な関係で作業する必要があります。
チーム内でのリーダシップにおいて重要なタスクのひとつは、心理的な安心感を得られる環境を構築することです。これによってチームメンバは、後ろめたさや能力不足という評価を受けるリスクを負うことなく、自らが直面する問題をオープンにし、見解やアイデア、さらには、まだ完全な形にはなっていないソリューションを共有することが可能になるのです。継続的改善のタスクに関するバックログを用意するのもよいでしょう、ですが、チームメンバがそれを使って仕事をすることを望んでいないならば、そこから得られる成果はたかが知れています。これは必然的に、その価値に見合った注目を集めることがなく、改革が始まる前に失敗するということを意味しているのです。"それは以前に試しました"、あるいは"それはうまくいかないでしょう。なぜなら ..."という返事を聞くことになるかも知れません。