開発とテストの段取りを工夫する

はじめに

本連載は開発を加速・効率化させる「ソフトウェアテスト」がメインテーマです。前回はこのテーマを実現するための全体的な戦略やアプローチを解説しました。今回は、そういった戦略やアプローチを考えるための、テストの種類や区分けを俯瞰的に解説していきます。

開発との関係から見るテストの役割

ソフトウェアテストは、テスト対象とテストベース（仕様書、設計書などテストのための資料）を入力にテストを実施し、そこで得た情報をフィードバックしてアクションを促す活動です。このフィードバックサイクルは、主にテストと開発（今回は上流工程からプログラミングまでの活動を指す言葉として用います）で回していきます。

テストのフィードバックサイクルは、主に次の点で開発に貢献します。

• ソフトウェアの欠陥を見つけ、その修正を促し品質向上に貢献する
• 限定的な範囲内（仕様書との合致性の確認など）で欠陥が見つからないことを確認し、品質保証を支援する
• 欠陥の傾向を収集し、各種改善活動の評価などマネジメント上の判断を支援する
• テストの分析・設計を通して、テストベースの誤り・不足を見つけ、その改善を促す
• テストによって設計や仕様を明示化し、以降の開発を駆動させる（テスト駆動開発）

この開発とテストのフィードバックサイクルは、開発の最初から最後まで様々な粒度で出てきます。例えば、開発初期でも次のようなサイクルを回せます。

• テストの分析・設計を通じて、ドキュメントの不足・誤りの情報をフィードバックする
• プロトタイプのテストや早期リリースのユーザテストを通じて、新たな要求を見つけ開発にフィードバックする

このように、開発とテストは様々な部分で紐づいていると言えます。

開発を包含したテストの戦略的アプローチの必要性

開発とテストが密接に絡んでいることから、現場のテストでは、開発・テストを横断した対応がよく求められます。

例えば、ソフトウェアテストは開発より優先度を下げられがちなため、しばしば次のような開発起因の制約に悩まされます。

• テストのスケジュールやコスト不足
  テストは開発の遅延や手戻り等の頻発により、期間やコストが途中から削減されがちです。
• テストの人的リソースの不足
  「テストより開発が重要」という判断を極端に推進した結果、テストリソースの人数やスキルレベルが不足してしまうことがたびたびあります。これは有効なテストの自動化が導入不能になるといった問題を生み出します。
• テストを軽視したプロセス
  開発偏重でテストに必要なドキュメントを十分に作らなかったり、テストの計画や分析・上流設計をスキップしたりすることがあります。この粗悪なドキュメント・不十分なテスト設計は、テストケースのヌケ・モレを生じさせます。
• テスタビリティの欠落
  テストを考慮せずに設計・実装した結果、不当にテストの手間が増えたり、実施すべきテストの自動化が困難になったりします。

こういった制約は品質問題を多発させ、プロジェクト全体の生産性を悪化させるものですが、テスト内の閉じた改善では対応が困難です。プロジェクトの最初からテスタビリティを考慮してもらう、費用対効果を評価したうえでテスト自動化に開発リソースを投入してもらう、といったテスト・開発を横断する戦略的なアプローチが求められるのです。

戦略的アプローチを工夫する

開発とテストを横断する戦略的アプローチの基本形となるものの1つに、「品質リスクに基づいたリスクマネジメント」があります。顧客に関わる品質リスクを識別し、リスクベースドテストなどの手段でリスクコントロールを行うアプローチです。

このリスクマネジメントは普遍的に使われるアプローチですが、実践形態は多様です。例えば、医療機器といった高信頼性ソフトウェア開発では、法規制に基づいた厳格なプロセスで明示的にリスク分析とコントロールを管理します。スピードを優先する開発では、ユーザストーリの優先付けやKPT（Keep（良かったこと）・Problem（悪かったこと）・Try（次に試すこと）を視点に改善を進める手法）による課題分析といった、エンジニア主体の軽快なプラクティスで実現します。

ただ、形態は様々でも、品質リスクに対応するためにテストや関連活動の段取りに工夫が求められる点は共通しています。以降では、そのテストの段取りの工夫について解説していきます。

実現すべき品質を知る

