改めてテスト分析について考える

テスト分析について言語化して他人に説明できるようにするため、改めてテスト分析についてまとめておこうと思います。

この記事への指摘、ツッコミなどは歓迎です。

JSTQB Fundation Level 2018V3.1.J03でのテスト分析の定義

少し前のシラバスですが、2018年のシラバスでは、テスト分析の定義を以下のように説明していました。

テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定する

ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03

 

これはテスト分析を説明している文章の冒頭の抜き出しになるため、これだけがテスト分析の作業ではありません。

この文章は、若干、意味が取りづらい文章であるため、単純に「何をテストするか」を考える作業がテスト分析であると紹介されることもあると思います。

特に1文目の意味が取りづらいのだと思いますが、改めて1文目を丁寧に理解できるようにまとめようと思います。

 

テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。

この文章の最初の1文を読み解くと、以下の様になっています。

• やること
  • テストベースを分析する
• 目的
  • テスト可能なフィーチャーを識別する
  • テスト条件を決める

つまり、テスト分析での実施内容としてはテストベースを分析することになるのですが、テストベースを分析する際には、「テスト可能なフィーチャーは何か？」、「そのフィーチャーのテスト条件は何か？」という2点を意識することが重要になります。

フィーチャーとは？

フィーチャー(Feature)は一般的な英単語であり、日本語訳は「特徴」、「特性」、「機能」などと訳される事が多いです。

どれも間違ってはいないのですが、以下に私が目についたソフトウェア関係の書籍でどのように定義しているかを紹介していきます。

Feature

製品差別化特徴, 特質, フィーチャ
〈使用者に対して直接的価値を生む小規模な機能単位〉

ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―

［訳注］フィーチャは、ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉として使っている。要求仕様、機能要件、大機能、ユースケースといった言葉が指すものとよく似ているが、決定的な違いは、ソフトウェアを使う側の視点から記述している点である。フィーチャはユーザにとっての価値なので、たとえば性能目標やセキュリティといったいわゆる非機能要件も含まれる。

アジャイルサムライ――達人開発者への道

 

つまり、使用者側から見た特徴や、機能であり、非機能的な話も含まれることがあるということです。画面レイアウトや使用性、性能、セキュリティの観点など、すべてフィーチャーと捉えることができると思います。

なお、この2つの書籍はISTQBの書籍として引用されているわけではありません。
より厳密な定義されている書籍があるかもしれませんので、これらの定義は参考として捉えてください。

また、JSTQBのシラバスでは「テスト可能なフィーチャー」（英語の原文：testable feature）となっていますが、大抵のフィーチャーはテスト可能なものになると思っています。

テスト条件とは？

フィーチャーを識別したあとは、そのフィーチャーのテスト条件を考えます。

JSTQB用語では、テスト条件は以下のように定義しています。

テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
(英語：A testable aspect of a component or system identified as a basis for testing.)

https://glossary.istqb.org/ja_JP/term/test-condition-2

 

具体的な例がないため、少し分かりにくいかなと思いますが、ある書籍では、テスト条件を以下のように紹介しています。

Test Conditions

I’ve used the phrase “test condition” loosely to describe what should be tested. In reality, test conditions can take on many different forms. Some may be very high level, as in, “Test credit card purchases” for an e-commerce application. Others may be very detailed, as these for the same application:

• ​Test American Express successful purchase
• ​Test American Express declined purchase attempt
• Test MasterCard successful purchase
• Test MasterCard declined purchase attempt
• Test Visa successful purchase
• Test Visa declined purchase attempt
• ​Test JCB successful purchase
• Test JCB declined purchase attempt

Advanced Software Testing - Vol. 1, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Test Analyst

 

翻訳すると以下のようになります。

テスト条件

「テスト条件」というフレーズを何がテストされるべきかを説明するために緩やかに使用しました。実際には、テスト条件は様々な形を取り得ます。中には非常に抽象的なものもあり、電子商取引アプリケーションでの「クレジットカードによる購入をテストする」といったものです。他には以下のように非常に詳細なものもあります：

• アメリカン・エキスプレスによる成功した購入をテストする
• アメリカン・エキスプレスによる拒否された購入の試みをテストする
• マスターカードによる成功した購入をテストする
• マスターカードによる拒否された購入の試みをテストする
• VISAによる成功した購入をテストする
• VISAによる拒否された購入の試みをテストする
• JCBによる成功した購入をテストする
• JCBによる拒否された購入の試みをテストする

この場合、「クレジットカードで物を購入できる」というフィーチャーに対し、上記のようなものがテスト条件となり、テスト条件は様々な抽象度のものがあるということです。

JSTQB Fundation Level 2023V4.0.J01でのテスト分析の定義

最新版のシラバスではテスト分析の定義を以下のように説明しています。

テスト分析は、テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む（5.2 節を参照）。テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を識別したり、試験性のアセスメントをしたりする。テスト分析では、多くの場合、この活動を支援するためにテスト技法を使用する(第 4 章を参照)。テスト分析では、計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。

ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J01

 

基本的な内容に変更はありませんが、最新のシラバスでは「試験性のアセスメントをしたりする」という内容が新しく増えているような気がします。

また、テスト分析についての文章量が今までよりも少なくなったことで、逆にまとまった文章となり、やるべきことがわかりやすくなった気がします。

 

まとめ

テスト分析では次の2段階でテストベースを分析していきます。

1. フィーチャーを識別する
2. フィーチャーのテスト分析を定義する

もちろん、テスト分析で行う作業はこれだけではありませんので、詳細な内容はJSTQBのシラバスなどを参照してください。

 

余談：ISO/IEC/IEEE 29119でのお話

ソフトウェアテストの国際的な規格として「ISO/IEC/IEEE 29119」という規格があります。

この規格も定期的に更新されており、最新版は2022年に更新されています。

ISO/IEC/IEEE 29119では「テスト条件」とは言わず「テストモデル」としているようです。そのため、テストはすべてモデルとして識別するという内容になっているようです。

参考

qiita.com