いままで、単体テストの抽出についてまとめたので、それ以外のテスト項目について。
まず、一般に、テストの目的は、２とおり考えられる
・品質の保証（向上）
・契約書・仕様書に書いてあることが実現されていることの証明
上記の「品質の保証（向上）」の場合は、結合以上のテストの場合、シナリオに基づきテストするとか、一般的な、総合テストの話になってしまう。
これは、市販のテストの本を見るなり、セミナーにでればいいだけだから、このブログでとりたてていうことの話ではないでしょう。
そういう本を、読んでください。で終わる話。
問題は、下のほうの
・契約書・仕様書に書いてあることが実現されていることの証明
これは、契約書や、それを展開している仕様書の書き方による。
契約書が機能で定義されているもの、たとえば、
本契約は、甲の受注システムを開発することを目的とし。。。
なんて、書かれてしまっている場合は、どうしょうもない。
受注システムの「受注」とは、なんのことかの範囲規定がない。
相手が、「こんなシステムではない」と言われれば、それにお付き合いするか、お金は切り取れないかのどちらかになってしまう。
なので、もはや、テストの世界とは、関係ない（テストできない）。
ちなみに、これを応用し、アジャイルとあわせると、ＳＥさん、プログラマーさんを、死ぬまで、こき使うことができる（それも、ものすごーい安い金額で）。
その方法については、（やばいかなあ、言うの・・・）まあ、やばくなさそうなら、後日発表するとして、今日は、別の契約書の書き方を検討します。
ふつう、上記の事態を避けるため（奴隷のようにこき使われないために）、契約書の文言は、以下のように、入出力とあわせて規定する（と思う）。
本システムは、受注システム、・・・より構成される
受注システムは、受注情報、商品情報、。。。を入力とし、受注表、。。。を出力するシステムである。
このように規定すると、出力データが出力できた時点で開発終了となり、それをテストすることになる。
そして、この契約書（具体的には発注仕様書）は、コンテキストダイヤグラムをもとに作成すればよい。
この場合のテストは、素直に、入力情報が記載されているもの（仕様書に、～を入力としとか、～を取得しとか書かれる）から、出力しなければいけないもの（仕様書に～を出力しとか、～を表示しとか書かれる）が、出力されているかどうかを確認すればよい。
だから、仕様書から、入出力のキーワード（入力し、出力し、など）を拾って、その入出力を実現する機能をみつけて、その機能を、その入出力で、動作させることをテスト項目とすればよい。
エビデンスは、その入出力した物自体（画面の場合、ハードコピー）や、ログとなる。
なので、まさにこいつは、情報処理試験の午後２の論文感覚。。。
アクセス
トータル
ランキング
