非エンジニアにとってのソフトウェアテスト
本記事ではソフトウェアテストについて学ぶことで、
開発や検証に直接関わらない方（コンサルタントやビジネスアナリストなど、非エンジニアの方）の業務にどう活かせるのかに焦点を当てて記載していきます。
何らか業務に活かすことができるポイントを見つけていただければ幸いです。
投稿に至った経緯
業務でソフトウェアテストについて学ぶことがあり、JSTQB Foundation Levelを取得しました。
その中で、ソフトウェアテストに関する知識は開発や検証フェーズだけでなく、
上流工程である、企画や要件定義フェーズにも大いに活用できることができると実感しました。
デシジョンテーブルのつくり方
本題に入る前に、デシジョンテーブルのつくり方を簡単に説明します。
デシジョンテーブル（decision table）は、想定されるすべての条件と、それに対して実行すべき動作を整理した表のことです。
デシジョンテーブルの作り方を理解いただくために、ECサイトの例を見てみましょう
例）送料計算の仕様
合計金額が5,000円以上の場合、国内配送料無料
合計金額が5,000円未満の場合、国内配送料600円
海外配送料は合計金額に関わらず2,000円
すべての条件の組み合わせを網羅するように条件を洗い出します。
条件と仕様を確認しながら、該当するアクションに「×」を記入します。
あり得ない組合せ（合計金額：5000円以上かつ5000円未満 など）では「N/A」を記入します。
デシジョンテーブルによって仕様の曖昧さを検知する
デシジョンテーブルの作り方を知っていただいたところで、活用の仕方を確認します。
以下のような冷蔵庫の仕様について考えます。
＜仕様＞
冷蔵庫内の温度が8℃を超えた場合、注意メッセージAを表示する。
ドアが3分以上開きっぱなしの場合、注意メッセージBを表示する。
停電を検知した場合、注意メッセージCを表示する。
注意メッセージCが表示されている場合、他の注意メッセージは表示されない。
2つ以上の条件が同時に発生した場合、警告メッセージXを表示する。
条件まで埋めた状態が以下となります。
アクションを埋めていくと、仕様が曖昧で確定できない部分が出てきます。
・注意メッセージと警告メッセージは同時に表示するのか？
・停電時に他の条件を検知できるのか？
・そもそも停電しているときにメッセージ表示が可能なのか？
このように、文字では検知することが難しい仕様の不備や曖昧な部分を、デシジョンテーブルというソフトウェアテストの技法を用いることによって検知しやすくなります。
さいごに
本投稿を通じて、ソフトウェアテストを学ぶことが皆さま何らかの業務に役立つと思っていただけたら幸いです。
今回はデシジョンテーブルを取り上げましたが、製品や実装する機能、プロジェクト上の制約などによって適用しやすいテスト技法は変化するため、他のテスト技法を知ることも有効かと思います。