開発とテストの連携では、第一に「プロジェクト全体でどのような品質を確保すべきか」の品質要求の分析が重要です。そして、その全体像を土台にテストが果たすべき責務（＝テスト要求）を検討していくことになります。全体とテストの関わりを明確化することで、様々な品質確保手段をどう組み合わせていくか検討しやすくなります。

この品質要求の分析では、全体を俯瞰的・抽象的に扱える分析アプローチが求められます。これには、ISO 25010といった品質モデルを使って整理する方法や、ユーザストーリーマッピングやMoSCoW分析で品質要求をグルーピングする方法などがあります。

またアーキテクチャレベルで品質要求を分割し、別々に分析可能にするアプローチも品質要求の全体を扱う工夫として有効です。例えば課金システムや個人情報管理などハイリスクな責務のインフラとローリスクのサービスを設計で分離して、各品質確保の厚みや方針を別々に考えられるようにするといったものです。

注意点として、ここでいう品質要求はウォーターフォール的に上流で確定できるものではありません。開発中にも品質リスクが顕在化したり変わったりしますし、品質確保手段の適切な組み合わせも開発中の試行錯誤や状況変化に応じて変わります。品質要求の全体像を分析し、それに対して品質確保手段の組み合わせを工夫していく姿勢は、開発を高速化するためには開発の最初から最後まで求められます。

段取り（分業、重ね合わせ、横断的最適化）を工夫する

品質要求に対しては、様々な品質確保の活動の組み合わせで対応していくことなります。この組み合わせは、主に「分業」「重ね合わせ」「横断的最適化」の3パターンを取ります。

• 分業：品質確保の責務を分担し、責務を果たせるまで作業を調整する
• 重ね合わせ：品質確保の仕組みを何重も組み合わせて、難しい品質確保を実現する
• 横断的最適化：全体の生産性が最大になるようにプロジェクト内で協力し、シナジーを確保する

具体例として、車載機器のネットワーク機能のセキュリティ確保を例に挙げます。セキュリティ機能は一般的に品質確保の難易度が高いため、分業・重ね合わせ・横断的最適化の段取りが求められます。例えば、しばしば次のような戦略が必要となります。

• 暗号化テスト、認証テスト、XSS検査など、後述するテストタイプを単位に分業し、チームの専門性を発揮しやすくする
• スタックオーバーランを防ぐという1つの目的に対して、設計で回避対策を導入／静的解析で構造的なリスクを検出／ユニットテストで動的に発生を監視、と品質確保手段を重ね合わせてセキュリティリスクを大きく軽減する
• 設計でセキュリティテストツールを導入できるようにテストインターフェースを確保する／テストでセキュリティテストツールを使って自動テストを実施する、と設計とテストで横断的最適化を行い、効率的にセキュリティリスクを下げていく

このように、難易度の高いテストで高速化を行うためには、設計・実装・テスト・レビューなど様々な活動の分業・重ね合わせ・相互協力が重要になります。

段取りを構成するテスト活動の部品

品質確保の分業、重ね合わせでは、さまざまなテストや評価、検証活動を組み合わせることになります。例えば、次のようなものです。

• 設計を対象にした活動
  ドキュメントレビュー、モデル検査、形式的証明、モデル駆動テスト、DSLの構文解析など
• コードを対象にした活動
  コードレビュー、コンポーネントテスト、静的解析、動的解析など

段取りの工夫では、これらの活動をさらに細かく区分けして検討します。以降では、戦略的アプローチを考える際に有用なソフトウェアテストの区分けをいくつか紹介します。

テストレベル

前回も触れましたが、コンポーネントテスト、結合テスト、システムテストといったテストレベルは、開発・テストを跨った段取りを考える上で有効です。テストレベルは開発の活動と連動している点、開発高速化の点で異なる長所・短所を持つ点の2つがその理由です。

例えば、システムテストといった高位のテストレベルは顧客視点の品質をテストしやすいですが、ユーザ要求やUIの変更に弱くなるほか、テストに時間がかかったり、自動化が困難だったりします。コンポーネントテストといった下位のテストレベルは軽快で開発中でも実施できますが、一方でテストがソフトウェア構造に強結合して構造的変更に弱くなります。また顧客視点の品質を直接テストしにくいといった制約があります。これらの長所・短所は、品質要求やプロジェクトの制約に応じて伸ばしたり補ったりする必要があります。

