シフトレフト・ライトのテストアプローチで何ができる?

シフトレフト・ライトのテストアプローチで何ができる?

品質保証はもはやQAチームの責任ではない

アジャイル開発では特に、品質保証活動を前倒しする「シフトレフト(Shift-left)」と、後ろ倒しする「シフトライト(Shift-right)」という概念があります。本記事ではそれぞれの説明とどちらをどう採用すべきかを、従来のウォーターフォールモデルにおけるテストと比較しながらご説明します。

・旧来のウォーターフォールモデルにおけるテストの立ち位置

旧来のウォーターフォールモデルでは、「テスト活動」は開発ライフサイクルの最後の工程に位置し動的テストに比重をおいていました。そのため最後のテストの段階になって、初めて「要件が不明瞭」「仕様バグ」「設計バグ」といった手戻りコストが高い事象が発生しがちでした。それに伴いリリースまでの工期も長くなることも課題にあげられます。

そこに追い打ちをかけるように、モバイルファーストな世の中において、機能のリリースや修正の頻度があがり、ウォーターフォール型では対応しきれなくなったのです。

そこで近年登場したのがアジャイル、そしてDevOpsです。
これらをすでに採用されている組織は多数存在していますが、アジャイルに移行したからといってテストスキームがチーム間で共有されていなければ意味がありません。
ウォーターフォール型では時系列に沿って左から右へとプロジェクトが進行しますが、それを念頭においてシフトレフト・シフトライトの話をしましょう。

シフトレフトテスト(Shift-left testing)とは?

シフトレフトテスト(Shift-left testing)は、より早く、より頻繁にテストを行うべきという概念であり、開発ライフサイクルの早い段階で「テスト活動」を実施することを言います。
この概念は、多くの企業がアジャイルソフトウェア開発やDevOpsを採用するようになると共に再注目されてきました。

過去には静的テストが軽視されてきた傾向があり、その逆を行く取り組みを指しますが、具体的にはどのようなことを行うのでしょうか。
未然にバグを防ぐ目的で、静的テスト(要件定義書や仕様書、設計書などのドキュメントレビュー)と合わせて動的テストを早期に行います。
そして早い段階でフィードバックを実施することで、テスト工程における要件や仕様、設計書の確認といった工期の削減や、要件・仕様の誤認識による大きな手戻り防止、ひいてはソフトウェア品質の向上につながります。

つまり、旧来のウォーターフォールモデルが抱えている問題の解決につながってくるのです。

シフトライトテスト(Shift-right testing)とは?

品質保証活動を前倒しする「シフトレフト(Shift-left)」に対して、「シフトライト(Shift-right)」はテストをサイクルの後ろで行うことを指し、リリース後も継続的に品質保証活動を続けていくというアプローチです。
製品のリリース後にもユーザビリティデータやフィードバックを収集し、絶え間無く改善や新機能のリリースを継続しユーザーの満足度を高めることで、ユーザーにサービスを利用し続けてもらうことを目的とします。

結局どちらを採用するべき?

Shift-left = Test Early / Shift-right = Test Post-Deployment と覚えておきましょう。

シフトレフト・シフトライトのどちらを採用するべきかという議論がありますが、これらは相反する手法ではなく、プロジェクトの特性によってどちらか、もしくは両方を選択することでメリットを享受していくことが必要です。
品質保証活動の前倒しをすることで効率的なテストを実施することを可能とし、そのための時間と労力の削減を目的としている「シフトレフト」と、スピード感をもったユーザエクスペリエンスの向上を目的としている「シフトライト」では、そもそもの目的が異なるという点がポイントとなります。

本記事がシフトレフト・シフトライトの概念理解と、アジャイルが確立されたチームではどのようにプロジェクトのサイクル全体にテスト工程が採用されているかの参考となれば幸いです。

ソフトウェアテストに関するご相談がありましたら、お問い合わせよりお気軽にご連絡ください。