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