DevOps時代のテスト要求分析

はじめに

こちらのエントリはソフトウェアテストAdvend Calendar2016の13日目の記事です。

qiita.com

ちなみに、昨日のエントリ、テスターがエンジニアとキャッキャウフフしながら文言指摘軽減を技術的に30分で解消したかもしれない話 - テストする人。は、キャッキャウフフしてる感じが楽しそうですね。

DevOps時代のテスト要求分析は難しい

　DevOps時代のテスト要求分析は難しい。それは、ウォーターフォール時代のテストで基本として使われていたVモデルによる従来のテスト戦略をそのまま適用することが出来ないからだ。これにはいくつかの理由がある。

（理由１）ビジネスの成熟度によってサービスやプロダクトに重要な品質が変化する
（理由２）開発中にシステムのアーキテクチャ設計が変化する

このブログエントリーでは、これらの理由を解説したのちDevOps時代のテスト要求分析の方向性について示す。

おさらい

　DevOps時代のテストの難しさについて述べる前に、テスト要求分析とVモデルについておさらいし、従来のテスト戦略に存在する暗黙の仮定を洗い出す。

テスト要求分析

　テスト要求分析は"テスト要求の源泉"を分析し"テスト要求"を洗い出すアクティビティだ[1]。「テスト観点を体系化」し、「テスト対象」と「テスト目的」を明らかにしていく。また、テスト活動を実施していく上でのビジネス要因やプロジェクトのリスクを洗い出したり、テスト対象のアーキテクチャを分析し、品質特性とテスト観点の紐付けを行ったりすることもここに含まれる。

　テスト要求分析の結果は、テストアーキテクチャ設計(*1)においてテスト戦略(*2)を決定していくことにに用いられる。

Vモデル

　Vモデルは、「要求分析」「設計」「コーディング」などの開発工程と、「受け入れテスト」「システムテスト」「単体テスト」などのテスト工程の対応関係を示すものだ。開発工程とテスト工程の対応関係により、それぞれのテスト工程の検証対象のスコープが明確化される[2]。ISTQBでは、「システムテスト」や「単体テスト」などの各テスト工程をテストレベルとしてまとめ、それぞれのレベルテスト計画を行うことを推奨している[3]。

従来のテスト戦略

　ウォーターフォールに基づく従来のテスト戦略では、これらのテストレベルを左から順に時系列で実施していくことが多かった。Vモデルと従来のテスト戦略の対応関係を下記の図に示す。

f:id:kokotatata:20161211124709p:plain

　この従来のテスト戦略に従いテスト活動を進めていくためには、３つの仮定が正しいことが暗黙的に求められる。

テスト活動開始以前にプロダクトやサービスを取り巻くビジネス要因が決定されており、テスト活動中にそれらが変更されないこと（仮定A）
テスト活動開始以前にプロダクトのアーキテクチャが決定されており、テスト活動中に変更されないこと（仮定B）
テスト活動開始以前にソースコードの変更が終了しており、テスト活動中には（バグ修正以外の目的では）変更されないこと（仮定C）

これら３つの仮定が正しい場合、ビジネスやアーキテクチャなどにまつわるリスクを固定化して考えることが出来るので、それ以外の要因、すなわちテスト対象のスコープを優先順位付けのための唯一の軸とすることができる。そのため、ウォーターフォール開発では、単体テスト→結合テスト→システムテストと、小さいテスト対象から大きなテスト対象へとスコープを広げていくテスト戦略が一般的になっている。

従来のテスト戦略がDevOpsでは使えない理由

　DevOpsにおいて従来のテスト戦略がそのまま使えない理由は単純だ。上述の仮定Aと仮定Bが正しくないからだ。それぞれ詳しくみてみる。

理由１：ビジネスの成熟度によってサービスやプロダクトに必要となる品質が変化する

　DevOps時代のビジネスでは、リーンスタートアップの考え方に代表されるように、ムダな要素を最小限に抑え、仮説検証を続けるビジネス開発手法が一般的だ[4]。ビジネスの成長に伴って、それぞれのビジネスのフェーズに一番価値のある部分にフォーカスする。下記にビジネスの成熟度とビジネスのフェーズの例を示す。

f:id:kokotatata:20161211132311p:plain

　ここで重要なことはビジネスフェーズが進むにつれてシステム開発でフォーカスすべき品質は変わってくることだ。たとえば、

スタートアップ期：プロダクトの最小限の機能性
ステップアップ期：プロダクトのユーザービリティ。ユーザーに安心して使ってもらうための信頼性やセキュリティなど
スケール期　　　：多数のユーザーに使ってもらうためのスケーラビリティやパフォーマンスなど
安定期　　　　　：コスト効率化のための運用性や効率性

といったように、求められる品質が変化していく。（もちろんこれらは例であり、求められる品質の変化はビジネスにより様々だ。）

　ビジネスフェーズが変わるごとに求められる品質が変化する、すなわち（仮定A）が成り立たないため、従来のテスト戦略の使用は困難となる。

理由２：開発中にシステムのアーキテクチャが変化する

