はじめに
続編です。
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その2 ソフトウェア開発ライフサイクル全体を通してのテスト〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その3 静的テスト〜
- テストを学びたくてJSTQBのFLシラバスを読んでみた〜その4 テスト技法〜 ← ここ
注意事項
あくまで、JSTQBのFLシラバス理解に向けた個人的メモです。
「これを読んだら FLシラバスが習得できます！」とかじゃないです。全然違います。
当然ですけど、こんな記事より「JSTQBのHP - JSTQB公認研修コース」に参加するのが正しい道です。（もしくは自力でシラバスを読むか。）
※本記事は「Foundation Level シラバス 日本語版 Version 2018.J03」を対象にしています。
4 テスト技法
330min
キーワード
ひとまずぱっと見、分からなかったものだけ調べるようにしてみる。
Qbookに載ってた用語
| 用語 | 意味(だいぶ省略してます) | Qbookの用語説明(JSTQB準拠) |
|---|---|---|
| チェックリストベースドテスト | 経験ベースのテスト設計技法。経験を積んだテスト担当者が導出した、チェックすべき項目のリストを使用して実施する。 | link |
| デシジョンカバレッジ | テストスイートによって遂行された、判定結果のパーセンテージ。 | link |
| エラー推測 | テスト担当者の経験を駆使し、エラーが起きた場合にどのような欠陥がテスト対象の中に存在するかを予想して、その欠陥を検出するテストケースを設計すること | link |
| ステートメントカバレッジ | テストスイートによって遂行されたステートメントのパーセンテージ。 | link |
| ステートメント | プログラミング言語の実体。実行の最小単位。 | link |
4.1 テスト技法のカテゴリ
K2 ブラックボックステスト技法、ホワイトボックステスト技法、および経験ベースのテスト技法の特徴、共通点、および相違点を説明する。
テスト技法を選択する際は、以下を含むさまざまな要因を検討する。
ちょっと多すぎるので、分類してみる。
システム知識
• コンポーネントまたはシステムの種類
• コンポーネントまたはシステムの複雑さ
業界知識
• 規制や標準
• 顧客または契約上の要件
• ソフトウェアの想定される使用方法
リスク・目的
• リスクレベル
• リスクタイプ
• テスト目的
PJの制約
• 入手可能なドキュメント
• 利用できるツール
• スケジュールと予算
• ソフトウェア開発ライフサイクルモデル
テストに関する経験・スキル
• テスト担当者の知識とスキル
• テスト対象のコンポーネントまたはシステムに関してテスト技法を使用した経験
• コンポーネントまたはシステムで想定される欠陥の種類
本シラバスでは、テスト技法を、ブラックボックス、ホワイトボックス、経験ベースに分類する。
| 項目 | ブラックボックス | ホワイトボックス | 経験ベース |
|---|---|---|---|
| 概要 | 適切なテストベースの分析に基づく。機能テストと非機能テストの両方に適用できる。テスト対象の入力と出力に着目し、その内部構造は参照しない。 | アーキテクチャー、詳細設計、内部構造、テスト対象のコードの分析に基づく。テスト対象内の構造と処理に重点を置く。 | テストケースの設計、実装および実行のために、開発担当者、テスト担当者、ユーザーの経験を活用する。ブラックボックステスト技法やホワイトボックステスト技法と組み合わせて使用する。 |
| インプット | ソフトウェア要件、仕様、ユースケース、ユーザーストーリーなど | ソフトウェア構造に関する情報など | テスト担当者、開発担当者、ユーザー、その他のステークホルダーの知識や経験など |
| カバレッジ | テストベース内のテスト済みアイテムと適用した技法に基づいて計測する。 | 選択した構造内のテスト済みアイテムに基づいて計測する。 | （記載なし） |
| その他特徴 | 要件と実装との間の相違、および要件からの逸脱を検出するために使う。 | 仕様書は、期待結果を決定するための追加の情報源として使用されることも多い。 | （記載なし） |
国際標準（ISO/IEC/IEEE 29119-4）には、テスト技法に対応するカバレッジ計測方法の詳細について説明されている（技法の詳細については、『Craig 2002』および『Copeland 2004』を参照されたい）。
ふむふむ。
4.2 ブラックボックステスト技法
K3 ある特定の要件からテストケースを導出するために同値分割法を適用する。
同値分割法は、同等に処理されると想定したデータすべてを同じパーティション（これを同値クラスとも呼ぶ）に振り分ける技法である（『Kaner 2013』および『Jorgensen 2014』を参照）。有効な値と無効な値の両方に対して同値パーティションがある。
色々説明書いてあるけど、絵にするのが一番わかりやすい気がする。
（slideshare-ソフトウェアテスト技法ドリル：線を意識するより引用）
絵の中では、「同値クラス」って表現だけど、FLシラバスだと「同値パーティション」って表現。方言だと理解すれば良いのかな。
無効同値パーティションをテストケースで使用する場合、複数の故障が同時に起き、1 つの故障のみが表面化した場合、他の故障を隠してしまい見逃す恐れがある。故障を隠してしまわないようにするため、他の無効同値パーティションとは組み合わせず単独でテストすべきである。
無効同値パーティションは、単独でテストしよう。
K3 ある特定の要件からテストケースを導出するために境界値分析を適用する。
境界値分析（BVA）は同値分割法の拡張であるが、パーティションが数値または順序付け可能な値で構成される場合だけ使用できる。パーティションの最小値および最大値（または最初の値と最後の値）が、境界値である（『Beizer 1990』）。
（slideshare-ソフトウェアテスト技法ドリル：線を意識するより引用）
同値パーティションの境界上での振る舞いは、同値パーティション内での振る舞いよりも正しくないことが多い。
ちゃんとやろう！境界値分析！
K3 ある特定の要件からテストケースを導出するためにデシジョンテーブルテストを適用する。
（slideshare - WACATE2010w テスト技法ワーク_スライドより引用）
デシジョンテーブルを簡単化する方法の詳細については、『ISTQB テスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト』を参照されたい。
それ、知りたかったんだけど、FLシラバスにはないのかー。（直交表とか、ペアワイズ法とかかなー？）
K3 ある特定の要件からテストケースを導出するために状態遷移テストを適用する。
コンポーネントやシステムは、現在の条件や過去の履歴（システムの初期化後から起きるイベントなど）によって、イベントに対して異なる振る舞いをする。過去の履歴は、状態の概念を使用してまとめることができる。状態遷移図は、ソフトウェアの取り得る状態、ソフトウェアが開始および終了する方法、ソフトウェアが状態間で遷移する方法を示す。
UMLのStateMachineと同じと解釈。
状態の典型的な順序をカバーする、すべての状態をテストする、すべての遷移をテストする、遷移を特定の順序でテストする、無効な遷移をテストする、といったテストケースの設計が考えられる。
状態遷移テストのカバレッジ基準の詳細については、『ISTQB テスト技術者資格制度 Advanced Level シラバス 日本語版 テストアナリスト』を参照されたい。
これもテストアナリストかー。
カバレッジは、テストをした状態または遷移の数を、テスト対象の識別した状態または遷移の合計数で除算して計測するのが一般的である（パーセンテージで表すことが多い）。
わかる。
K2 ユースケースからテストケースを導出する方法を説明する。
ユースケースは、ソフトウェアアイテムとの相互作用に表れるソフトウェア機能の要件を取り込むための設計方法であり、テストケースが導出可能である。ユースケースは、サブジェクト（ユースケースが適用されるコンポーネントまたはシステム）とアクター（ユーザー、外部ハードウェア、その他のコンポーネントやシステム）をつないでいる。
UMLのユースケース図に同じと理解。
カバレッジは、テストしたユースケースの振る舞いをユースケースの振る舞いの合計数で除算して計測する（パーセンテージで表すことが多い）。
わかる。
ユースケーステストのカバレッジ基準の詳細については、『ISTQB テスト技術者資格制度 AdvancedLevel シラバス 日本語版 テストアナリスト』を参照されたい。
そんなにわかりにくいものだっけ？？？きっと自分が理解できてない要素があるんだろうな・・・
4.3 ホワイトボックステスト技法
K2 ステートメントカバレッジを説明する。
カバレッジは、テストにより実行したステートメント数を、テスト対象の実行可能ステートメントの合計数で除算して計測する（パーセンテージで表すことが多い）。
「ITmedia - ステートメントカバレッジ（すてーとめんとかばれっじ）」より引用
K2 デシジョンカバレッジを説明する。
デシジョンテストはコード内の判定をテストし、実行したコードを判定結果に基づいて評価する。このために、テストケースは、判定ポイントを通る制御フローに従う。
文章だけだとよくわからん。
「ITmedia - ディシジョンカバレッジ（でぃしじょんかばれっじ）」より引用
K2 ステートメントカバレッジとデシジョンカバレッジの価値を説明する。
100%のデシジョンカバレッジの達成は、すべての判定結果を実行したことを意味する。これには、真の結果、偽の結果、さらには明示的な偽のステートメントが存在しない場合（例えば、IF ステートメント内に ELSE のないコードなど）を含む。
ほー。「明示的な偽のステートメントが存在しない場合の偽判定」も含むのか。
- ステートメントカバレッジは、他のテストでは遂行されないコードの中にある欠陥を見つけるのに役立つ。
- デシジョンカバレッジは、他のテストでは真の結果と偽の結果の両方が実行されないコードの欠陥を見つけるのに役立つ。
わかる。
4.2 ブラックボックステスト技法
K2 エラー推測を説明する
エラー推測は、誤り、欠陥、故障の発生をテスト担当者の以下の知識に基づいて予測する技法である。
わかる。
エラー推測技法に対する系統的アプローチは、起こりえる誤り、欠陥、故障のリストを作り、それらの故障やそれらを引き起こす欠陥を検出するテストケースを設計する。
ノウハウが溜まるほど強いけど、量が多すぎると困惑するやつだ。
ちょうど良いバランスを探さなきゃなぁ。
K2 探索的テストを説明する。
探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステムについての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。
探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。セッションベースドテストでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担当者はテスト目的を含むテストチャーターに従ってテスト実行をする。テスト担当者はテストセッションシートを使用して、実行した手順や発見した事象を文書化する場合がある。
いまいち、探索的テストってよくわかってなかったけど、スクラムちっくな感じで、イテレーション（セッション）ごとに何か目標を置いてスプリント（テスト）して、得られた結果から、次のスプリント（テスト）を計画するってことだと理解した。
大枠は理解したけど、効率の良い探索方法とかはノウハウで貯めていくしかないのかなぁ？
K2 チェックリストベースドテストを説明する。
チェックリストベースドテストでは、チェックリストにあるテスト条件をカバーするように、テストケースを設計、実装、および実行する。
「エラー推測」との差が少しわかりづらい・・・
「エラー推測」はやや抽象的で、「チェックリストベースドテスト」は具体的、って理解で良いのかな・・・？
ちょっと調べたら出てきた。
| 技法名 | 概要 | 入門文献 |
|---|---|---|
| エラー推測 | エラーを推測し、その存在を確認するテストを行う | JSTQBテストアナリストシラバス |
| チェックリストベースドテスト | テストの目的に沿ってチェックリストを作成し、そのチェック項目ごとにテストを行う | JSTQBテストアナリストシラバス |
（「ThinkIT - テスト設計技法を活用する」より引用）
エラー推測は普遍的な内容で、チェックリストベースドテストは、テスト目的に応じて変わるって感じ？
エラー推測も、テスト目的に応じて変わりそうな気がするんだけど・・・
う〜ん。推測か、リストか・・・くらいでひとまずとどめておくか・・・。
詳しくはテストアナリストシラバスで後ほど勉強しよう。
さいごに
今回は330minよりは短かった。割と聞いたことあるものも多かったので。
あと、1/3頑張るぞー！
現場にすぐにでも適用したいこと
（なんとなくゴールイメージが沸いているもの）
- 「エラー推測」に該当するノウハウの見える化・蓄積
以上です。