開発方法論のまとめ　５ - 実践！情報処理試験講座

先ほどの続きです。

　結合テストは、いくつかのモジュールをまとめます。
　まとめるといっても、たとえば、１画面レベルでのまとめもあるし、
　ある程度の画面がまとまった、一連の流れのテストも考えられます。

　このため、ＩＴ１、ＩＴ２と２種類のテストをやる場合もあります

　　ＰＴ→ＩＴ１→ＩＴ２→ＳＴ

となります。ＩＴ２よりももっと細かく、ＩＴ３，ＩＴ４・・・と続ける
プロジェクトもある場合があります。
　テスト仕様書の書き方は、単体のときと同じです。富士通の場合、ＩＴ用の
仕様書があります。ブラックボックステストが中心です。

　テストの行い方ですが、画面入力して確認するということで、手作業になるのですが、
Ｗｅｂの場合、自動的に入力してテストしてくれる、seleniumというのがあります

　とくに、回帰テストに向いているのですが、回帰テストについては、後で書きます。

　複数のモジュールをつなげて行うので、ここで、バグが出ることが多く、
その場合、単体で起こるよりも、深刻です（派生範囲が広い）。
　バグが起こった場合、

　　　１．バグ票を書く
　　　２．管理台帳に記入
　　　３．プログラマが対応
　　　４．対応した旨を管理台帳に記入
　　　５．バグ報告者が確認
　　　６．管理台帳に書く

　というながれになります。このとき、修正ソースは、どこのタイミングでいれるか？という話になります。５を行うために、内輪で公開して、６でリリースタイミングを決めるというかんじが多いのかしら？

　電子化されていれば、省略できる工程もあります。この電子化したものを、バグトラッキングシステム（ＢＴＳ）といい、有名なものにtracがあります（その勉強会Shibuya.tracは有名ですね）

　そして、ソースが修正されていくのですが、これをばらばらに直していったら、ぐちゃぐちゃになってしまうので、ちゃんと整合性をとっていく必要があります。それが構成管理で、構成管理のツールとしては、SVN(Subversion)やＣＶＳなどがあります。

　また、修正したとき、バグの箇所は確認しますが、修正に伴い、今までちゃんと動いていたところを壊してしまう可能性もあります。そのため、いままで動いていたところもテストしなおさないといけません。
　これが、「回帰テスト」（リグレッションテスト）になります。

　ただ、そんなこんなでテストすると、爆発的にテストケースが多くなります。
　テストケースを押さえる技術としては、直行表があります。

●総合テスト（ＳＴ・ＯＴ）

まず、要求仕様書の非機能要件に応じて、性能を満たしているかどうかを図る、
総合テスト（ＳＴ）があります。

ブラックボックステストになります。
富士通の場合、仕様書があります

テストツールとしては、JMeterなどがあります。
ここで、性能を満たしていないとなると、しゃれにならないことになります。

最終的には、要求仕様書の機能要件であり、ＲＦＰにも書かれている業務が
ちゃんとできるかという、運用テスト（ＯＴ）を行います。

　これにより、開発が終わったので、あとマニュアルとかを適当（適切）に書いて、
必要なものを納品します。

　納品されたものを、発注者側は、契約書に基づき、検収します。
　検収したら、検収結果報告書(検収完了報告書）を発注者側が書き、開発者側に送ることになります。
　検収合格となると、支払いになります。

　さて、この際、契約に基づき検収を行うわけですが、
　契約の雛形というのを、ＪＩＳＡが出しています。

JISAソフトウェア開発委託契約書（平成14年5月版）
http://www.jisa.or.jp/legal/contract_model2002.html

実際には、契約は

・ＮＤＡ(秘密保持契約）
・基本契約
・業務契約
　　　契約書→金額が書かれてる紙に収入印紙
　　　発注仕様書

など、いろいろにわかれます。検収の場合は、発注仕様書に対して行います。

ということで、開発一巡しましたかね。