ここ数年でアジャイル開発が広まり、小規模の新ビジネスの開発だけでなく、基幹系・大規模開発にまで広がってきています。その中で、システムの品質向上が課題となっていると思います。対策の1つとして「テストファースト」により、開発の前にテスト（ケース・コード）を実装して品質を確保していきますが、システムが提供するサービス全体の品質を確保するのは困難ではないでしょうか？
今回は、「テストファースト」の意味を拡張させ「シン・テストファースト」と題して、プロジェクト全体を品質面からリードする考え方を提示させて頂きました。ご興味のある方は、ぜひ実践してみてください。
テストファーストとは？
「テストファースト」という言葉は聞いたことがあると思います。テストファーストの情報を完結にまとめると、以下の内容になります。テストファーストとは、先にテストケースやテストコードを準備して、それが通るように開発をする手法です。「テスト駆動開発」パターンの１つに挙げられています。アジャイル開発において、あるスプリントで開発する機能を定義した際、先にテストケースやコードを実装しておき、そのテストが通るようにコードを書いていく手法です。
メリットとしては、バグを早期に検知できたり、機能設計⇒テスト設計と二度手間になりうる作業が一度に済んだりと、アジャイル開発に適している手法だと思います。
テスト実行をはじめて行うエンジニア向けのマニュアル型資料
テスト実施の基本とバク報告の書き方を解説
テスト実行者向け はじめてのガイドブック
アジャイル開発における品質課題
「テストファースト」によるシステム開発のメリットはありますが、同時にデメリットもあると思います。ウォーターフォールのように要件定義⇒設計⇒開発と積み上げる方式と異なるアジャイル開発では、システム全体の品質のコントロールが確保できない課題に直面する場面が多いと思います。例えば、機能単位の品質管理には適していると思いますが、テストファーストのデメリットとして、システム全体の品質を俯瞰的・網羅的に確保するには難しいのではないでしょうか？
また、非機能要件やユーザビリティといった機能レベルではない部分の品質の確保には適していないと思います。もちろん、「テストファースト」という手法でシステムのすべての品質を管理するのではなく、
一般的な品質管理手法との組み合わせで対応すると思いますので、上記の例は極端な話ではあります。
「シン・テストファースト」による品質管理
今回は、「テストファースト」の意味を拡張させ、プロジェクト全体の推進と品質管理に活用できる考え方「シン・テストファースト」を提起したいと思います。
- 方針
各工程で、品質管理で使われる手法を用いて、品質向上と同時にプロジェクト推進に貢献できます。品質管理面からのアプローチのため、広い意味で「テストファースト」という言葉を使わせて頂きました。
- 要件定義工程
開発するシステムがどんなサービスを提供するのかの業務要件はもちろん、非機能要件まで網羅する必要があります。いきなり要件をまとめようとしても、どこから手を付けていけばよいのかわからないという状況が多いのではないでしょうか。また、アジャイル開発であれば、動くものを作る作業が優先で、きちんと要件を整理するタイミングがないのではないでしょうか？このような状態で要件をまとめるために、テスト計画などで利用される「品質特性」を参考に、要件をまとめてみてはいかがでしょうか？
プロジェクト・プロダクト全体の品質を向上させ、デジタル改革を加速させます
バルテスの品質向上サービスのご紹介
「品質特性」とは、「ISO/IEC25010ソフトウェアの品質モデル」に定義されており、9つの特性で定義され、各々の特性に対して副特性が定義されています。なお、ISO/IEC 25010は2023年に改訂され（日本ではJIS X 25010:2025として制定）、特性の名称や構成が一部変更されています。
| 主特性 | 副特性 | 定義 |
| 機能適合性 | 機能完全性 | 明示された作業及び意図した利用者の目的の全てを網羅する、一組の機能を提供する製品の能力 |
| 機能正確性 | 意図した利用者が使用するとき、的確な結果を提供する製品の能力 | |
| 機能適切性 | 明示された作業及び目的の達成を促進する機能を提供する製品の能力 | |
| 性能効率性 | 時間効率性 | 応答時間及びスループット速度が要求事項を満たすように、明示された状況下で明示された機能を実行する製品の能力 |
| 資源効率性 | 明示された状況下で機能を実行する際に、明示された量以内で資源を使用する製品の能力 | |
| 容量満足性 | 製品のパラメータの最大限度に対する要求事項を満たす製品の能力 | |
| 互換性 | 共存性 | 他の製品と共通の環境及び資源を共有する間、他の製品に有害な影響を与えずに、要求された機能を効率的に実行する製品の能力 |
| 相互運用性 | 他の製品と情報を交換し、交換された情報を互いに使用する製品の能力 | |
| インタラクション容易性（旧：使用性） | 適度認識性 | 利用者のニーズに適していると利用者に認識される製品の能力 |
| 習得性 | 明示された利用者に、明示された時間内に製品の明示された機能の使用を学習させる製品の能力 | |
| 運用操作性 | 運用操作及び制御を容易にする機能及び属性を備えている製品の能力 | |
| ユーザーエラー防止性 | 運用操作エラーを防ぐ製品の能力 | |
| ユーザエンゲージメント（利用者関与性）（旧：ユーザインタフェース快美性） | 継続的なインタラクションを促すように、意欲を引き出し、動機付けるような方法で機能及び情報を提示する製品の能力 | |
| インクルーシビティ（包摂性） | 様々な背景の人々によって有効利用される製品の能力 | |
| ユーザ支援性（旧：アクセシビリティから分割） | 明示された利用状況において明示された目標を達成するために、幅広い範囲の特性及び能力をもつ人々に使用される製品の能力 | |
| 自己記述性 | 利用者が必要とする所で適切な情報を提示し、製品及び他の資源との過剰なインタラクションなしに、利用者に製品の能力及び使い方をすぐに分かるようにする製品の能力 | |
| 信頼性 | 無障害性（旧：成熟性） | 通常の運用時に障害なしに明示された機能を実行する製品の能力 |
| 可用性（アベイラビリティ） | 使用することを要求されたとき、運用可能及びアクセス可能となる製品の能力 | |
| 障害許容性（耐故障性） | ハードウェア又はソフトウェアの障害があっても、意図したとおりに稼働する製品の能力 | |
| 回復性 | 中断又は故障時に、直接的に影響を受けたデータを復旧し、システムを望ましい状態に復元する製品の能力 | |
| セキュリティ | 機密性 | アクセスを許可されているデータだけにアクセスできることを確実にする製品の能力 |
| インテグリティ | 悪意ある行為又はコンピュータエラーによる権限のない変更又は削除から、システム及びデータの状態を確実に保護する製品の能力 | |
| 否認防止性 | 事象又は行為が後になって否認されることがないように、行為又は事象が引き起こされたことを証明する製品の能力 | |
| 責任追及性 | ある実体の動作がその実体に対して一意に追跡されることを可能にする製品の能力 | |
| 真正性 | ある対象又は資源が主張されたとおり同一であることを証明する製品の能力 | |
| 耐攻撃性 | 悪意ある者からの攻撃を受けている間も、動作を維持する製品の能力 | |
| 保守性 | モジュール性 | 一つの構成要素に対する変更が他の構成要素に影響しないように制限する製品の能力 |
| 再利用性 | 複数のシステムで資産として使用される、又は他の資産の構築に使用される製品の能力 | |
| 解析性 | 欠陥若しくは故障の原因を診断するため、又は修正する部分を特定するために、製品の一つ以上の部分への意図した変更が製品に与える影響について、効果的及び効率的に総合評価される製品の能力 | |
| 修正性 | 欠陥を取り込むことなく又は既存の製品品質を低下させることなく、効果的及び効率的に修正される製品の能力 | |
| テスト可能性（試験性） | 要求事項が満たされているかどうかを判断するために、客観的かつ実行可能なテストを設計及び実行することを可能にする製品の能力 | |
| 柔軟性（旧：移植性） | 適応性 | 異なるハードウェア、ソフトウェア、又は他の運用環境若しくは利用環境に、効果的及び効率的に適応又は移行される製品の能力 |
| 拡張性 | ワークロードの増大若しくは縮小に対応する、又は変動に対応するために製品の容量満足性に適応する製品の能力 | |
| インストール性（設置性） | 明示された環境において、製品を効果的及び効率的に正常にインストール及び／又はアンインストールされる製品の能力 | |
| 置換性 | 同じ環境において、同じ目的のために他の明示された製品と置き換える製品の能力 | |
| 安全性 | 運用制約性 | 運用上の危険に遭遇したときに、安全面のパラメータの範囲内又は安全な状態内で、その運用を制約する製品の能力 |
| リスク識別性 | 許容できないリスクに生命、財産又は環境をさらす可能性のある、事象の経過又は運用操作の経緯を特定する製品の能力 | |
| フェールセーフ | 故障時に、製品が安全な動作モードに自動的に製品自身を移行する、又は安全な状態に復帰する製品の能力 | |
| 危険警告性 | 安全な運用を維持するように時間内で十分対応できるように、運用又は内部制御に対する許容できないリスクを警告する製品の能力 | |
| 統合時安全性 | 一つ以上のコンポーネントとの統合中及び統合後の安全性を維持する製品の能力 |
出典:出典：「JIS X 25010:2025（ISO/IEC 25010:2023）システム及びソフトウェア技術－システム及びソフトウェア製品の品質要求及び評価（SQuaRE）－製品品質モデル」
「品質特性」にある要件に対する「テスト」を定義することで、要件定義の代わりになりうると考えられます。例えば、「時間効率性」のテスト要件を決めれば、性能目標を決められます。「使用性」の各副特性に対して、テスト要件としてどこまで求めるかを定義すれば、ユーザビリティに対する要件を定義できます。
品質を高め、コストダウンができる効果を9つの事例でご紹介
テストアウトソーシングの効果とコストダウン実例ガイドブック
- 設計工程
詳細な設計書を作成しないアジャイル開発では、各機能やオブジェクトの仕様（入力制限など）は曖昧なまま実装が進んでしまう状況が多いと思います。本来の「テストファースト」でも、先にテストケースを作成する運用となっているため、ここでテストケース作成（またはテストコードの設計）を行います。実際にこのような手法を採用した場合、テストケース作成側では期待値を明確にしたいので、詳細な仕様の確認をする必要があります。
その際、テストエンジニアが開発者に確認しながら、仕様を詳細化・具体化していく作業が期待されます。品質管理としての手法としては「仕様書インスペクション」が活用できると思われます。本来は開発側の設計書の曖昧さや整合性をチェックする手法です。しかし、そのノウハウは「テストファースト」のテスト設計でも活用できると思います。
- テスト工程
要件定義、設計工程と、品質面から要件や仕様を明確にしてきています。それらをインプットとして、結合テストや総合テストのテスト設計を進めていくことができます。例えば、結合テストであれば、品質特性の「相互運用性」に対して整理した結果に基づき、テスト設計を進めることができます。また、総合テストでは、品質特性の「機能適切性」を基に、「明示された作業及び目的の達成を促進する機能を提供する製品の能力」の検証が可能となります。その他、非機能系のテストについても、様々な品質特性にて定義した内容からテスト設計を進めていくことができます。
例：
パフォーマンステスト：性能効率性
ユーザビリティテスト：インタラクション容易性（旧：使用性）
運用テスト：信頼性、保守性
まとめ
システム開発には様々なアプローチや手法があります。その中で、開発対象に適したアプローチの判断は困難であると思います。今回は、「シン・テストファースト」と銘打ち、テストファーストによる品質管理面からのアプローチの案の１つを提示させて頂きました。皆様のプロジェクト推進時の引き出しの１つとして活用頂ければ幸いです。
当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。
