システム開発は、システムで実現したいこと（要求）があって、それをコンピュータという(融通の利かない）機器で実現できる形（プログラムとかデータとか、機器とか）にするまで段階的に詳細化してゆく作業と、作られたものが要求どおり動くかどうかを確認するテストという作業に分かれる。コンピュータネタ、目次へここで段階的詳細化の過程は、要件定義とか基本設計とか詳細設計とか仕様とかプログラミングといった名称で大きく分けられることになる。で、これらの区別を迷わずに済む程度に説明してくれるものは今のところ見つかっていない。これでどうやって設計するんだ、とずっと思っていたが、その辺があまり問題にならない理由に思い当たった。
違っていてもなんとかなるのだ。各工程の担当者の間で意識の違いがあっても、それは吸収される。というのは、例えば基本設計の担当は「基本設計の成果物はこのようなもので、この程度の詳らかさで書かれているべきだ」という意識があるはずである。それがなかったら成果物は出てこない。で詳細設計の担当にそれを渡す。もしそれが詳細設計の担当者が期待するほど緻密なものでなかったとしても、詳細設計者はぶつくさいいながら自分の意識する詳細設計の成果物を作る。で、これがプログラマーに行き着く。こうなると成果物のレベルは誰が見ても明らかになる。コンピュータがプログラムを受け付けてくれるか、という絶対の基準がある。そんなわけで、とりあえずモノができるまでの間、段階的詳細化の区分けについての意識がぶれても、それほどの問題とならないのだ。問題があるとするとパターンは２つ。自分が認識していた以上のことをやらされた、例えば詳細設計者の守備範囲が広すぎて、作業レベルが下がってしまうこと。もう一つは外部が絡む場合である。基本設計者が「このデータはこのシステムからもらってくる」と書いたが、実は（物理的）制限がある場合である。先方のファイルにアクセスに行ったが、毎月第二水曜日夜間はMS-Windowsのパッチ適用で先方のサーバが止まっている、とか判明した場合である。月次のことならまだ気のつけようもあるが、滅多にない通貨コード変更、どのタイミングで通貨テーブルが更新されるか、なんてあまり考えたくない。
とりあえず、プログラミングまでの間においてフェーズ分けはある程度おおまかで、各担当間で意識が共有されていなくてもなんとかなりそうなことは分かった。しかし、テストフェーズがそうであると致命傷になるかもしれない。
テストフェーズもＵＴ、ＩＴ、ＳＴとか分けられるが、これがどういう基準で分けられているのが、実は判然としない。ＵＴはまだ分かる。プログラマーが自分の作ったものがちゃんと動くか確認するのだ。これは責任持ってやってくれるだろう。
Ｖ字モデルという奴を持ってくると、詳細設計で記載されていることが実現されているかをＩＴで、基本設計書をＳＴで確認、とおさまりがいいが、であるならば、基本設計書が完成したときにはＳＴの項目くらいはできているはずであろう。世間的にそうなっているかは甚だ疑問。むしろ、ＩＴは結合テスト、ＳＴはシステムテスト、と言うように「テストに必要なプログラムやハードウェアがそろったところで」ＩＴなりＳＴなりをやっているような気がする。（ついでに言うと基本設計を作ったときにＳＴの項目を作ってしまうと、例外ケースの対応に弱点がありそうだ。例外ケースって書きにくい。）テストに必要なプログラムがそろったところで、ハードやデータを調達してテスト環境を整え、てテスト。中小規模の環境を作ってＩＴ、大規模な環境を作ってＳＴ、オンラインまで動かしてＯＴ。効率的だ。やるほうからするとこの方がおさまりがよい。
となると、どのフェーズでどの種類のテストをやるかというのが問題になる。具体的なテスト項目をグループ分けしないと。というわけで私が唯一知っているまとめ、日経ＩＴｐｒｏの記事に再度ご登場願う。
ここまで自分で考えて読み直すとこれを書いた石川さんの意識に疑問符。Ｖ字モデルと、「起動終了確認テスト」はどのフェーズ、と分けた表を作るのはこれまでに書いた理由で、なじみが良くない。と直感したところで、あ、分かった。なんで僕と石川さんで「起動終了確認テスト」をどのフェーズでやるかという意見に違いがあるのか。
開発標準化のルールを作るとき、まず新規開発を念頭に置く。派生開発に比べて考えやすいから当然と言えば当然。でプログラミングまではこれでなんとかなるかもしれないが、テストとなると少々困ったことになる。
テストは効率を重視して、必要なプログラムがそろったところで環境を構築して実施、ということを考える。それを前提に、テスト項目種類（さっきの「起動終了確認テスト」とか）をどのフェーズにプロットしてゆくかを考える。分類基準は「どのフェーズで可能か」。すると「サブルーチン一つ作ったからといって、入力画面の方とは結合していないから、入力値をいろいろ取らせるというのはできないな、せいぜいデバッガを使って外部変数に何かを入れてやるくらい。〜つまりInteger宣言の変数に文字を入れるとどうなるか、という例外テストはできない〜だから入力バリエーションテストはＩＴ」という判断が出てきて、これはこれで納得。
しかし、先ほどと同じ分類基準「どのフェーズで可能か」を使って、今度は派生開発に適用することを考えると、別の結論が出る。サブルーチン一つ修正しました。で、元からあった入力画面のプログラムはライブラリから引っ張ってくればリンク可能だから、入力値をいろいろ変えて、挙動を見る、というテストは可能。ということで「入力バリエーションテストはＵＴ」。少しでも上流で修正したほうがコストは安く済むから、この方が望ましい。なるほど、テスト項目種類をテストフェーズにプロットする表が他にないはずだ。これは固定化してはいけないのだ。用意できるテスト環境によって臨機応変に決めていかなければならない。ただしこれでは、必要なテストを都度考えることになり、漏れや重複が出やすい。するとＶ字モデルのほうが落ち着きは良くなる。
が、Ｖ字モデルはテスト設計が大変そうだ。プログラミングまでの開発フェーズは上流工程ほど人が少ない。というわけで設計したのと同じ人が担当するとするとＩＴよりもＳＴのほうがテストを担当する人は少なくなる。それでは回らないだろう。
実際は修正を考えて、システムリリース直前までプログラマをキープしておかねばならないので、テストはプログラムを担当した人間にも割り振る。でもこの辺に品質向上のヒントはあるような気がするな。やっぱりテスト計画書は先に作ろう。プログラマにプログラム仕様と、ＩＴ，ＳＴのテスト計画書を同時に渡せば、多少なりとも大局的見地からみてコードを書いてくれるかもしれない。最悪なのは、新規開発を前提としてテスト項目を種類分けし、それを派生開発でも（場合によってはＶ字モデルでも）守ってしまうこと。構造的にテスト項目漏れが発生するからである。
１行書くのにここまで考えてしまった。
特定のテスト項目をどのテストフェーズで行なうかについて、担当間で意識のズレがある。これがテストもれの原因となっている可能性がある。
でも、解決策としてテスト項目種類のフェーズ分けを見直す、とするわけには行かんのだよなあ、さっき考えた結果では「臨機応変」が望ましいわけだから。