みなさん、こんにちは！ QA事業本部のゆーすけです。
JSTQB CBT試験みなさん受けてますかっ！？（前回と同じ入り方）
ついに、テストアナリストのCBT開始の連絡もありましたね、しかもテストアナリストはPBTやテストマネージャーCBTとは異なり、「3年間の業務経験」という条件がなくなっていますので、より現場に近い資格になったんじゃないかな、と思います。
また、年内には
・アジャイルテスト担当者
・自動車ソフトウェアテストテスト担当者
・テスト自動化エンジニア
も開始予定とのことなので、自分もそろそろアジャイルテストと自動化エンジニアの勉強を再開しようかと思っているところです！（自動車はPBTで取得済み）
ということで、JSTQBの学習のススメ連載の6回目となります！
▼1～4回のおさらいです！
1回目 JSTQBってなんだろう？→Foundation Levelから始めよう
2回目 Foundation Levelの構成ってどうなっているんだろう？
3回目 テスト基礎について
4回目 テストのライフサイクルについて
5回目 静的テスト
JSTQB Foundation Levelの構成は以下のようになっていて、6回目の今回はみんな大好きテスト技法について触れていきたいと思います。
１：テストの基礎
２：ソフトウェア開発ライフサイクル全体を通してのテスト
３：静的テスト
４：テスト技法 ←今回はココ
５：テストマネジメント
６：テスト支援ツール
テスト技法って？
テストを効率的かつ効果的に進めるための考え方、アプローチ方法ととらえると分かりやすいかもしれません。シラバスにも記載されていますが、テス技法ありきでテストを考えるのではなく様々な要因のもと正しくテスト技法の取捨選択、適用範囲を決めていることが大事になります。
プロダクトの性質上、適用できない/適用しても効果的ではない、というテスト技法もあるので、技法の特性特色はここで適切に把握するようにしていきましょう。
FLシラバスでは、動的テストの「ブラックボックス」「ホワイトボックス」「経験ベース」の3つに分類しています。以前の記事にも使ったテスト図に付け加えると以下のようなかたちになります。
ブラックボックスのテスト技法
上の図とは順番が異なりますが、シラバス記載の順序通りにブラックボックステストの技法から簡単に触れていきましょう。
同値分割
同値はデータの処理からグループ分け（同値クラス化）をする考え方です。
例えば、数字入力のフォームにて、
・0～50
・51～100
・101～
の入力結果において異なる処理が行われる場合、上記の3つカテゴリが有効同値クラスとなります。
テストを行う際は、同値内の中央値を使用くするのが一般的と言われています。
境界値分析
境界値分析はIPAなどでは限界値分析とも呼ばれます。
コーディングにおいて、”＞”（大なり）、”＜”（小なり）と、“≧”（大なりイコール）、”≦”（小なりイコール）を取り間違える、というのはありそうでなさそうだけど、実際はありえる分かりやすいコーディングミスの一つです。想像することのできるコーディングミスで、最も単純でその割に影響度が果てしなく大きいので、出来れば重要な数値周りは境界値の観点でテストを行い、「問題ない」というお墨付きをもらっておきたいところですよね。
※設計書上で数字の分岐定義、統一がされていない、「以上以下」と「より未満」が入り混じるようなものは要注意です。
先ほどの同値分割と同じ数字でいうと、
・0～50
・51～100
・101～
0、50、51、100、101が境界値分析として取り扱うべきテスト対象となります。
※境界値として2値をとる、という方針になった場合。3値の場合は0、49、50、51、99、100、101が対象となります。
同値と境界値の関係を簡単な図にすると以下のようになります。
デシジョンテーブル
決定表とも呼ばれるテスト手法で、デシジョンテーブルのことを取り上げた記事もあります。
いまさらデシジョンテーブルというものを考えてみた | Sqripts
上の記事にも記載していますが、テストケースを省略できるパターン、省略できないパターン、デシジョンテーブルではなく原因結果グラフが適切な場合などいろいろ考えられますが、Foundation Levelではまずは簡単なテスト条件からテーブルを作成できれば問題ないと思います。
デシジョンテーブル記事の再掲となりますが、
想定：
映画館のチケット割引サービス
仕様：
通常金額1900円
割引システム：
ファーストデイ：毎月1日はだれでも1200円
レディースデイ：毎週水曜日は女性なら1200円
という条件があった場合、以下のようなテーブルが作られます。
条件からデシジョンテーブルを作ってみる、という内容はJSTQB ALテストアナリストや、IVEC（IT検証技術者認定試験）でも頻出しているので、自分で条件を考えて実際に数回テーブルを作ってみる、というのがいいと思います。
状態遷移テスト
これまた別ブログ記事参照で申し訳ないですが、状態遷移を取り上げた記事がありますので、より深く知りたい方はこちらを参考にしてみるといいかもしれません。
幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト | Sqripts
状態遷移テストは、「状態遷移図」または「状態遷移表」を作って考えます。
それぞれの特色としては、
状態遷移表：無効値も含めて考えるため、仕様の抜け漏れに気づきやすい
状態遷移図：フロー図で表すため、遷移が視覚的に分かりやすい
ということがあります。
状態遷移テストはJSTQB ALテストアナリストでも引き続き掘り下げられていく手法のため、FLの段階でしっかりと状態遷移図、状態遷移表のどちらも作れるようにしていきましょう。
※JSTQBテストアナリスト試験では、状態遷移図を作ってNスイッチカバレッジを求めよ、というのが頻出傾向でしたが、最新PBTではなくなった、という嘆きの声もあるようです。
※嘆きの声が書かれた記事がこちら
シラバス改定後初のJSTQB ALTA試験受けてきた #1 | Sqripts
ユースケーステスト
まずはシラバスから抜粋すると
ソフトウェアアイテムとの相互作用の設計方法であり、テストケースは、ユースケースから導出可能である。
ユースケースには、ソフトウェア機能の要件が盛り込まれている。
（省略）
各ユースケースは、1 つのサブジェクトと 1 つ以上のアクターとの相互作用による振る舞いを明確にす る（UML 2.5.1 2017）
と記載されています。
つまりユースケースは、ソフトウェア機能要件（要件定義～詳細設計）で定義されたものがテストベースとなります。
ただし、ユースケーステストをISTQB GLOSSARYで調べると
ブラックボックステスト技法の一つ。ユースケースの動作を実行するようにテストケースを設計する。
同義語：ユーザシナリオテスト、シナリオテスト
と記載されているので、ユースケース図をテストベースとしたテストだけではなく、ユーザーを想定した一連のテストを丸めて呼んでいる、代表的な例としてユースケース図をベースに作成する、とざっくりとした理解でもFLの段階ではいいと思います。
このあたりはSWEBOK-SQuBOKや、ISO/IEC/IEEE 29119など、他の学習を取り入れ、そのうえで自分の中でのユースケース定義、シナリオテスト定義などをしっかりと定め、認識齟齬なくテスト活動を行っていく、ということが重要なところとなります。
ちなみにシラバスにも記載されているユースケースにおける、サブジェクトとアクターはこのように表せます。
なんと次回に続く……
今回テスト技法を「ブラックボックス」「ホワイトボックス」「経験ベース」の3つを取り上げる予定でしたが、3つ全て取り上げるとかなりのボリュームになりそうなので、今回はブラックボックスだけの内容として、残りの2つは次回にまわしたいと思います。
次回はなるべく早めに掲載できるよう頑張りますので引き続きお付き合いいただけますよう何卒宜しくお願いいたします！！
シリーズ一覧
JSTQB学習のススメ #1 〜JSTQBとは〜
JSTQB学習のススメ #2 〜Foundation〜
JSTQB学習のススメ #3 〜Foundation〜
帰ってきた JSTQB学習のススメ #4 〜Foundation〜
JSTQB学習のススメ #5 〜Foundation〜
JSTQB学習のススメ #6 〜Foundation〜