例えば、段取りの場合では、アジャイルテストでのテストピラミッドで低コストのコンポーネントテストの責務を増やし高コストのシステムテストといった上位テストレベルの責務を減らすことでROIの改善を目指しています。

またテスト自動化を推進する場合では、アーキテクチャレベルでのテスタビリティを作りこんだ上で自動化した結合テストの責務を増やし、テストの保守性を高める工夫がしばしば採用されます。

スクリプトテストと探索的テスト

開発の高速化では、「スクリプトテスト」と「探索的テスト」の区分けも重要な段取りです。

ここでいうスクリプトテストとは、テスト手順を文書化し、テスト手順書のとおりにテストを実施するアプローチです。一方、探索的テストはテスト手順を文書化せず、テストエンジニアがテスト実施で情報を得ながら柔軟にテスト手順を構築するアプローチです。探索的テストには程度のバリエーションがあり、例えば抽象的なテストケースや大まかなテスト方針を明文化するチャータベースのものから、すべてテスト実施者の自己判断に任せるフリースタイルのものまであります。（「はじめて学ぶソフトウェアのテスト技法」リー・コープランド（日経BP社刊））

開発高速化の点でスクリプトテストと探索的テストは長所・短所が異なるため、段取りを工夫する余地があります。探索的テストはスクリプトテストより仕様変更やあいまいな仕様にも柔軟・高速に対応できる一方で、テストの効果が属人的、テストの網羅性・十分性を評価しにくいといったデメリットがあります。

こうした特徴から、例えばアジャイル開発では、次のような段取りで変化を許容する高速開発を支えることが多いです。

• 短期で済ませる個々のイテレーションのテストでは、自動化したスクリプトテストと探索的テストによるユーザストーリテストを実施
• リリース段階など、より大きなサイクルで上記を補うスクリプトテストを実施

テストタイプ

「テストタイプ」は、開発成果物とテストの関連付けを検討するのに役立ちます。テストタイプは、テストで着目する特性やテスト設計アプローチでテストを区分けしたものです（より具体的な定義がいくつかありますが今回は割愛します）。例えば、機能テスト・ユーザビリティテスト・ストレステスト・障害復旧テスト・アクセシビリティテストといった区分けはテストタイプです。

まとまったテスト設計アプローチをテストタイプで分けて区別することで、テストタイプは分業を検討する際に活用できます。

また、テストタイプはテスト技術の蓄積・整理にも役立ちます。蓄積・整理とは、例えばサーバ障害の監視、サーバ障害の注入、典型的なサーバ障害のリスクリスト、障害テストのテスト設計手法などの知見を「サーバ障害テスト」といったテストタイプでまとめ、それらのテストタイプのセットをチームのテスト技術として蓄積するというものです。整理されたテストタイプのセットは、テストチームの技術の蓄積を支援します。また、テスト分析の観点として用いたり、外部のテストタイプリストと比較して自分たちのテスト技術の不足や偏りを評価したりすることも可能になります。

テストプロセス

「テストプロセス」も段取りを工夫すべき区分けです。テストプロセスは、テスト分析、テスト設計、テスト実装といったテスト活動のプロセスです。

テストプロセスで段取りを考えると、テストの流れや、テストと開発の関係が検討しやすくなります。例えば、開発プロセスとテストプロセスを並行させて上流からテスタビリティを確保するWモデルの導入を考えることができます。

また、品質要求の分析やテストの責務を考える上では、テスト分析や上位設計といったテストプロセスの上流活動が重要になります。テストプロセスでの段取りの検討は、そのテストの上流活動の必要性を強調・認知させるのにも有効です。

おわりに

今回は、段取りを構成するテスト活動の部品について解説しました。まとめると、「開発・テストを横断したプロジェクト全体で、分業・重ね合わせ・横断的最適化と言った戦略的アプローチが求められる」ということです。

次回以降は、これまでに解説したテスト戦略の実践例を紹介したのち、今回紹介したテスト活動の部品の詳細を深掘りしていきます。