この記事はDee Ann Pizzicaによるゲスト投稿です。

ソフトウェア開発では、問題を早く見つけるほど修正が容易でコストも抑えられます。

私がそれに気付いたのは、要件・設計・実装・テストに関して旧来のV字モデルを採用する大規模なウォーターフォール型プロジェクトに携わっていたときです。しかし、小さな組織であっても、早期にフィードバックを得ることなく設計を作りこみすぎてしまうという罠にはまるのは簡単でした。

後にアジャイル手法が業界を席巻し、みな懸命にフィードバックループを縮めようとしました。これは、最適なソリューションを構築することに重点を置いて開発作業を改善しようとする試みでした。

テストのシフトレフトはその次のステップです。これは、どのようなプロジェクト管理プロセスであっても取り入れられる変化であり、ウォーターフォールでもアジャイルでも有効です。以下では、なぜテストのシフトレフトが重要なのか、また特に重要なこととして、プラクティスの効果を最大化するために、チームに合わせてどのような調整が可能なのかを見ていきます。

シフトレフトとは

従来のソフトウェアサイクルモデルでは、プロジェクトは始まりから終わりまで順を追って、たいていは予測されたとおりに進行します。これは、左から右へ向かう手順で図式化されることがよくあります。

問題の識別 >> 可能なソリューションの議論 >> ソリューションの設計 >> ソリューションの実装 >> ソリューションのテスト

プロジェクトの最後のステップでテストを行うのは理に適っています。結局のところ、実際に試してみなければ、ソリューションが問題を解決するかどうかはわからないではありませんか？しかしいっぽうで、テストを最後の最後まで保留したあげく、もし的を外していたらどうしますか？それから新しいソリューションを再構築し、プロジェクトを軌道に戻すには何ヶ月もかかるでしょう。

シフトレフトとは、テストをプロセスのより早い段階に移そうというアイデアです。テストをプロジェクトの初期のフェーズに組み込むと、仮定でものごとを考える癖がなくなり、チームの誰もがテスターになります。 

早くテストするほど、想定されていなかったことを発見し、プロジェクトの最初で修正できる確率が高くなります。完成してデリバリーの用意ができた機能をテストするだけでなく、Scrumでそうするように、プロジェクトのあらゆる側面をテストします。

なぜシフトレフトするべきなのか

プロジェクトの終盤になって、結局のところ、自分たちがひどい誤りを犯しており、簡単には救いようがないということがわかるのは、コストが高く、チームの士気を下げ、ステークホルダーにとって大きなリスクになります。

直感には反しますが、急ぐためにスローダウンしなければならないときもあります。すべてのステークホルダーを招集し、立ち止まって、プロジェクト全体のさまざまなソースからフィードバックを求めるのは、コストの高い行為ですが、間違った方向に進むほうがずっと高くつきます。

どこでシフトレフトするか

シフトレフトするとは、プロジェクトの全工程を通じてテストを行うようにマインドセットを変えることです。プロセスのあらゆるフェーズを調べて、テスターが––あるいはテスターのマインドセットを持ったメンバーなら誰でも––現在のプロセスを改善できる箇所を探します。チーム全体でテストに関わるあらゆる可能性を探ります。

テスト計画 

プロジェクト開始時には、問題とそれに対するソリューションの候補について議論します。このプロセスの一環としてドキュメントを作成していない場合、作成することを強くお勧めします。うまくいっているScrumチームであっても、ユーザーストーリーだけでは複雑なプロジェクトの全体像をじゅうぶんに捉えられないことは多いものです。 

計画書や議論のメモ書きをドキュメント化したら、自分のアイデアや仮定をテストする時間を取ります。チームメンバーがブレインストームする時間だけでなく、提案されたソリューションを再読し、じっくり考える時間も予定に入れます。

ソリューションがどのように機能するか、詳細な質問をしましょう。

• このプロジェクトで最も重要なステークホルダーは誰か？
• ほかにどんなソリューションが検討されたか、またなぜ違う方法を選んだのか？
• このソリューションのリスクは何か？
• ほかに評価・使用・機能比較するべきツールや製品はあるか？
• 把握しきれていない領域はあるか？想定外の事態に関するリスクを軽減するためにどんな計画が立てられているか？

