プログラマに渡すテスト結果に載せるべき項目を教えて下さい。

Question

表題の通り、ソフトのテストをして結果をプログラマに渡したいのですが
どんなフォーマットで渡せば良いのか、分かりません。
（私はプログラムは全く出来ません）
どなたか、お力を貸して頂けませんか？

詳細をお話すると、ソフトのテストを頼まれました。
動作確認をして、要修正箇所（エラー発生箇所）を表にして渡してくれ、というものです。
プログラマが超多忙のため、急遽できそうなことを手伝うことになり、
テストを頼まれた次第です。

テストをするソフトは、OS上で動作する業務システムです。
プログラム言語が何かは分かりません。
既に全体が完成していて、ユーザー使用のインターフェイスから、
実際の業務と同じ動作をし、不具合が出た箇所を表にして欲しいというものです。

プログラマに渡す一覧には、最低限何を記載する必要がありますか。
また、これも記載されていると親切、というものはありますか。
実際の現場で使用しているフォーマットのような物があれば、
参考程度にその項目を教えていただきたいのですが。

本来ならば、依頼してきたプログラマに聞くべきなのですが、急ぎの仕事なので
そのプログラマと連絡がつくまで待っていると、テストが終わらなそうで困っています。
頼まれた時には「分かれば、どんなのでもいい」と言われたのですが
実際やり始めてみると、エラーが出たときエラー番号はメモした方が良いのか、
ダイアログの文面まで知らせるべきなのか、
エラーが出なかった箇所は表に載せなくていいのか、など疑問が出てきました。

以上よろしくお願いします。

pangnya · Accepted Answer

この手の業務を行っていたのは、もうだいぶ以前になりますので、忘れてしまっている部分もあるかもしれませんが、ご容赦下さい。

１．エラーが発生した業務名
　　・もし解ればプログラム名も

２．エラーが発生した時の正確な状況
　　・何をどうしたら、こうなった
　　　（例えば、１を入力したら変な値が出た）
　　・何をどうしたら、こうならなかった
　　　（２を入力したら正確な値が出た）

３．エラー発生時のエラーメッセージ
　　・もし、メッセージが出た場合は、出来るだけ詳しく正確に（エラーコードも）

４．エラーの再現性
　　・もう一度、同じ操作をしても、同じエラーが発生したかどうか

うーんと、今思い付くのは、こんなところですね。
もし、また思い出したら、また書き込みます。

pangnya · Answer

-izayoi-さん、適切にシステムテストの手順をまとめていただいてありがとうございました。

私は、もう現場を離れてから１０数年も立っており、システムテスト？といわれても、しばらく思い出せませんでした。
当時、私がシステム設計にたずさわりましたあるシステムは、現在でも某所で動いておりますが、たしか、仕様書、設計書が４０００ページほどであったのに対して、私が書いたシステムテスト仕様書は、２万ページを越えていたことを思い出しました。
当時、私は、設計者である自分と、それを作ってくれたＰＧさんへの、それこそ嫌がらせのように、ありとあらゆる可能性を考え出し、どんな人が操作しても大丈夫なようなテスト仕様書を作ったつもりでしたが、それを当時の上司に提出したところ、たちどころに盲点を付かれてしまい、人間を想定してちゃ駄目だ、サルが出鱈目にいじっても絶対に大丈夫なようにしろと言われたことを思い出しました。
当時は大型コンピューターを使い、ＣＯＢＯＬで開発しておりましたが、いつの間にか時代は変わって、今ではオフコンから、さらにパソコンにまでシステムの単位が変わってしまいました。
最近では、ＣだのＬｉｎｕｘだのと、今の私には訳の分からない世界になってしまいました。
もう、私は現場には戻ることは無いと思いますが、今のパソコンですら、当時の私達には夢のような性能を実現しています。
これからは、若いＳＥさん達に、逆に私達が教わらないと時代について行けなくなりそうです。

う～ん、こんなところで、感慨に浸ってどうしようというのでしょうか？
何だか、さっきのテスト項目を挙げただけで、現役のＳＥだった頃を思い出してしまいました。

