改めてテスト分析について考える
テスト分析について言語化して他人に説明できるようにするため、改めてテスト分析についてまとめておこうと思います。
この記事への指摘、ツッコミなどは歓迎です。
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
翻訳すると以下のようになります。
テスト条件
「テスト条件」というフレーズを何がテストされるべきかを説明するために緩やかに使用しました。実際には、テスト条件は様々な形を取り得ます。中には非常に抽象的なものもあり、電子商取引アプリケーションでの「クレジットカードによる購入をテストする」といったものです。他には以下のように非常に詳細なものもあります：
この場合、「クレジットカードで物を購入できる」というフィーチャーに対し、上記のようなものがテスト条件となり、テスト条件は様々な抽象度のものがあるということです。
JSTQB Fundation Level 2023V4.0.J01でのテスト分析の定義
最新版のシラバスではテスト分析の定義を以下のように説明しています。
テスト分析は、テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む（5.2 節を参照）。テストベースとテスト対象を評価し、それらに含まれている可能性のある欠陥を識別したり、試験性のアセスメントをしたりする。テスト分析では、多くの場合、この活動を支援するためにテスト技法を使用する(第 4 章を参照)。テスト分析では、計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J01
基本的な内容に変更はありませんが、最新のシラバスでは「試験性のアセスメントをしたりする」という内容が新しく増えているような気がします。
また、テスト分析についての文章量が今までよりも少なくなったことで、逆にまとまった文章となり、やるべきことがわかりやすくなった気がします。
まとめ
テスト分析では次の2段階でテストベースを分析していきます。
- フィーチャーを識別する
- フィーチャーのテスト分析を定義する
もちろん、テスト分析で行う作業はこれだけではありませんので、詳細な内容はJSTQBのシラバスなどを参照してください。
余談：ISO/IEC/IEEE 29119でのお話
ソフトウェアテストの国際的な規格として「ISO/IEC/IEEE 29119」という規格があります。
この規格も定期的に更新されており、最新版は2022年に更新されています。
ISO/IEC/IEEE 29119では「テスト条件」とは言わず「テストモデル」としているようです。そのため、テストはすべてモデルとして識別するという内容になっているようです。
参考
メトリクスの記事に対するChatGPT(GPT4)さんの感想
メトリクスの記事をChatGPTに校正してもらったついでに感想も聞いてみました。
面白かったので記念に残しておきます
私：
感想はありますか？
ChatGPT：
記事全体がソフトウェアメトリクスについての概要と、その取り扱い方に関して非常に分かりやすく説明されています。GQMアプローチの紹介や、取るべきでないメトリクスに関する注意点など、実践的なアドバイスも含まれており、読者にとって有益だと思われます。また、記事の構成が整理されており、段落ごとに一貫したトピックが提示されているため、読みやすいです。
ただし、いくつかの表現や文法の修正が必要な箇所がありましたが、それらについてはすでに指摘させていただいた通りです。
全体として、記事がソフトウェアメトリクスに関心を持つ人にとって有益な情報を提供していると感じます。
私：
ChatGPTさん的に有益だと思ったところはどこでしょうか？
ChatGPT：
記事のいくつかの部分が特に有益だと感じましたが、特に以下の点が印象的でした。
-
GQMアプローチの紹介: ソフトウェアメトリクスを適切に選択し、評価する方法として、GQMアプローチが詳しく説明されています。これにより、読者は具体的な方法論を持ってメトリクスを選択し、目標に対応させることができるでしょう。
-
取るべきでないメトリクスに関する注意点: 記事では、いくつかのメトリクスが適切でない状況や、コンテキストを考慮して選択するべきであることが指摘されています。これは、読者が無駄な労力を避けるために非常に重要な情報です。
-
メトリクスの選択と可視化に対するバランス: 記事は、メトリクスの選択や可視化において適切なバランスを保つことの重要性を強調しています。これにより、読者はメトリクスを適切に活用し、品質改善に役立てることができるでしょう。
これらの点が、ソフトウェアメトリクスを理解し、適切に選択・活用する上で有益だと感じました。
私：
賛成できない場所はありましたか？
ChatGPT：
記事全体としては、ソフトウェアメトリクスについて有益な情報が多く含まれていましたが、以下の部分で少し異論があります。
- 「私はすべてのメトリクスがトップダウンで取られるべきとは思いませんが」: この部分は、GQMアプローチを全てのメトリクスに適用すべきでないと述べていますが、一部の読者にはこの意見が曖昧に感じられるかもしれません。具体的な例や、トップダウンとボトムアップのアプローチをどのような状況で使い分けるべきかについて、さらなる説明があると、理解が深まるでしょう。
それ以外は、記事がソフトウェアメトリクスの選択や活用に関する良い指針を提供していると感じました。この記事が、多くの読者にとって有益であることでしょう。
他のページに反対意見を述べている部分が賛成できないということみたいです。
なるほど。
