仕様書から単体テスト以外のテスト項目を抽出する方法

　いままで、単体テストの抽出についてまとめたので、それ以外のテスト項目について。

まず、一般に、テストの目的は、２とおり考えられる

・品質の保証（向上）

・契約書・仕様書に書いてあることが実現されていることの証明

---

　上記の「品質の保証（向上）」の場合は、結合以上のテストの場合、シナリオに基づきテストするとか、一般的な、総合テストの話になってしまう。

　これは、市販のテストの本を見るなり、セミナーにでればいいだけだから、このブログでとりたてていうことの話ではないでしょう。

　そういう本を、読んでください。で終わる話。

---

　問題は、下のほうの

・契約書・仕様書に書いてあることが実現されていることの証明

これは、契約書や、それを展開している仕様書の書き方による。

　契約書が機能で定義されているもの、たとえば、

本契約は、甲の受注システムを開発することを目的とし。。。

　なんて、書かれてしまっている場合は、どうしょうもない。
　受注システムの「受注」とは、なんのことかの範囲規定がない。
　相手が、「こんなシステムではない」と言われれば、それにお付き合いするか、お金は切り取れないかのどちらかになってしまう。

　なので、もはや、テストの世界とは、関係ない（テストできない）。

　ちなみに、これを応用し、アジャイルとあわせると、ＳＥさん、プログラマーさんを、死ぬまで、こき使うことができる（それも、ものすごーい安い金額で）。

　その方法については、（やばいかなあ、言うの・・・）まあ、やばくなさそうなら、後日発表するとして、今日は、別の契約書の書き方を検討します。

---

　ふつう、上記の事態を避けるため（奴隷のようにこき使われないために）、契約書の文言は、以下のように、入出力とあわせて規定する（と思う）。

本システムは、受注システム、・・・より構成される
　受注システムは、受注情報、商品情報、。。。を入力とし、受注表、。。。を出力するシステムである。

　このように規定すると、出力データが出力できた時点で開発終了となり、それをテストすることになる。
　そして、この契約書（具体的には発注仕様書）は、コンテキストダイヤグラムをもとに作成すればよい。

　この場合のテストは、素直に、入力情報が記載されているもの（仕様書に、～を入力としとか、～を取得しとか書かれる）から、出力しなければいけないもの（仕様書に～を出力しとか、～を表示しとか書かれる）が、出力されているかどうかを確認すればよい。
　だから、仕様書から、入出力のキーワード（入力し、出力し、など）を拾って、その入出力を実現する機能をみつけて、その機能を、その入出力で、動作させることをテスト項目とすればよい。

　エビデンスは、その入出力した物自体（画面の場合、ハードコピー）や、ログとなる。

　なので、まさにこいつは、情報処理試験の午後２の論文感覚。。。

流通システム開発センターのページにある、ビジネスモデル、結構良く出来てて、参考になると思う

ものものさんの、「たまゆら雑記」のブログの、積読　「ビジネス・プロセス・モデル調査研究報告書」にでてくる、流通システム開発センターの、流通システム化に関する研究開発、いけてる！かもしんない。

　事業自体は、どーでもいいんだけど（いいんかい ^^;)

---

　そこの、(1) ビジネス・プロセス・モデルの策定 にある、「ビジネス・プロセス・モデル調査研究報告書」が、ざっと見た限りでは、よく出来ていると思う。

　参考になるのは、
　　１０、１１ページの図、概略としては、きれいだと思う。
　　１２ページからの表は、一般的なプロセス内容としては、こんなもんだと思うので、
　　　実際に、自分たちが行おうとしている開発は、ふつうとどこが違うのかを比較する
　　　たたき台として使えると思う。
　　２４ページの図（３－１０）、いいっすねえ。
　　　取引条件（特売とか）の説明、きれいかも。。
　　３０ページから６４ページまでの物流関係と支払い関係は、知識として、
　　　読んでおいてもらうと、共通の意識が持ちやすいと思う。
　　　必要なことがきれいにまとまっている。

---

　(2) ビジネス・モジュールの基本設計 にかんしては、ロジックを、追っかけてないので、正しいかどうかわかんかいけど、ちょっと見た範囲では、

「ビジネス・モジュール基本設計報告書」をダウンロードして、解凍すると現れる、

・2-1-0要件定義\2-1-1システムユースケース検討\ユースケース図及び業務フロー.pdf
　内容が細かいので、このままでは、使いずらいが、とても参考になると思う

・2-2-0外部仕様設計
ビジネスプロセスが、まず、全体をつかむのにわかりやすいと思う。
　そのほかについて、よく見てないけど、いいんでないかい！！

・2-3-0内部仕様設計
　一番使えるのは、データベース設計書.pdfのデータベース設計のER図と、テーブル仕様テーブル仕様は、ウィリアムのいたずらが最近のブログで書いてきた、Excelの仕様書に近い形式で書いてあるし、ここまで、はっきりと、テーブル設計してあれば、標準として、わかりやすいんでないかい！

　データディクショナリも、いいかんじでついてきてるし（？？）

---

　ということで、流通業をやっている人は、自分たちのシステムと、標準と、どこが違うかとか、通論を学ぶのには、いいドキュメントだと思います。

　たまには、流通システム開発センターもやるじゃん。バーコード以来のヒットっていう感じです。

　あ、でも、実際にやろうとしている、「流通SCM共通プラットフォーム」は、どーでもいいんだけどね（いいんかい！！）

月末、月初にデータ変えるのも、怖いよね＆納品時に話しかけるのは、やめましょう。

　いま、前のブログで書いた会社から抜け出てきて、他の会社にいるんだけど、

　結局、データを作り直すけど、もう、月末月初だから、月初を過ぎてから、作り直しデータに入れ替えるってことになったみたい。
　たしかに、月末、月初には、月次処理が走るから、そーいうタイミングにデータ入れ替えたくないよね。。。

　新しいデータに入れ替えて、バグがおきて、月次処理を走らせられない！なんてなったら、残業になっちゃったりするから、たしかに、ユーザーさんは、いやだよね。

　なっとく。

---

　で、その入力データを消しちゃった原因なんだけど、

　他の人に話しかけられ、そちらに気をとられ、ついうっかり、入力したデータに、もとの（入力前の）ファイルを、コピーしちゃって、（メッセージボックスがでて）はい！にしてしまったらしい。。

　うーん。

　納品時に話しかけるのは、やめましょう。

　（そーいう問題なのか？そういう問題かも？？）

Access（に限らんが）、自動的にバックアップ取っておいたほうがいいかもよ！

　いまね、ある会社さんにお邪魔してるんだけど、

　そこでね、ある人（その会社の社員の人）が、Accessで入力したデータを
　午後、納品しようとして。。。

　ぎゃー！まちがって、入力したデータのほうを、消しちゃったあ！

　午後納品なのに。。。(@_@!)

　っていう、状態みたいです。。。
　やばやばだよね。。。さあ、にげよーっと。

　Accessに限らんが、ある程度データを入力したら、バックアップを取ってくれるような仕組み（人的仕組みにしろ、自動化するにしろ）が、必要かもかも。。。

　みなさんは、注意しましょうね！
　（もちろん、ウィリアムのいたずらもだけど。。。）