ブラックボックステストのテスト技法としてよく知られている、(JSTQBのFLでも出てくる)
以下の5つ
この技法の理屈は誰でも理解できると思いますが、
結局、どんな時使ったらいいの？？
と疑問に思ったことがありませんか？？
というわけで、ここでは各技法の詳しい説明はしませんが、
各技法の説明を様々な人が様々なサイトで説明してくれている中で
どんな「例」をあげているか抽出し、集めれば、その技法の使い所がわかるはず！
ということでまとめました。
同値分割法はざっくり言うと、処理の結果をグループ分けし、代表値だけテストするやり方。
境界値分析法はざっくり言うと、処理の結果をグループ分けし、グループが隣接する境界やその前後の値でテストするやり方。
参考資料: http://www.jasst.jp/symposium/jasst19tohoku/pdf/S4.pdf
参考資料: https://qiita.com/softest/items/648d8bb4021cd1256b02
参考資料: https://solutionware.jp/blog/tag/%E5%90%8C%E5%80%A4%E5%88%86%E5%89%B2%E6%B3%95/
参考資料: https://www.slideshare.net/scarletplover/ss-56911349
年齢別に送信処理が分岐するようなやつ
入力バリデーションで使うのが人気ですね〜
条件により仕様が複雑に絡み合うときなど、デシジョンテーブルに一度まとめてから、それを基にテストを設計/実施するのがデシジョンテーブルテスト
参考資料: https://gihyo.jp/dev/serial/01/test_up/0005
クーポン割とか、平日割とか、複数の条件が組み合わさった場合とかがあるようなやつ。このサイトに限らず、映画館の料金システムなど、施設の精算システムのようなものをデシジョンテーブルテストのサンプルとして使っているのをよく見かけた
参考資料: https://www.weblio.jp/content/%E6%B1%BA%E5%AE%9A%E8%A1%A8
参考資料: http://www.jasst.jp/symposium/jasst19tohoku/pdf/S5-1.pdf
確かに複雑な料金プラン(オプションとかが複雑に絡み合うような・・）場合の仕様を整理する時、
デシジョンテーブルを使うと、仕様が明確になりやすい。そしてどこを追加でテストしたらいいか、、とかわかりやすくなる。
こちらもご参考に デシジョンテーブルを恋愛条件に置換えて3分で理解する
状態遷移テストは、ざっくり言うと状態遷移図と状態遷移表をもとに行うテスト
参考資料: https://webrage.jp/techblog/transition_test_of_the_state_of_the_system/
ストップウォッチ的なもの。他のサイトでもよくこの手のストップウォッチ的なものを例としているのを見かけた
参考資料: https://cacoo.com/ja/blog/what-is-state-machine-diagram/
参考資料: https://www.changevision.co/tutorial-statemachine-japanese.html
実際、資料に書かれているのは「CDプレイヤー」ですが・・・今どき、CDプレイヤー使ってる人とかあまりいないよね、、ってことで、音楽プレイヤーとあえて書いた次第・・
ハードウェア、組み込み系とかに人気の技法？？
こちらももすすめ Webアプリにありがちな状態遷移をまとめて状態遷移表でテスト観点とする
ユースケーステストはざっくり言うと、アクターとテスト対象システムの相互作用を表した「ユースケース」というものを基にし、テストケースを設計したテスト。
参考資料: https://appkitbox.com/testkit/knowledge/test/20130912-134
ユースケーステストとシナリオテストの違いを語っているサイトをよく見かける。
ということは、この2つはごっちゃになりやすい。ということなんだろー