こういった質問は、従来的な感覚ではテストとは思えないかもしれませんが、テスターにとって大切な考え方を促進し、チームが協力して適切なソリューションの構築について考えるようにさせます。

キックオフミーティング

プロジェクトが本格的に始まる前に、すべての関係者を集めてプロジェクトの期待値を設定すると、非常に効果的です。ディスカッションの一環として、目標、タイムライン、役割を再確認することが重要です。

また、このミーティングは、それまでにわかったことをテストする機会にもなります。現行のプロジェクトドキュメントとアイデアをひととおり検討する準備をしましょう。時間がかかりすぎる無駄な手順に思えるかもしれませんが、ソリューションや想定外の領域に関する問題をその時点で特定できれば、後になって問題が明らかになるよりリスクとコストを低減できます。

徹底的に問題を検討し、疑問点を残らず議論する時間を確保しましょう。必要なフォローアップやアクションアイテムをドキュメント化します。こういった場での会話は、早期のバグレポートのようなものであり、時間と注意を割くのに価します。何より大事なのは、このプロセスに集中することです。議論に関心を向け、全面的に参加します。 

1つ注意点があります。キックオフミーティングの後、コードが書き始められるより前に、チームのメンバーがドキュメントの内容についてよく考え、質問できる時間とプロセスを用意します。大勢の人がいる会議室で最善の思考を尽くせるという人間ばかりではないので、このステップは重要です。比較的物静かなメンバーもプロセスに参加でき、意見が尊重されるような余地を設けましょう。

開発者テスト

ユーザーストーリーの作成時にテスト駆動型開発アプローチを採用すると、プロセスの一環としてテストを計画することを促進できます。テストチームと開発チームのメンバーが協力し、作業項目を完了とするときに必ず実行する必要があるテストをドキュメント化します。 

コードカバレッジを増やすため、開発チームは単体テストをビルドプロセスに組み込みます。開発チームの手を離れる前にエラーを捕捉できるよう、自動化された統合テストをビルドプロセスに組み込むこともできます。ビルドにエラーが入り込む前に発見できれば、それだけ迅速に問題を解決できる可能性も高まります。

早期プロトタイプによるデモ

テストをシフトレフトするもう1つの方法は、各方面のステークホルダーに向けて早期にデモを行い、フィードバックを得ることです。プロセスのいくつかの場面でデモを行うことができます。

最初のデモは枠組みだけの場合もあるでしょう。次に、完成したUIがあったりなかったりする小さな部分的機能のデモになるでしょう。最終的に、デモは完成した機能や製品のQA用ビルドに近くなるでしょう。

それぞれの段階で、プロジェクトの最初に出された疑問に立ち返ることができます。ソリューションは提案されたプロジェクトの問題を解決するか？ユーザーはこの製品でポジティブなエクスペリエンスを得られるか？ソリューションは文書化された要件を満たしているか？早期のフィードバックは、プロジェクトがゴールと目標を達成する軌道に乗っているかどうかの検証になります。

いつシフトレフトするべきか

シフトレフトする機会は、欠陥をいち早く検出する機会にほかなりません。テストを意識しながらプロジェクトを進め、すべてのメンバーが当事者として品質に取り組むチームは、当面の問題に対して適切なソリューションを開発できる可能性が飛躍的に高くなります。

適切なステークホルダーが適切なマインドセットを持ち、早期からプロジェクトの全期間にわたって質問を続けることで、チームの成功に向けた条件が整います。

Dee Ann Pizzicaは熱心で好奇心にあふれたソフトウェアテスターです。15年以上にわたって、さまざまな業界の顧客向けに、小規模からエンタープライズ規模まで、きわめて複雑なビジネスロジックを持つカスタムモバイルおよびWebアプリケーションをサポートしてきた経験があります。現在、Dee AnnはBRDのDirector of Engineeringとして勤務し、iOSおよびAndroid向け暗号通貨ウォレットに取り組む才能あるチームとコラボレートしています。

（この記事は、開発元Gurock社の Blog 「Shift Left: Testing from the Onset of the Project」2021年11月3日の翻訳記事です。）