前回の記事では、ISTQBのシラバスに列挙された「テストの目的」の変化について書きました。
が、そもそもこの項をきちんと熟読していませんでした。
この記事では「テストの目的」を、健康診断のアナロジーで考えてみたいと思います*1。
用語の対比
まずは、テストと健康診断の用語の対比を考えてみましょう。
テスト周りにはややこしい用語が多いのですが、まずはドラフトってことで。
| テストの言葉 | JSTQBの定義 | 健康診断の言葉 |
|---|---|---|
| テスト対象（test object） | テストすべき作業成果物。 | 人間の体 |
| テストアイテム（test item） | テストプロセスで使用するテスト対象の一部分。 | 体の各部位 |
| テスト条件 | テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。 | 検査対象となる体の機能・状態 |
| テスト技法（test technique） | テスト条件の定義、テストケースの設計、およびテストデータの明確化をするための手続き。 | 検査の手法。胃カメラとか。 |
| テストケース（test case） | 実行事前条件、入力値、アクション（適用可能な場合）、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの。 | 検査項目 |
| 欠陥（defect） | 作業成果物に存在する、要件または仕様を満たさない不備または欠点。 | 症状をもたらす身体上の問題 |
| 故障（failure） | コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。 | 冷たいものを食べると歯が染みる、といった症状 |
| 測定値（measure） | 測定することによって、ある実体の特性に付加した数字や種別。 | 検査で測定できる数値。血圧や歯周ポケットの深さなど |
テストアイテムとテスト条件
テストアイテムもテスト条件については少し前に、湯本さんからこう教えていただきました。
テストアイテムは機能カットにするとは限らないと思います。開発の都合で分割してるものでテストへとリリースするものです。一方テスト条件はテストできるようにテスト目線で識別して列挙していってるものです。
— Tsuyoshi Yumoto (@yumotsuyo) 2020年3月21日
人間の体も多くの部位・器官に分かれていますが、その部位たちは当然ながら、検査の都合を考えて作られているわけではありません。たとえば鼻と耳は別の部位と見なされますが、「耳鼻科」のようにまとめて扱う方が検査しやすかったりもします。
同じように、テストアイテムは必ずしもテストの都合に合わせて整理されているわけではなく、テスト条件を導くためには一度、テストのために整理し直す必要があります。
なお、「耳だけが先にリリースされる」というケースはマレで、人体は一式でdeliver*2されることが多いので、人体のテストはビッグバンテストということができますね。
また人体の設計は、人間より上位の存在であるプライムベンター(神)から指定されており、ある程度品質は担保されているのですが、誰も使用しない機能があったり、指定したパラメタが何かの拍子で狂ったりすることもあるので、完全とは言い切れないようです。
テストケース
健康診断の検査項目、たとえば「血圧」を考えてみると、腕のどのあたりに何秒間圧力をかけるか、ということが決まっていますね。入力値、アクションはこれらが該当するでしょう。
また、各項目には基準値が設定されています。血圧でいうと、「収縮期」の基準は130mmHgとなっています。
テストの目的と健康診断の目的
さて、本題に入りますしょう。
Version3.0の和訳をベースに、3.1を和訳したものが以下です。
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することで、欠陥の作りこみを防ぐ。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成したことをチェックし、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 故障や欠陥を発見することで、不適切なソフトウェア品質のリスクレベルを低減する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのような要件や標準に準拠していることを検証する。
それぞれ、意味を考えていきます。
5. 故障や欠陥を発見することで、不適切なソフトウェア品質のリスクレベルを低減する。
わかりやすいところから行きましょう。
たとえば歯科検診で虫歯が見つかったとすれば、その歯を治療することになるでしょう。これは、テストケース実行によるバグ*3発見とその改修のイメージですね。
ちなみに、前回の記事で書いた通り、Version3.1のこの項は、3.0の2つの項目を合わせたものです。3.0では、このようなカッコ補足がありました。
（以前に検出されなかった故障が運用環境で発生するなどの）不適切なソフトウェア品質のリスクレベルを低減する。
ソフトウェア側が変わっていなくても、環境の違いや時間の経過によって、隠れていた不良が顕在化することがあります。
たとえばネットワーク通信速度の向上によって、想定していた処理順にならなくなったとか。開発当初は知られていなかった脆弱性が公知となったとか。よって一度リリースしたソフトウェアに対し、継続してテストを行うことは有効です。
人間の体も加齢に連れてガタが来ますし、検査の技術も向上していきますので、定期的に検査を受けることが大切ですね。
1. 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することで、欠陥の作りこみを防ぐ。
これも比較的わかりやすいです。
たとえば、体重が年々増えていき、BMIも悪化している。これが肥満によるものなのであれば、たとえば基準値内だったとしても、悪い傾向を正していく必要がありそうです。
これは、「技術的負債の蓄積による保守性の悪化」と例えることもできますし、「長時間稼働によるメモリリーク」と例えてもいいかもしれません。また、「開発プロセスの悪化」とも。
ともあれ、時間の経過によりバグを生んでしまったり障害を発生させてしまったりする前に、対処の必要性を明らかにすることができます。
6. ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
ソフトウェア開発におけるステークホルダーは様々で、開発しているソフトウェアの詳細まで知っている人もいれば、コンセプトくらいまで把握していれば十分という人もいます。ステークホルダーが必要とするレベルに合わせて情報を提供することが大切です。
わたしの手元にある人間ドックの結果表を見ると、まず「総合判定」が出てきます。これは体全体の評価です。ここで「A」なら、もうその先には特に読まないという人もいるでしょう。
一方、もっと詳細を気にする（すべき）人もいます。総合判定がたとえば「C」なら、なおさらですね。わたしですが。
総合判定の次に、各検査の結果が並んでいます。身体計測、視力、眼圧、眼底、聴力、・・・のそれぞれに対し、A～Fが振られています。ソフトウェアでいえば、機能ごとの品質判定になぞらえられるでしょう。
この後に、「医師の指示事項」が載っています。わたしは「胃部検査で経過観察が必要」とあります*4。これは各機能に対するテスト結果のサマリと言えますね。
さらにこの後に、各検査項目の詳細が出てきます。先ほど「血液一般」というカテゴリになっていたものは、「白血球数」「赤血球数」「血色素」・・・と詳細になっています。これはテストケースに相当しそうですね。
このように、レベルを分けて情報を提供し、総合的な情報も、詳細の情報も見られるようになっているのが、よいレポートだと思います。
なお、健康診断におけるステークホルダーは、まずは自分自身ですね。あと家族。
会社員なら会社もステークホルダーと言えるかも。
7. 契約上、法律上、または規制上の要件や標準を遵守する、そして／またはテスト対象がそのような要件や標準に準拠していることを検証する。
ソフトウェアのテストタイプの一つに、標準適合性テスト（compliance testing）があります。たとえば通信関係のソフトウェアに対し、「TCP/IPのRFC規格に準拠した実装になっている」ことを確認するためのテストをしたりします。もちろん手動ではなく、ツールを使った自動テストが多いでしょう。
またたとえばVMWare関連のプラグインを開発する場合、VMWareの提示するスペックに準拠していることを証明するための認証キットが提供されたりしていますね。
このような要件・標準を満たしていることを証明することも、テストの目的の一つです。
健康診断のアナロジーでいうと・・・。
たとえばパイロットには「身体検査基準」があり、満たすべき視力が設定されています。この場合の検査は、問題を発見することよりも、「基準を満たしていることの証明」が目的になりますね。
4. テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
信頼を積み重ねる、とはなかなか難しい言葉。
たとえば考えられるテストケースが100件あったとして、20件中20件のpassよりは、90件中90件のpassの方が、そのソフトウェアを信頼できるといえるでしょう。また1回のテストでなく、同じテストを複数回passすることで安心できるようなテストケースもあるでしょう。
（テスト）空間的、時間的にテストを重ねることで、対象のソフトウェアに対する信頼・安心感は増していきます*5。
健康診断も同様で、幅広く、かつ継続的に検査を受診することで、こちらも安心感が増します。
ただし、「テストが全部通った」「総合判定がAだった」からといって、ソフトウェアや体に問題がないことの証明になるかというと、そうとは限らないですね。
テストでいえば、やるべきテストケースが漏れていたかもしれない。テストケースの実行結果に見逃しがあるかもしれない。そもそも必要なテストアイテムを漏らしているかもしれない。
そうならないように、健康診断の検査やテストの精度を少しずつでも上げていきたいものです。次の#2に通じるものがあります。
2. 明確にしたすべての要件を満たしていることを検証する。
たとえば肝機能について、「ガンマGTPが51未満であること」ことは要件そのものではなく、「肝機能の働きが正常であると考えるための手がかりの一つ」に過ぎません。「働きが正常である」という判断は、いくつかの角度から観察して初めて、（それでも暫定的に）下すことができます。
テストにおいても、個々のテストの pass / fail ではなく、それらを束ねて初めて、ソフトウェアや機能が「要件を満たす」を判断することができます。
逆に言うとテストケースの集合は、「それらをpassすることで要件を満たしていると宣言できるような内容」になっていることが求められます。テスト分析やテスト設計が必要なのは、そのためです。
3. テスト対象が完成したことをチェックし、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
たとえば発注したソフトウェアのユーザ受け入れテストなどに相当するでしょうか。発注で意図したものが確かにできあがっていることの確認ですね。
この項目だけはちょっと、健康診断のアナロジーを当てはめづらそうです。健康診断に向けて体を「完成」させるわけではないので・・・。
まとめ
長くなってしまいましたが、7つもあるテストの目的には大きく、「情報の提供」と「改善への足掛かり」の2つに分かれるようにも見えますね。
- 情報の提供: 2、3、4、6、7
- 改善への足掛かり: 1、5
Version3.0から3.1で、9個から7個に集約されましたが、もう少し整理できそうな気もしています。
なお2011年版ではとてもシンプルに、以下の4つなのです。
- Finding defects
- Gaining confidence about the level of quality
- Providing information for decision-making
- Preventing defects
追記
ツイッターでいただいたコメントをぶら下げておきます！
テスト対象が人間で、テストアイテムが検査対象物（レントゲンなら肺とか、聴力検査なら耳とか）とても伝わりやすく良いアナロジーだと思います。それ故に全部のテスト目的を語れるかな？と考えてしまいました。（ドリル本では、体力測定とか色々増やしたら、かえって判りにくくなってしまいました）
— あきやま🛟 (@akiyama924) 2020年4月7日