No.1339276さん、テスト頑張ってくださいね。
それでは、大変失礼しました。

kaiu · Answer

Ｎｏ．４です。
大事なものを忘れてました。
・Ｎｏ．
・テスト実施日
・（必要に応じて）大項目
・（必要に応じて）中項目
・（必要に応じて）小項目
・テスト内容（←！！）
・結果（○・×か良・不可等）
・備考（障害表Ｎｏ．○○-○○など）
実施者は表の上にでも書いておけば良いと思います。

kaiu · Answer

フォーマットについてですが
エクセルか何かでざっと表形式が一般的な気がします。
行には
・Ｎｏ．
・テスト実施日
・（必要に応じて）大項目
・（必要に応じて）中項目
・（必要に応じて）小項目
・結果（○・×か良・不可等）
・備考（障害表Ｎｏ．○○-○○など）
で、ＰＧ側としては不可項目に障害時の
画面のハードコピーがあると助かります。
不可項目のみの障害表を簡単に作成しましょう。
オペレーション・現象・再現性等を
別ファイルにまとめてハードコピーを付けます。
下記もご参考になれば。

参考URL：http://www.stackasterisk.jp/tech/engineer/devp03_01.jsp

-izayoi- · Answer

最低限必要な項目としては、
・不具合が発生する操作手順
です。
そのとき、
・どのような不具合が起きたか
も、できるだけ詳細に記録しておくと良いです。
エラーの文面や番号なども、あるに越したことはないと思いますが、「不具合が発生する操作手順」で、現象を再現できるのであれば、プログラマの方で確認できますので、時間が無いのであれば、端折っても良いと思います。
なお、不具合というのは、操作結果として明確にエラーが出ることだけではなく、正常に処理を終えたようでも期待通りの結果が得られないことも指します。
この場合は、操作手順だけでなく、現象（例えば、Ａという結果になるべきなのに、Ｂという結果になる）も伝える必要があります。

効率最優先で、「不具合が出た箇所」だけが必要ということであれば、以上にあげた２つの情報を一覧にまとめれば良いと思います。

しかし、動作確認の本来の目的は、不具合無く動作することを確認するものですから、可能ならば以下のように作業を進めるべきです。

まず、あらかじめテスト項目（操作の手順 → 期待する結果）書き出します。（漏れが無いように・・。観点については、pangnyaさんが回答されていますので、参考になさって下さい。）
作成した項目に沿って、テストを進めます。期待通りに動作した項目は、正常であった旨を記録します。期待通りに動作しなかった項目は、不具合として、どのような結果になったかを記録すれば良い訳です。
このように作業を進めることで、不具合なケースだけでなく、正常なケースを確認（記録）できますし、不具合の割合など、品質分析の基礎データにもなります。
テストの進捗具合も数量的に確認できますので、テストがいつ終わるかの目処も立ち易いです。
このように、ただ思い付くままにテストするのではなく、計画を立ててからテストするのが、漏れなく確実にテストする為に必要なプロセスです。

pangnya · Answer

NO.１です。
もう一つ、大事なチェックを忘れていました。
設計者、プログラマー泣かせの、嫌なチェックです。

５．例外テスト
　　・本来は入れるはずのないデータをわざと入力してみる
　　・選択項目等がある場合、例えば１～３のどれかを選択するような場合に、わざと４とか０とかを押してみる
　　・その他、通常ならやらない操作をわざとしてみる

これらのテストは、業務上で想定していない操作が行われた際に、システムがどうなるかを判断します。
この、例外処理がプログラム上考慮されていない場合、予想外の動作をしたり、最悪、システムダウンを起こします。
人間誰でも操作を間違えることは当前のようにありますので、その間違い操作にも対応していなければ、安全なシステムは構築できません。

プログラマに渡すテスト結果に載せるべき項目を教えて下さい。

この手の業務を行っていたのは、もうだいぶ以前になりますので、忘れてしまっている部分もあるかもしれませんが、ご容赦下さい。

-izayoi-さん、適切にシステムテストの手順をまとめていただいてありがとうございました。

Ｎｏ．４です。

フォーマットについてですが

最低限必要な項目としては、

NO.１です。

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング