名 ・ サ − ビ ス 名 は 、 各 社 の 商 標 登 録 で す Appendix：コンテキスト由来欠陥への対策案 22 コンテキスト由来欠陥 対策（仕様定義段階での未然防止） 対策（仕様レビューによる検出） 対策（テストによる検出） 条件の組み合わせの考慮漏れ・未記載 デシジョンテーブルなどを作成して条件の組み合わせを整理し、 考慮漏れを防ぐ。 デシジョンテーブルなどを作成して条件の組み合わせを洗い出し、 必要な組み合わせに対して網羅的に仕様が定義されているかレ ビューする。 デシジョンテーブルなどを作成して条件の組み合わせを洗い出し てテストする。 条件の間での矛盾 条件を減らして、矛盾が起こりにくくする。減らせない場合、形式 言語など、矛盾が生じない表現形式で表現する 類似の条件に関する仕様同士を突き合わせて、矛盾がないかレ ビューする。 類似の条件に関するテストは、同じ担当者が連続して実施する ようにする。 増やした条件の記載漏れ 条件を増やすことを議事録やTODOリストなどに記録して、記載 したかどうかをチェックできるようにする。 条件を増やすことを議論・決定した場に参加していた人に、レ ビューをお願いする。 テスト担当者も仕様の議論の場に参加し、増やすことになった条 件はテストに反映する。 増やした条件と、既存の条件や機能との矛盾 既存の条件や機能をドキュメント化して、条件を増やす場合に 一通りの既存部分と突き合わせてチェックする。 既存の条件や機能に詳しい人にレビューをお願いする。 増やした条件と、既存の条件や機能を組み合わせてテストする。 状態ごとの振る舞いや状態遷移の考慮漏れ・未 記載 状態遷移図や状態遷移表を作成して、状態遷移の考慮漏れ を防ぐ。 状態遷移図や状態遷移表を作成して、状態遷移がすべて定義 されているかチェックする。 状態遷移テストで状態遷移を網羅的にテストする。機能の振る 舞いをテストする際に、状態と組み合わせてテストする。 状態の認識を誤っている 各状態の呼び名と定義をドキュメント化して、定義した状態名の み使うようにする。 レビューアが理解した状態遷移を、仕様と別の表現形式で表現 し、認識違いがないかを仕様作成者がチェックする。 テスト担当者が理解した状態遷移に基づいてテストケースを作 成し、認識違いがないかを仕様作成者がチェックする。 仕向け条件考慮せず 仕向けごとの仕様の違いをドキュメント化してチェックできるように する。 仕向けごとの仕様の違いに詳しい人にレビューをお願いする。 仕向けごとの仕様の違いに詳しい人にテストをお願いする。 振る舞いの矛盾 仕向けごとの仕様の違いを減らして、矛盾が起こりにくくする。減 らせない場合、形式言語など、矛盾が生じない表現形式で表現 する 仕向け独自の仕様と、それ以外の部分の仕様を突き合わせて、 矛盾がないかレビューする。 仕向け独自の機能と、それ以外の機能を組み合わせてテストす る。 言語ごとに異なる仕様や、画面レイアウトの未記 載 言語ごとの違いをドキュメント化してチェックできるようにする。 言語ごとの違いに詳しい人にレビューをお願いする。 言語ごとの違いに詳しい人にテストをお願いする。 言語ごとの表示する内容の不一致 他言語に翻訳しやすい平易な表現を使う。 対象の言語に詳しい人・得意な人にレビューをお願いする。 各言語で表示している内容が同じ内容を表しているか、テストす る。 制限事項の未記載 製品やシステムの状態の一覧を作成し、状態とハードウェアキー の組み合わせごとに制限の要・不要を定義する。 製品やシステムの状態の一覧を作成し、状態とハードウェアキー の組み合わせごとに制限の要・不要が定義されているかチェックす る。 製品やシステムの状態ごとにすべてのハードウェアキーを操作する テストを行う。 キー押下時の共通仕様と、個別の機能の仕様 の矛盾 キー押下時の共通仕様を先に定義し、個別の機能の仕様を定 義する際にチェックできるようにする。 キー押下時の共通仕様と、個別の機能の仕様を突き合わせて レビューする。 テストケースの期待結果を作成する際に、キー押下時の共通仕 様と個別の機能の仕様の両方を見ながら作成する。 遷移元の未記載 画面遷移図を作成して、画面遷移の考慮漏れを防ぐ。 画面遷移図を作成して、ありえる画面遷移がすべて定義されて いるかレビューする。 画面遷移のテストを作成する際に、遷移元から遷移する手順を 具体的に記載する。 他の製品の画面遷移仕様との矛盾 他の製品の画面遷移仕様をドキュメント化してチェックできるよう にする。 連携する他の製品・システムの仕様に詳しい人にレビューをお願 いする。 テスト用に他の製品・システムを用意し、実際に連携して画面遷 移のテストを行う。 COTS（既製品）の動作が想定外の場合の 仕様の考慮漏れ・未記載 利用する既製品が想定外の動作をする前提で、仕様を定義す る。 既製品との連携に関する仕様をレビューする際に、想定外の動 作時のエラー処理が定義されているか確認する。 既製品の想定外の動作をエミュレートし、その際のテスト対象の 動作をテストする。 他の製品のエラー時動作との矛盾 利用する既製品のエラー仕様をドキュメント化してチェックできる ようにする。 利用する既製品のエラー仕様に詳しい人にレビューをお願いす る。 テスト用に既製品を用意し、実際にエラーを起こしてテストを行 う。 ビジネスルール・ロジックの考慮漏れ・未記載 ビジネスルールなどのドメイン知識をドキュメント化してチェックでき るようにする。 ビジネスルールなどのドメイン知識に詳しい人にレビューをお願い する。 テスト対象の製品やシステムの利用シーンを想定してシナリオテ ストを行い、必要なビジネスルール・ロジックが盛り込まれているか 確認する。 ビジネスルール・ロジックとの矛盾 ビジネスルール・ロジックを減らしたり単純化して、矛盾が起こりにく くする。それができない場合、形式言語など、矛盾が生じない表 現形式で表現する ビジネスルール・ロジックのドキュメントと仕様を突き合わせて、矛 盾がないかレビューする。 テスト対象の製品やシステムの利用シーンを想定してシナリオテ ストを行い、ビジネスルール・ロジックと矛盾なく利用できるか確認 する。
hikarut
leveragestech
kenta_hi
sansan_randd
yud0uhu
enforcerpl
yasumuusan
yukukotani
makenowjust
.jpg){kind=avatar}
m3_engineering
cygames
databricksjapan
hursman
addyosmani
tammyeverts
tmm1
wjessup
trishagee
davidbonilla
phodgson
sstephenson
garrettdimon
holman
bkeepers