　アジャイル開発では、システム開発中に要求変更を受け付けるのと同様に、アーキテクチャ設計もどんどん進化していく。これは「Evolutionary Design」として知られる[5]。そのため、新規機能と既存機能の結合テストや、アーキテクチャの変更に伴う品質特性のテストを適切なタイミングを計画し実施していく必要がある。

　下記に、各イテレーションにおける実装とテストの対応関係の例を示す。

f:id:kokotatata:20161211140342p:plain

　この例では、イテレーション１と３においてそれぞれ機能1と2を実装しているため、それぞれ対応するイテレーションでの機能テストを行っている。一方で、イテレーション２でセキュリティ強化を行っているため、イテレーション３で実施される機能２のテストよりも前にセキュリティテストを実施している。また、機能２のテストと機能１と２の結合テストが並行して実施されている。

　この図で示したいことは、時間軸上でアーキテクチャが変化する場合、テストは単純なVモデルの繰り返しではなく、複数のVモデルを考慮しなければならないということだ。そのため、単純に単体テストから受け入れテストへと進めていくことを前提とせず、しっかりと機能の結合やアーキテクチャ変更のタイミングも見据えたテスト要求を洗い出す必要がある。

DevOps時代のテスト要求分析の方向性

　これらの問題点を踏まえ、DevOps時代のテスト要求分析には以下の３点の方向性が重要になる。

ビジネス要因とアーキテクチャ設計の変化を時間軸上で捉えること
テスト戦略へのフィードバックを可能にすること
ビジネスやアーキテクチャ設計へのフィードバックを可能にすること

変化を時間軸上で捉える

　ここまで見てきたように、DevOps時代のテスト活動では、ビジネス要因やアーキテクチャ設計を固定として考えることはできない。これらは時間軸上で変化していくものとして捉え、変化に対応可能なようにテスト要求分析をしていく必要がある。

　たとえば、ビジネス要因では今後３年の事業計画から、３ヶ月くらいごとのテスト要求を導出することが考えられる。また、モノリシックからマイクロサービスへとアーキテクチャ設計を変化させる上で重要となる、回復性やデータ品質といった要求について優先順位を決め、どのタイミングでテストする必要があるかを考えていく。

テスト戦略へのフィードバック

　テスト戦略は一度作ったら終わりではなく随時改良していく必要があることが知られている。DevOps時代のテスト要求分析では、より積極的にテスト戦略改善のフィードバックを回していく。

　単純な例を挙げれば、計画当初は一度だけのセキュリティテスト実施を計画していたが、セキュリティテストの結果を踏まえ、セキュリティテストを自動化し以降のスプリントでも継続的に実行していくように戦略を変更する、といった事が考えられる。

　逆に、テスト実行に時間がかかるが、今までほとんどバグが検出されていないテストについて、優先順位の高い20%のみを実行するように変更する、といったケースも考えられるかもしれない。

　プロジェクトが進みプロダクトが大きくなるにつれて、たとえばテストケース数は膨れ上がり、テスト活動はどんどんコントロール不可能なものになるだろう。テスト活動をコントロール可能なものとして保つため、随時フィードバックよりテスト活動で起きている変化を把握し、テスト戦略を更新していく。

ビジネスやアーキテクチャ設計へのフィードバック

　DevOpsでは「本番からのフィードバック」が大切な事が指摘されている[6]。チームが継続的に「要求的にもアーキテクチャ的にも学びを得る」ことによって、プロダクトを成長させる。

　DevOps時代では、テストもビジネスやアーキテクチャ設計へと直接フィードバックを回していく事が求められる。そのため、ビジネスやアーキテクチャ設計への学びがテスト要求にも入ってくるはずだ。

　ベータテストやABテストなどは、テストからビジネスへのフィードバックの典型的な例だ。新バージョンの本運用に入る前に、小規模のユーザーに試験的に使ってもらい、そこで得たフィードバックを本運用前に改善する。

　また、本番運用での学びを積極的に採用できないセキュリティなどのケースでは、依然、きちんとしたテスト環境で破壊的なテストを実施し、アーキテクチャ設計にフィードバックする事が求められる。

まとめ

　DevOps時代のテスト要求分析が難しい理由を、従来のVモデルにもとづいたテスト戦略から考察した。また、今後のテスト要求分析の方向性を３つ示した。

　ここで大事な事は、DevOps時代には「プロダクトの価値」が時間軸上で変化する事だ。そのため、テスト要求分析もしっかりと時間軸上での変化を捉える必要がある。また、テスト活動やビジネス、アーキテクチャの変化をリアルタイムで把握し、フィードバックループを作っていくことも重要になる。

注意

(*1)(*2)このブログエントリでは専門家以外の分かりやすさ重視のため、「テストアーキテクチャ設計」と「テスト戦略」を同義語として扱っています。「テストアーキテクチャ設計」の詳細についてはQAアーキテクチャの設計による説明責任の高いテスト・品質保証をご参照下さい[7]。

Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア（Automation Architect）のブログです。