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

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

品質保証はもはや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 と覚えておきましょう。

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

本記事で、概念理解・そしてアジャイルが確立されたチームではどのようにプロジェクトのサイクル全体にテスト工程がまんべんなく採用されているかの情報になれば幸いです。

質問は問合せフォームまたはsa_cs@shiftasia.comまでお願いいたします。

記事一覧へ