2023.03.27
本コラムはテスト分析手法「ゆもつよメソッド」で有名な湯本 剛氏（freee株式会社／株式会社ytte Lab）による連載コンテンツです。
湯本氏のnote「テストマネジメント虎の巻」はこちら
第1回：いまどきのソフトウェア開発に求められるもの 第2回：新しい開発スタイルの概要 第3回：新しい開発スタイルに合わせたテストの概要 第4回：開発チームとテストチームの関係～成功のための大事な役割～ 第5回：品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い 第6回：テストレベル間のテスト量の関係は？テストピラミッドとの関係も
これまでの連載では、「ビジネスの成功に貢献するソフトウェアを作るためにはトライアルアンドエラーを行うことが大事であること」「トライアルアンドエラーを実現するためには、開発スピードが大事になること」「これらを実現させるために出てきた代表的な４つの開発スタイルはどのようなものか」を説明してきました。
今回からは、これらの開発スタイルに合わせて行うソフトウェアテストはどうあるべきかを説明していきます。
- もくじ
1．テストの変わらないことと変わること
代表的なテストのアプローチとしては、V字モデルで表現される、ユニットテスト、統合テスト、システムテストといったようにテストレベルを分けて段階的にテストを積み上げる方法があります。この考え方は今でも有効ですし、これからも有効でしょう。
ユニットテストを行い、ユニットレベルでのバグを見つけたら、それを直してからそれぞれを統合していったほうが効率的なことに変わりはありません。ただ、V字モデルは、各テストレベルで行うテスト量については言及していません。テストレベルごとのテスト量がこれからの開発スタイルに適合させていくテストのアプローチのポイントになっていきます。
テストのプロセスは、JSTQBのシラバス(※1)にて、「テスト計画」「テスト分析」「テスト設計」「テスト実装」「テスト実行」「テスト完了」という活動が時系列的に必要だと記されており、これらの活動を通して、「テストのモニタリングとコントロール」というマネジメント活動が必要だとされています。このテストプロセスも変わりません。
ただし、それぞれの活動をどの程度の時間を費やして行うかがこれからの開発スタイルに適合させるための考慮事項になってきます。
また、JSTQBのシラバスでは、いつの時代も変わらない、テストに関する７つの原則があると言われていますので以下に列挙します。
＜テストの７原則＞
・テストは欠陥があることは示せるが、欠陥がないことは示せない
・全数テストは不可能
・早期テストで時間とコストを節約
・欠陥の偏在
・殺虫剤のパラドックスにご用心
・テストは状況（context）次第
・「バグゼロ」の落とし穴
これらの原則の解説はJSTQBのシラバスを参照していただきたいのですが、これらの原則の中にある「テストは状況（context）次第」が、テストのやり方を新しい開発に合わせていくべきであることを謳っています。コンテキストに合わせるとは、例えばどんなことなのか、前回取り上げた代表的な開発スタイルを例にして見ていきたいと思います。
※１ テスト技術者資格制度Foundation LevelシラバスVersion 2018.J03
http://jstqb.jp/syllabus.html#syllabus_foundation
オープンソースを活用した開発の際にテストで考慮すべきこと
オープンソースの活用の特徴としては、必要となるプラットフォームやライブラリなどで全てを自分たちで開発しなくても済むようにして、開発のスピードを上げることが考えられます。ただし、オープンソースは、自分たちの開発とは別サイクルで日々更新されていきます。最新バージョンを適用させた後に、常にリグレッションテストが必要になります。リグレッションテストを効率的にやらないとコストも時間も余計にかかってしまい、オープンソースを活用したメリットを帳消しにしてしまいます。
アジャイル開発を活用した開発の際にテストで考慮すべきこと
アジャイル開発の特徴としては、ビジネス側の人と開発側の人でお互いの垣根を超えた数名からなるチームを形成し、そのチームが主体となって微調整を繰り返しながら開発を進めていきます。テストを行う際は、微調整していることを常に意識合わせしながらテストしていく必要があります。
完成した仕様書をベースにテストケースをしっかり準備してからテストしていてはスピードが落ちてしまい、テストがボトルネックになってしまいます。また、少しずつ開発を進めるということは、ここでも常にリグレッションテストが必要になるということです。リグレッションテストのアプローチ次第で効率的にも非効率的にもなります。
クラウドを活用した開発の際にテストで考慮すべきこと
クラウド活用の特徴は、クラウド上で全て完結できるところです。つまり、本番で使われているプログラムやデータが全て同じクラウド上にあります。この本番環境にあるものを使ったテストをやっていくことが、クラウドを使って得られるスピードを台無しにしないテストになっていきます。例えば、性能テストや障害復旧のテストのために他の環境を作るのではなく、本番環境で行うことが該当します。また、フィーチャートグルを使った機能テストも有効です。
フィーチャートグルとは、メイントラックに開発したプログラムを統合しつつも、開発中の機能へ入っていける実行経路をOFF（使えない状態）にするスイッチとなる機構のことです。これにより開発者たちは、テストが終わっていない機能を含んだバージョンを本番リリースすることが可能になります。フィーチャートグルをOFFすることによってそれらの機能は隠されるので、ユーザインタフェース上には表示されません。
これにより、日常的にブランチやマージする労力を払うことなく、多くの小さな変更ごとにソフトウェアのバージョンを刻みながら、常にリリースすることが可能になりますし、限定的な経路でONにすることで、本番環境でその機能をテストすることが可能になります。
また、他のSaaSの活用、連携を行う機会も出てきます。その際の連携のテストでは、いきなり他のSaaSに接続するのではなく、スタブを使ったテストを最初に行うことになります。近年、これらのスタブは「Service Virtualization（サービス仮想化）ツール」と呼ばれます。
マイクロサービスアーキテクチャーを活用した開発の際にテストで考慮すべきこと
マイクロサービスアーキテクチャーでは、カナリアリリースによって迅速なトライアルアンドエラーができるようになりますが、カナリアリリースの際には、前述したフィーチャートグルを使ったテストが必要になります。
また、マイクロサービス間の結合をなるべく少なくすることも特徴としてあげられますが、この結合点は、マイクロサービス間の整合性を保つためにも重要な意味を持つので、結合点の保証をしている機構を重点的にテストするといったことが必要になります。
2．テストはどう変わるべきか
以上、開発スタイルの変化に合わせた具体的な例として、どのようにテストが変わるかをいくつか紹介してきました。
ただし、このまま個別の例を続けてあげていくよりも、ビジネスの成功に貢献するという本来の目的を意識しながら、これからの開発に役立つソフトウェアテストはどうなるべきかを考えてくことのほうが重要になると思います。筆者は、大きく以下の４つに分類できると考えています。
開発チームとテストチームの関係
「QAが行うようなテストは別チームにやってもらうというアプローチ」から「開発チームにQAが内在するアプローチ（QAが行うテストは開発チームにて行う）」にする。
品質リスクの許容度合い
「トラディショナルな品質リスクの許容度合い」から「いまどきの品質リスク許容度合い（すぐに修正リリースできる欠陥は許容する）」にする。
テストレベル間のテスト量の関係
「ビッグバンテスト（リリース前に大量にテストをする）」から「予防テスト（リリース直前に欠陥修正により手戻りが最小限になるようテストをする）」にする。
QA（Quality Assurance）の考え方
「品質保証的判断（リリース可能な品質であることを様々な証拠をもとに第三者が判断する）」から「継続的品質改善（リリースとは関係なく常にチーム全員が品質をよくしていく）」にする。
それぞれに対して、一言ずつの説明では、十分に意図が伝わらないと思います。
次回からは、ここであげた４つの「テストはどう変わるべきか」に関して、1つずつ深掘りしていきたいと思います。
