「テスト仕様書」の運用について ・どういう手法として知られているか

質問

業務系のソフトウェアを開発・販売・保守している会社にいます。
今回、プログラム開発の過程に「テスト仕様書」というものが導入されることになりました。
通常、プログラマレベルでのプログラムの作成→担当SEもしくはその他の人がそれを検収の上ユーザに納入、という流れを取っています。
（ここにいう「作成」「納入」というのはシステム全体を納入するといったことではなく、例えば数十以上の実行ファイル等でできあがっているシステム全体のうち、実行ファイルを1コ追加する、といった単体レベルの話です。）
「テスト仕様書」の運用方法なのですが、
(1)通常の仕様書と同時に、あるいは少し遅れたタイミングでプログラマに渡す。
(2)稼働中のユーザと同じ動作環境のもとで、ごく限られた条件と、その条件によって出てくる予定の出力結果が提示してある。…帳票などでは範囲を広く指定すれば大量の出力結果が得られるわけですが、例えば「得意先は○○、商品は○○」の場合は「金額は○○円」と出てくる筈、というふうにごく一部だけが示してある。
(3)テスト結果をプログラム作成の終了と同時に、場合によっては途上で担当SEなどに早めに提出する。
…というものです。
趣旨としては、
(1)「テスト仕様書」の添付により、もともとの仕様書の不備を明らかにしやすくなり、かつ、プログラマの仕様の理解における勘違いを早めに正す。
殊に、誤解を招きやすい仕様の箇所に重点を置くと効果を発揮する。
(2)作成されたプログラムの本検収に取り掛かる前に一部でもテスト結果を早めに得ておくことで、検収やそれ以後の作業の迅速化を図る。（おもむろに取り掛かった本検収でプログラムの不備が初めて明らかになるより、ごく一部のテスト結果をちらっと見るだけでそれが間違いであることが分かればすぐに修正を依頼することができる。）
(3)一部のテスト結果が正しければ全体も正しいという蓋然性が高まるので、プログラムの品質の向上に繋がる。
…というものです。
趣旨は良く分かりますし、特に「一部だけを早めに摘み食いする」という(2)の着眼点というのは面白いと思います。また、「得られるべき結果」を予測しておくための労力（言い換えれば「テスト仕様書」を作成するための時間)はかかりますが、あるべき出力結果を考えるというのはどのみち後でしなければならないことなので全体としての工数は変わらないという考えもあるようです。
…こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。
書店で立ち読みなどをして文献を探したのですが（笑）、該当すると思われるものはありませんでした。
手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。

回答No.5

choconamacream · ベストアンサー

取り敢えずは、専門用語だけを。

#4さんがおっしゃっているのは、「テスト・ファースト」ですね。

同じソフト開発でも、オブジェクト指向分析・設計などになってくると、UMLなどのようなモデリング手法を用います。#3さんがおっしゃられていることも、最近では「ユースケース図」や「イベントフロー」、「シナリオ」などを使うことが多いです。特に「ユースケース図」では、「粒度を揃える」ことが最重要です。何でもかんでもユースケース図を書きまくってしまうと、『一部だけを早めに摘み食いする』ことが出来なくなりますから。後は、状態遷移を表すのには、「ステートマシン図」なんてのもあります。

「テスト仕様書」の作成段階では、やはり「レビュー」でしょうか。作成されたドキュメント類に対して、仕様の抜けが無いのかなどを同じメンバー内で総チェックですね（いわゆる、事前報告）。同じレビューでも、厳密には「キックオフ」をちゃんと行い、配布資料等を渡すことによって、事前に質問や疑問点などを用意しておいてもらったら、さらに効率性がアップします。

回答No.6

sinjou

業務系のソフトウェアの場合、膨大な人員が必要なので、プロジェクトがこけた場合、膨大な人件費と時間の無駄使いが発生します。
それを設計段階で8割方根絶するために、
「テスト時の操作性」「エンドユーザーの操作性」
を同居させた設計書を書いてしまうと合理的で良いかも。
開発中のビルドをぶん取ってきて、それを見ながらプロジェクト結成時のテスターにテスト仕様書を書かせてたPMがいました。
無謀だなあ・・・と思ったのですが、無理な設計箇所が発生するのを防ぐ意味があると思います。
業務系の場合、設定メニューのつまみ食いだけはやっておかないと・・・いやーっつ（悪夢がーっつ）！！
という事態が有るかも。

