• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:「テスト仕様書」の運用について ・どういう手法として知られているか)

テスト仕様書の運用方法とは?

このQ&Aのポイント
  • テスト仕様書の運用方法について質問があります。通常の仕様書と同時に、あるいは少し遅れたタイミングでプログラマに渡す方法や、稼働中のユーザと同じ動作環境で予定の出力結果を示す方法など、テスト仕様書の効果や品質向上について知りたいです。
  • テスト仕様書の運用について調査しています。テスト仕様書の添付により、元の仕様書の不備を明らかにしやすくなり、プログラマの仕様の理解に勘違いがあれば早めに正すことができます。また、テスト結果を得ることで検収や作業の迅速化が図れます。テスト仕様書の運用方法やその効果について教えてください。
  • テスト仕様書の運用方法について教えてください。テスト仕様書の添付により、元の仕様書の不備を明らかにし、プログラマの勘違いに早めに気付くことができます。また、テスト結果を早めに得ておくことで検収や作業の迅速化ができます。テスト仕様書の運用方法やその効果について教えてください。

質問者が選んだベストアンサー

  • ベストアンサー
回答No.5

取り敢えずは、専門用語だけを。 #4さんがおっしゃっているのは、「テスト・ファースト」ですね。 同じソフト開発でも、オブジェクト指向分析・設計などになってくると、UMLなどのようなモデリング手法を用います。#3さんがおっしゃられていることも、最近では「ユースケース図」や「イベントフロー」、「シナリオ」などを使うことが多いです。特に「ユースケース図」では、「粒度を揃える」ことが最重要です。何でもかんでもユースケース図を書きまくってしまうと、『一部だけを早めに摘み食いする』ことが出来なくなりますから。後は、状態遷移を表すのには、「ステートマシン図」なんてのもあります。 「テスト仕様書」の作成段階では、やはり「レビュー」でしょうか。作成されたドキュメント類に対して、仕様の抜けが無いのかなどを同じメンバー内で総チェックですね(いわゆる、事前報告)。同じレビューでも、厳密には「キックオフ」をちゃんと行い、配布資料等を渡すことによって、事前に質問や疑問点などを用意しておいてもらったら、さらに効率性がアップします。

その他の回答 (5)

  • sinjou
  • ベストアンサー率13% (492/3662)
回答No.6

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

  • tomo316
  • ベストアンサー率35% (51/142)
回答No.4

アジャイル開発プロセスでは有りませんか。 臨機応変に変更することを前提として、できるだけ少しずつ作り、その過程で発見された問題について、できるだけ早く確実に対処を行ういリスクを軽減しながらの開発していこうとする手法です。 仕様書よりテストを重視します。 テスト(仕様書 ↓ PG作成 ↓ 評価(テスト これを繰り返します。 代表的な手法としてはXP(エクストリーム・プログラミング)が有名です。 詳しくは、「アジャイル XP(エクストリーム・プログラミング)」で検索 バグは少なかったですよ。

  • sinjou
  • ベストアンサー率13% (492/3662)
回答No.3

仕事でバグ起票するんですが・・・ 単なる仕様もれが多いです。 設計書の下書き段階で、仮UIの設計書を一枚用意して、テスターにテストさせりゃいいのに・・・と、いつも思います。 要求定義の段階で、テスターを呼んで、仮テストさせてくれれば良いのに・・・と、いつも思います。 でも、日本のソフトソフトウェアはまだ20年しか歴史がないので、現在20代後半でシステムエンジニアリングの研究を行っている人材がおっさんになる時代まで待たないと、そういう考えは常識化しないようです。 日経BP辺りが出版してるアメリカ人が原著のQA業務に関する出版物が無難かも。 私も上司に「書籍もネットにもバグの元を断つ情報がないで~・・・・うなだれ。」 と聞いてみましたが、「当たり前だ、(バグデータベースは)社外秘なんだから。」 との回答でした。 で、QAを置いてるなんちゃって外資的な会社さんの場合は、 「受入テスト項目書」なるものをエクセルで作っておられました。 ・最大値 ・最小値 ・タブの移動数 ・罫線の初期値 ・全角入力可 ・半角入力可 などが記してありました。 とりあえず、気付いた事からコツコツと、 ・エクセルに箇条書き ・エクセルにバグショットを貼り付ける ことから始めてみてはいかが? 実際、プログラマーから言われた事です。 バグ起票は時間のロスなので、「こいつでいい(充分だ)!」、と言われた時の手法です。 これを下書きにして、エクセルに必要項目を書き起こし、エクセルの罫線を駆使して、簡易UI画面を付け足していくのです。 文献がないので、あくまで参考まで。 50代の方は、ワードやノーツに文章で設計書を書く人が多いなあ・・・と思います。 30代の方は、実際のUIショットをエクセルに貼り付ける人が多いのかなあ・・・と思います。 役立たずレスだったらごめんなさい。 でも、仮設計の段階でテスター呼んじゃえば、設計漏れは8割回避できると思います。

  • lv4u
  • ベストアンサー率27% (1862/6715)
回答No.2

>>…こういった手法は既に良く知られ、何かの名前が付いているものなのでしょうか。 書店で立ち読みなどをして文献を探したのですが(笑)、該当すると思われるものはありませんでした。 「既に良く知られ」ている単語は無いと思います。ネットで検索しても、ぴったりのものって出てきませんね。 実際には、昔から請求関係など、「絶対に間違った結果は出せない」って思えるシステムのテストでは、行われていました。逆にいえば、結果が間違っていても「社内のことだから・・・」で済むようなシステムは、やっていないことも多いと思います。 >>手法としての名前や、何か参考資料の在り処等を教えて頂ければと思います。 「シナリオテスト」っていうのがそれなりに、ぴったりきそうに思います。この分野の参考書は少ないです。テスト技法の古典として有名な「ソフトウェア・テストの技法 第2版」がお勧めだと思います。初版が1980年で、2006年に第2版が出て、Webプログラム、エクストリーム・プログラミングなど、新しい分野が追加されています。

kistune
質問者

お礼

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

  • bin-chan
  • ベストアンサー率33% (1403/4213)
回答No.1

結果の境界値を用意して行うのが「ブラックボックステスト」  (中身は重視せず、結果に着目) 内部の判定条件分岐すべてを網羅して行うのが「ホワイトボックステスト」  (中身を重視、結果にも着目) テスト仕様は要求定義書に基づいて作成すると思います。

kistune
質問者

お礼

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

関連するQ&A

専門家に質問してみよう