テストアナリストのシラバスに載っているテスト技法
この記事は、ソフトウェアテスト #2 Advent Calendar 2018 14日目の記事です。
はじめに
JSTQB テストアナリストの学習を通じて、ソフトウェアテストの技法をいくつか学びました。 本記事では、日本語版シラバスの各技法に対するコメントを書いてみます。 見出しの番号は、シラバスの目次と対応しています。 あくまで私個人の経験に基づいて書いていますので、一般論ではありません。ご注意ください。
3.2 仕様ベースの技法
3.2.1 同値分割法
おなじみの同値分割です。私も実務で当たり前のように使っています。 シラバスにも書かれているとおり、同値クラス内の値が正確に同じ方法で処理されないと欠陥を見逃します。 あまり過信はせず、他の技法と組み合わせて使うことが多いです。同値分割の結果だけを使うのであれば、スモークテストで使う程度にとどめています。 また、無効同値を狙うための前処理としてよく使います。
3.2.2 境界値分析
こちらもおなじみの技法です。2値の値を用いる方法はよく使っていますが、3つの値を用いる方法は使ったことがありませんでした。3つの値を用いる方法は、JaSST'18 Kyushuでも紹介されていました。今後、取り入れてみたいと思います。 この技法は、ループや時間に関係する境界にも適用できます。例えば「同じ操作をn回繰り返す」や「日跨ぎで操作する」はよくやります。ただ、こういった欠陥は、境界値分析のテストではなく、探索的テストと意識していたことが多かったです。
3.2.3 デシジョンテーブル
実務では一番使っている技法かもしれません。表形式にまとめると、お客様への説明がラクですね。条件の組み合わせが増えると表が肥大化し見づらくなるので、情報をどう切り出すかをよく悩みます。また、デシジョンテーブルを作ると、期待結果の抜けが見つかることが多いです。そのため、ソフトウェアの設計/実装をしていた時にもよく使っていました。
3.2.4 原因結果グラフ法
座学のみに留まっている技法です。WACATEなどで記法は習いましたので、今後習得していきたいと思います。 シラバスによると、テストベースの品質向上が期待できるそうです！
3.2.5 状態遷移テスト
状態遷移図/表は、テストの実務で使ったことはほぼありません。ソフトウェアの設計/実装をしていた時にはそこそこ使っていました。 たとえば、申請/承認機能の挙動をデシジョンテーブルで整理したことがありますが、いま思えば状態遷移図/表を使った方が良かったのかもしれません。 WACATEでモデリングを学んだ際、「状態遷移中」もひとつの状態として捉えるかどうかは非常に悩みました。
3.2.6 組み合わせテスト技法
直交表、ペアワイズ、クラシフィケーションツリーについて触れられています。組み合わせ爆発を防ぐ目的で、ペアワイズを用いることはあります。直交表は、実務では使ったことがありません。クラシフィケーションツリーも、実務では使ったことがありません。今後習得していきたいと思います。
3.2.7 ユースケーステスト
実務ではそこそこ使う技法です。ユーザーストーリーを書く前の前処理的に使うことが多いです。他の技法を使うときと比べて大きく違うのが、ユースケースを書くために、有識者のお時間をいただく必要があるということです。知識を豊富にお持ちの方は概ね多忙ですので、普段から関係性を築いていくこともとても大事だったりします。
3.2.8 ユーザーストーリーテスト
実務ではかなりよく使う技法です。非機能テストを含めることができるので、使い勝手が良いです。私が関わった実務の範囲では、BDDやATDDを使うことはあまりありません。ユーザーストーリーをもとに記述した受け入れテストをデモしてDONEにしています。ユーザーストーリーテストを使う現場では、細かな組み合わせのテストなどが軽視されがちな印象を受けますので、意識して他の技法で補強しています。
3.2.9 ドメイン分析
座学のみに留まっている技法です。ソフトウェアテスト技法ドリルで学びました。私の場合は恐らく、ドメイン分析を適用できる状況でもデシジョンテーブルを使っていました。技法が分かれているということは何かしらの意味があると思いますので、学び直します。
3.3 欠陥ベースの技法
3.3.2 欠陥分類法
欠陥分類法という名前そのものには馴染みがありませんでしたが、実務ではそこそこ使っている技法だと思います。異常系のテストを設計するときに使います。 シラバスでは、テキスト欄と日付欄をサンプルに例示がされています。実務では、これらのリストがすでに手元にあることは少なく、都度考えて作っていることが多いです。ちょっと勿体無いですね。
3.4 経験ベースの技法
3.4.1 エラー推測
テスト好きであれば、大体の方が得意な技法だと思います。自分自身にスイッチが入ってしまうと、枝葉ばかり狙って幹が疎かになることがあります。使いどころには気をつけましょう。また、結果を言語化して伝えるのが難しいことも多いように思います。 例：「よくこんなの見つかりましたね！どうしてこれを思いついたんですか？」「さあ。。。？？(このあと頑張って言語化する)」
3.4.2 チェックリストベースドテスト
シラバスの定義と合っていないかもしれませんが、スモークテストなどの用途で、簡易的なチェックリストを使うことがあります。データを作って→取引の記録をつけて→月の処理を締めて→帳票に出力して、というイメージです。簡易的なチェックリストなので、細かい操作は人によってブレますが、手順抜けの防止に使えます。新規参入メンバーの教育目的で、同チェックリストを使うこともあります。
3.4.3 探索的テスト
実務では、ときどき使う技法です。JaSST'18 Tokyoで、チャーターを使った探索的テストを学びましたが、私の場合はチャーターを使ってかっちりとテストをした経験はなく、刺激に対する反応を拾って、次の刺激を与えるというサイクルを繰り返すことが多いです(刺激→反応モデルと呼ばれるそうです)。欠陥を見つけるだけでなく、「こう動かしたらどうなるの？」という情報を得るために行うことも多いです。
(番外)構造ベースの技法
構造ベースの技法は、テクニカルテストアナリストのシラバスに記載されています。 (前職の)実務では、複合条件カバレッジを用いることが多かったです。シラバスだとどこに該当するか、ちょっと理解できていません。判定条件テスト？
まとめ
シラバスを読むことで、新しい技法との出会いがありました。 自分の引き出しが増えるのは楽しいですね。既に知っていた技法についても、学びなおす良い機会となりました。 皆様もシラバスを読んで、楽しいテストエンジニアライフを送ってください。
