第293回： 「ALTAのテキストをつくろう」48 （チェックリストベースドテスト）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.3 経験ベースのテスト技法」の「3.3.1 エラー推測」の「適用、制限／注意事項、カバレッジ、検出できる欠陥の種類」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.3 経験ベースのテスト技法」の「3.3.2 チェックリストベースドテスト」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢4の「テストケースは文書化される場合があるが、作成者だけが理解して再現できる形」が39.6%と最も多ったのですが、正解は1です。正答率が22.9%なので低めです。
選択肢1が誤っているのは「のみ」のところです。確かにエラー（エラー、欠陥、故障、故障モード）を推測するのは「経験」によってです。
しかしながら、エラー推測技法では、「推測した欠陥を検出するテストを作成する」必要があります。「テストを作成する」方法として、ブラックボックステストやホワイトボックステストが使われます。
また場合によっては「欠陥分類法」の知識を使用してカバレッジを求めることも欠陥の検出に役に立ちます。
以上のことから、経験だけあってもテスト技術がなければよいテストにはなりませんから、「検出できる欠陥は経験のみに依存する」という主張には問題があります。
なお、選択肢4についてはシラバスの記載通りです。
前回の復習は以上として、今回のnoteのテーマに移ります。
ふと、「推測正答率」を測っても良面白いかもしれないと思いました。
推測正答率
＝（見つかった欠陥数）÷（推測数）×100
です。
≡ チェックリストベースドテストの定義
要は、チェックリストを使ったテストのことです。用語集を確認してみます。
英語は「An experience-based test technique in which test cases are designed to exercise the items of a checklist.」ですので、特に意訳もありません。
気を付けないといけないのは、シラバスの以下の記述です。
アジャイルソフトウェア開発では、チェックリストはユーザーストーリーの受け入れ基準から構築できる。
いや、これは間違いでしょう。
ユーザーストーリーのAC（acceptance criteria）からチェックリストを作るって、、、きっとこの部分を書いた人はチェックリスト、もしくは、ACのどちらか、あるいは両方について誤解をしていると思います。
ねんのために英語版も確認してみましたが、同じ内容でした。
In Agile software development, checklists can be built from the acceptance criteria for a user story.
私が誤解しているかもしれませんので、ALTAのテストに出たらシラバスどおりに答えてください。
≡ チェックリストベースドテストの適用
シラバスには「ユーザーインターフェースチェックリスト」の例があり、これは分かりやすいと思いました。
キャッチイメージを再掲します。
チェックボックスのユーザーインターフェースの一つに「ラベルクリック」があります。チェックボックスの横にラベル（選択肢の文）があったときに、チェックボックス部分だけではなくラベルをクリックするとチェックボックスにチェックが入るユーザーインターフェースです。
こういうもののために「ラベルをクリックすることでもチェックが入る」というチェックリストは有効です。
HTMLでは、
<input type="checkbox"><label>ラベルの文</label>と書くだけでは「ラベルクリック」にはならず、
<input type="checkbox" id="c1"><label for="c1">ラベルの文</label>とする必要があります。
（もちろん別の方法もあります）
というように実装しないとラベルクリックの動きにならないということは、テストにおいて、「ラベルクリック」が効いていることも確認する必要があるからです。
≡ チェックリストベースドテストの制限／注意事項
シラバスには、「同じチェックリストを使用しても、異なるテスト結果となる可能性がある。これは、より広いカバレッジを可能にするが、再現性が犠牲になることがある。」とあります。
抽象度の高い（ハイレベルの）チェックリストは広い範囲のチェックに使えるメリットはあるけれども、テスターによって異なる結果になるというデメリットがあるということです。
「チェックリストの読み合わせ会」を開くと良いと思うのですが、なかなかそんな時間はとれませんので、ベテランのテスターと新人のテスターがペアになってテストをするのが良いと思います。
≡ チェックリストベースドテストのカバレッジ
いや、カバーするチェックリストを作ることが大変であり、作ったチェックリストは全部テストすると思います。したがって、シラバスのここに何が記載されているかについては書きません。
≡ チェックリストベースドテストの検出できる欠陥の種類
JSTQBのALTAシラバスの該当箇所の全文を引用します。
この技法で見つかる典型的な欠陥は、テスト時のデータ、手順の順序、全般的なワークフローなどが異なることにより、故障をもたらす欠陥である。
そうなのかなあ？
昔（30年くらい前）は、チェックリストが流行っていたように思います。
「リソースのオーバーフロー」、「うるう年の考慮」、「イベントのぶつかり」といった、今で言えば「テスト観点」のようなものが、ずらずらと50個くらい書かれた一覧表が渡され、それぞれの機能を列にして、確認したらチェックを入れていくというやつです。（ゆもつよ表の縦横が逆なものを想像してもらえば、だいたい合っています）
だから、検出できる欠陥はチェックリストの各項目でした。
ALTAのシラバスにある「テスト時のデータ」がチェックリストの「大量データ」、「誤ったデータ」、「空のデータ」、「改行が間違ったデータ」、「文字コードが間違ったデータ」等々のチェック項目のことを丸めて書いているのなら正しいと思いますが、よくわかりませんでした。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.3.1 （K2）経験ベースのテスト技法の原則と、ブラックボックステスト技法および欠陥ベースのテスト技法と比較した場合の長所と短所を説明する。
TA-3.3.2 （K3）与えられたシナリオから探索的テストを識別する。
TA-3.3.3 （K2）欠陥ベースのテスト技法の適用方法と、使用方法におけるブラックボックステスト技法との違いを説明する。
ということで、エラー推測に続いて、こちらに関するものも見当たりません。
わたしはK2レベルだと思います（K2：理解、K3：適用、K4：分析）。
《問題》
下記はチェックリストベースドテストについて述べたものである。誤っているものはどれか。
1. 必ずチェックリストを使用する
2. アジャイル開発では、ユーザーストーリーのACから構築できる
3. リグレッションテストには使用しない
4. GUIのチェックリストを作り操作性を確認することも有効
答えは次回に書きます。
≡ おわりに
今回は、「チェックリストベースドテスト」がテーマでした。
昔は、テストケースをつくらずに、チェックリストが渡されて、それを見ながら触ってみるのがテストでした。テスト対象も小さくてシンプルだったからそれでも十分だったんですね。
さて、次回は、みんな大好き「3.3.3 探索的テスト」です。
この記事が気に入ったらサポートをしてみませんか？