BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース テストピラミッドを使って品質を左シフトする

テストピラミッドを使って品質を左シフトする

原文(投稿日:2021/05/06)へのリンク

品質の左シフト(前倒し)とは、開発終了後に品質テストを行うのではなく、ソフトウェア開発サイクルの早期に品質を作り込む、という意味である。テストピラミッドモデルを使うことで、テストをより早いステージに移動させることが可能になり、統合時に問題となる欠陥を開発早期に発見することが可能になる。

ThoughtWorksでリードクオリティアナリストを務めるHaritha Hari氏は、ConTEST 2021で、品質の左シフトについて講演した。

システムに品質を組み込むというのは、コミットするすべてのコードが製品品質であるという意味であり、それによってテストに要する追加的作業が不要になるという意味だ、とHaritha氏は主張する。

その企業は、開発が完了したシステムがエンドツーエンドで動作しないという、統合面での問題に直面していた。このようなプロダクト提供の遅延を回避するには、最初から統合の問題に対処しておく必要がある。これを可能にする方法は、設計フェーズからテストを開始するという、テストの左シフト(shift-left testing)以外にあり得ない、とHaritha氏は言う。

テストの左シフトというこの原則にアプローチする現実的手段として、この企業では、テストピラミッドモデルのテスト戦略を採用した。テストピラミッドモデルでは、ユニットや統合など異なったレベルの全テストに対して、エンドツーエンドのテストと同じ優先度を適用する。

数百件のテストが、信頼性のない、コードへのフィードバックが何もないものだった、とHeritha氏は言う。そのため、利用可能なエンドツーエンドテストを他の全テストと比較調査する作業が行われた。この調査の結果から、エンドツーエンドテストで対象としているテストケース中の多数が、実はすでにユニット統合テストに含まれていて、実施するメリットのないことが判明したため、それらのエンドツーエンドテストを問題なく削除することができた。

テストピラミッドモデルに残ったエンドツーエンドテストに対しては、さらなる分析を実施して、テストピラミッドの適切なレイヤ用に書き直すことで、テストカバレッジが良好であることを確認した。これにより、システム全体をカバーするユーザフローの観点から、エンドツーエンドの機能的カバレッジというメリットを提供するという、本来の目的を果たすことのできるエンドツーエンドテストのみを残すことができた、とHaritha氏は述べている。

この経験からHatitha氏は、何らかの変更を行う前には、現行作業の負担をある程度軽減して、新たな変更に対応する余裕を確保しておくことが重要であると学んだ、と講演で話している。

このケースでは、数百件のエンドツーエンドテストを維持することが負担であったため、不要なテストを特定してその数を減らしたことで、バックログの見直しや障害分析といったプロセスにチームが興味を示してくれるようになったのだ。

品質の左シフトについて、Haritha Hari氏にインタビューした。

InfoQ: その企業が直面していた品質に影響する問題というのは、どのようなものだったのでしょう?

Haritha Hari: そのプロジェクトでは、開発ステージにアジャイルを使用していたのですが、テストに関しては、機能開発が完了するまでテスタの出番がないという、従来型のウォーターフォールモデルを使用していたのです。

テストは2つのステージに分割されていました。最初のものはプロジェクトテストと呼ばれていて、エンドツーエンドテストと手作業によるテストで外部システムのモックを行っていました。そのため、製品リリース間際に実施されるテストの第2ステージまで、システム統合に関する問題が表面化しなかったのです。この第2ステージは、プロジェクトテストが終わった後、実際のシステムでモックを置き換えた製品リリースの間際に行われていました。

アジャイルの中でテストのみウォーターフォールを維持していたことが、障害特定の遅れを発生させ、分析と開発が繰り返されることになり、市場へのタイムリな製品投入に影響を与えていたのです。

InfoQ: アジャイルに対して、どのような誤解があって、どう対処したのでしょうか?

Haritha: レトロスペクティブやスタンドアップといったアジャイルのセレモニが、目的を完全に理解しないまま実施されている状態だったのです。チームはスプリントのベロシティを重視していたため、改善に時間を費やすことには後ろ向きでした。

アジャイルに関しても、十分な分析を行わずに多くのスコープをランダムに取り入れる方法、と理解していました。バックログの見直しセッションや障害の優先順位設定ミーティングを増やすことで、このアプローチを修正する必要があったのです。

また、アジャイルアプローチが開発分野以外に適用されていなかったため、テスタはチームの他の部分から離れて作業することが多くなっていました。これについては、物理的に近い場所にチームを配置して、アイスブレーカー(ice breaker)セッションを行うことで、チーム内のコラボレーションを改善しました。

さらに、キックオフセッションやローカルデスクチェックを重視することで、このコラボレーションをさらに改善し、テストをプロジェクトに一歩近付けることができたのです。

InfoQ: どのようなことを学びましたか?

Haritha: 新しいプロジェクトにテストの左シフトを導入するのは、長く続いている既存プロジェクトに導入することに比較すれば簡単です。数百件のエンドツーエンドテストをユニットテストや統合テストに分解する変更を取り入れようとした時には、テストを左シフトするアプローチやテストピラミッドモデルに対する理解不足のため、多くの反発を受けることになりました。

このことから、変更を実施する前に、コーチングやトレーニングが必要であると認識するに至ったのです。コーチングは、テストの左シフトとテスト戦略を中心に行いました。

InfoQ: 破壊的な変更(disruptive change)を効率的に行うには、どのようにすればよいのでしょうか?

Haritha: 常に重要なのは、メンバが変更について理解することと、その必要性をメンバに教えることです。最初にプロジェクトの小さな部分で試す、というのが、破壊的変更を実施する上では最善の方法です。その変更が作業全体に対してポジティブな影響力を持っていれば、新しいやり方について支持してもらうのはずっと簡単になるのです。

この記事に星をつける

おすすめ度
スタイル

BT