現在、最新プロジェクトの新しいリリースに向けてテスト部門を準備しています。ソフトウェアをテストし、バグがリリース前に私たち (開発チーム) に確実に返されるようにするための綿密な計画に従うことを明らかに望んでいます。
このテスト計画を作成する際に従うべき適切なツールや方法論はありますか?
10706 次
6 に答える
10
このテーマに関して私が見つけた最良の本は、Managing the Testing Processです。著者は、テスト計画の作成方法について説明します。
私の経験では、テスト計画の基本は次のとおりです。
- 機能の説明
- 仮定
- 関連ドキュメント
- テスト マトリックス
- 有効なテスト
- 無効/エラー条件テスト
- 状態テスト (動作は、オブジェクト/システムのさまざまな状態に基づいています)
- ストレステスト
- 性能試験
- パフォーマンス指標
- 必要なツール
- 環境に関する懸念事項 (特定のハードウェア、ブラウザ、OS など)
あなたがそれを埋めることができれば、チームはテストをうまく実行できるはずです.
決定する必要があるのは、テスト チームの能力はどれくらいかということです。テスト計画は、すべてのテスト ケースを導出するためのアルゴリズムであることが望ましいです。ケースの種類を説明しますが、必ずしも各ケースを詳細に説明する必要はありません。チームの能力が低い場合は、各ケースを具体的に説明する必要がある場合があります。
最後に 1 つの注意事項。詳細すぎるというサイレンの呼び出しを避けてください。頭の中に入れておくことができない計画は、実行される可能性が低いです。テスト計画が 25 ページの長さである場合、書きすぎている可能性があります。
于 2009-04-30T17:21:14.190 に答える
4
そして忘れないでください、あなたがしたいすべてのテストをするのに十分な時間は決してありません。したがって、計画内のテストに優先順位を付ける必要があります。リスクによる優先順位付けが最善の方法であることがよくあります。
ただし、通常、テスト計画は、開発者およびPMと協力して、QAグループによって作成されます。QAが独自に計画を作成していない場合は、QAチームがアップグレードを使用できるようです。少なくとも、開発者が初期計画をまとめている場合でも、QAは異なるPOVを持つため、いくつかの入力を提供する必要があります。テスト計画に目を向けるほど、それはより完全になります。
于 2009-05-01T14:07:25.597 に答える
1
pavliks さん、どの程度基本的なものをお望みかはわかりませんが、シンプルで簡単に取り入れて実行できるものが必要な場合は、この記事をご覧ください:システム テスト計画の作成
ソフトウェアの知識があり、MS Word がインストールされていて、文書化のスキルがあれば、問題ありません。
それに付随する非常に基本的で一般的なバグ ロギング プロトコルに関しては、以下をご覧ください。
--LM
于 2010-06-08T08:46:09.773 に答える
0
Tom Eが指摘するように、QAは絶対にテスト計画を作成する必要があります。彼らは、要件を理解するために顧客と協力し、実装を理解するために開発チームと協力する必要がありますが、結局のところ、テストマインドセットを持つチームがテスト計画を所有する必要があります。
QAチームのテスト計画を作成する必要があると私が考えることができる唯一の状況は、製品にまだ精通していないQAを行う外部委託チームがある場合です。その場合、設計と開発の際に、チームの1人または2人の上級メンバーを同じ場所に配置することをお勧めします。それは彼らがはるかに速くスピードを上げるのを助け、彼らはその知識をチームの他のメンバーに伝えることができます。
于 2009-07-31T15:05:08.420 に答える
0
試行:成果物: テスト計画
于 2009-04-29T16:33:54.110 に答える
-1
単体テストと統合テストは、コード レベルで多くの問題を検出する必要がありますが、ユーザーの観点からシステムがどのように動作するかをテストするには適していません。
機能が何をすべきか、それが機能するかどうかを知る方法がわかったら、TestComplete、SmarteScriptなどを使用してそのテストを自動化します (明らかに意味がある場合) 。これらのテストは実行が簡単で自動化されているため、見落としを心配することなく常に一貫して実行されます。
于 2009-07-31T14:49:21.707 に答える