回答No.4

tomo316

アジャイル開発プロセスでは有りませんか。
臨機応変に変更することを前提として、できるだけ少しずつ作り、その過程で発見された問題について、できるだけ早く確実に対処を行ういリスクを軽減しながらの開発していこうとする手法です。

仕様書よりテストを重視します。

テスト（仕様書
↓
PG作成
↓
評価（テスト

これを繰り返します。

代表的な手法としてはXP（エクストリーム・プログラミング）が有名です。

詳しくは、「アジャイル　XP（エクストリーム・プログラミング）」で検索

バグは少なかったですよ。

回答No.3

sinjou

仕事でバグ起票するんですが・・・
単なる仕様もれが多いです。
設計書の下書き段階で、仮UIの設計書を一枚用意して、テスターにテストさせりゃいいのに・・・と、いつも思います。
要求定義の段階で、テスターを呼んで、仮テストさせてくれれば良いのに・・・と、いつも思います。

でも、日本のソフトソフトウェアはまだ20年しか歴史がないので、現在20代後半でシステムエンジニアリングの研究を行っている人材がおっさんになる時代まで待たないと、そういう考えは常識化しないようです。
日経BP辺りが出版してるアメリカ人が原著のQA業務に関する出版物が無難かも。

私も上司に「書籍もネットにもバグの元を断つ情報がないで～・・・・うなだれ。」
と聞いてみましたが、「当たり前だ、（バグデータベースは）社外秘なんだから。」
との回答でした。

で、QAを置いてるなんちゃって外資的な会社さんの場合は、
「受入テスト項目書」なるものをエクセルで作っておられました。
・最大値
・最小値
・タブの移動数
・罫線の初期値
・全角入力可
・半角入力可
などが記してありました。

とりあえず、気付いた事からコツコツと、
・エクセルに箇条書き
・エクセルにバグショットを貼り付ける
ことから始めてみてはいかが？
実際、プログラマーから言われた事です。
バグ起票は時間のロスなので、「こいつでいい（充分だ）！」、と言われた時の手法です。

これを下書きにして、エクセルに必要項目を書き起こし、エクセルの罫線を駆使して、簡易UI画面を付け足していくのです。

文献がないので、あくまで参考まで。
50代の方は、ワードやノーツに文章で設計書を書く人が多いなあ・・・と思います。
30代の方は、実際のUIショットをエクセルに貼り付ける人が多いのかなあ・・・と思います。

役立たずレスだったらごめんなさい。
でも、仮設計の段階でテスター呼んじゃえば、設計漏れは8割回避できると思います。

回答No.2

lv4u

>>…こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。
書店で立ち読みなどをして文献を探したのですが（笑）、該当すると思われるものはありませんでした。

「既に良く知られ」ている単語は無いと思います。ネットで検索しても、ぴったりのものって出てきませんね。
実際には、昔から請求関係など、「絶対に間違った結果は出せない」って思えるシステムのテストでは、行われていました。逆にいえば、結果が間違っていても「社内のことだから・・・」で済むようなシステムは、やっていないことも多いと思います。

>>手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。

「シナリオテスト」っていうのがそれなりに、ぴったりきそうに思います。この分野の参考書は少ないです。テスト技法の古典として有名な「ソフトウェア・テストの技法　第２版」がお勧めだと思います。初版が１９８０年で、２００６年に第２版が出て、Ｗｅｂプログラム、エクストリーム・プログラミングなど、新しい分野が追加されています。

お礼

「シナリオテスト」…なるほど、良く調べてみます。書籍の紹介もありがとうございます。

回答No.1

bin-chan

結果の境界値を用意して行うのが「ブラックボックステスト」
　（中身は重視せず、結果に着目）

内部の判定条件分岐すべてを網羅して行うのが「ホワイトボックステスト」
　（中身を重視、結果にも着目）

テスト仕様は要求定義書に基づいて作成すると思います。

お礼

ご回答ありがとうございます。
そうですね、ブラックボックステストの一種のような気がします。