誰がテスト計画を書くべきですか？
私は社内の開発チームに所属しており、マーケティングチームの要件に応じて自社のWebサイトを開発しています。受け入れテストのためにサイトをリリースする前に、従うべきテスト計画を彼らに与えるように要求されました。
ただし、開発チームは、要求者からの要求であるため、何をテストするか、何を探すべきか、どのように動作するかなどについて最良の知識を持っているため、テスト計画は不要であると感じています。私たちは常にこれについて議論しています。開発者は次のようなことを書き留めるのは時間の無駄です。
- ボタンをクリックします[〜＃〜] a [〜＃〜]。
- フォームフィールドに[〜＃〜] xyz [〜＃〜]と入力し、ボタン[〜＃〜] b [〜＃〜]をクリックします。
- 動作[〜＃〜] c [〜＃〜]が表示されます。
これは、要求された要件/機能ごとに繰り返す必要があります。これは基本的に、要件ドキュメントに既にあるものを言い換えたものです。
プロジェクトの管理にはアジャイルアプローチを使用する方向に進んでおり、これは各反復の終了時にも要求されます。
単体テストと統合テストは別として、エンドユーザー受け入れテスト計画を立てるのは誰ですか？それは要求者なのか開発者なのか？
よろしくお願いします。
よろしく
CK
テスト計画は開発者によって書かれるべきではありません。テスト計画が行うことの一部は、開発者が要件を正しく解釈したかどうかを確認することです。開発者は、作成するコードでテスト計画を効果的に作成できません。テスト計画は、QAを実施する予定の人またはビジネスアナリストが作成する必要があります。開発者が計画を作成する必要がある場合は、作成するプログラムの一部の計画を作成する人を割り当てないでください。
これは、開発者が書いたコードをテストして、期待どおりの結果が得られるかどうかをテストする必要があるため、ユニットテストの設計とは異なることに注意してください。ただし、テスト計画は、アプリケーションが期待どおりに機能するかどうかをテストすることです。これは、アプリケーションが効果的に機能するように技術的に設計されている方法を知らない人が行う必要があります。
QAチームはテスト計画を作成して実行する必要があります。
理想的には、テスト計画は機能仕様と並行して作成する必要があります-機能をテストする方法について考えることがどのように心を集中させ、仕様を改善するかは驚くべきことです。
スクラムの答え：「完了の定義」を定義したい場合は、テスト計画を持つことがすぐに1つの項目になることがわかります。テストされていない場合に、実行するストーリーを他にどのように説明できますか。
テスト計画を作成する責任があるのは誰ですか？チーム
チームは誰ですか？製品の実現に取り組むすべての人は、チームのメンバーである必要があります。
したがって、あなたのケースでは、「開発チーム」にテスト計画を書くことができる人を含める（または雇う）ことができます。アジャイルに移行する場合、テスト計画の作成が開発の並行で行われることに気付くでしょう。どちらも同じストーリーから始まり、コミュニケーションを通じて最終的に同期され、同時に配信されます。利害関係者が重要であるとみなすテストケースに合格する前に、ストーリーを「完了」と宣言しないでください。
機能テスト計画は機能/ビジネスアナリストが作成する必要があると思います。彼らは機能分析を記述し（アジャイルで作業している場合でも、分析があると想定しています）、テストのためにアプリケーションのどのパスをたどるかを書き留めます。
それは完全にあなたがどのように働いているかに依存しますが、私の意見では、開発者はアプリケーションのテスト方法、それをテストするためにどのデータを使用するかなどの機能文書を書くべきではありません。
両方のグループを幸せにする可能性のあるアイデアを以下に示しますandアジャイルアプローチに移行するのに適しています。
ユーザー受け入れチェックを自動化し、スクリーンキャストします。
http://pragprog.com/magazines/2009-12/automating-screencasts
あなたが抱えている問題の一部のように思えますが、あなたが書いているテスト計画は非常に繰り返しが多く、純粋に確認的です。正直なところ、私があなたがテストを書いていることをまったく呼ぶつもりはありません-要件を確認するだけの場合は checking です。これを自動化してスクリーンキャストすることで、顧客向けのきちんとしたデモを定期的にパッケージ化できます（短い日数で送信することもできます）。テスト計画を開いてデモを見るよりも、デモをクリックして視聴する可能性が高くなります。それを通して作業を開始するので、うまくいけば、より迅速なフィードバックが得られます（よりアジャイルなアプローチに向かっている場合は非常に重要です）。コンポーネントを再利用できるため、ワークロードが軽減されます。また、開発者は通常、ドキュメントを書くよりもコードを書く方がはるかに楽しめます。
また、要件を実際に実行する方法も提供します-Gojko Adzicの実行可能な仕様に出くわしましたか？ここを見てください： http://gojko.net/2010/08/04/lets-change-the-tune/ これを要件を取得する方法として考えている場合顧客にデモするための実行可能フォームを使用すると、突然、無意味になります。
今、私のテスターの帽子をかぶって、スクリーンキャストがうまくいかない場合、あなた/あなたの利害関係者がいくつかの適切なテストを行うために解放されることを指摘できることを光栄に思っています。要件を確認するだけでなく、スクリーンキャストを提供し、さらにフィードバックが必要な領域についての短い質問や提案を提供することをお勧めします。次に例を示します。
1）これが新しい登録フォームです。このスクリーンキャストを見て、どのように機能するかを確認してください！
フィードバックのお願い：このフォームには、お客様が間違ったデータを入力できないようにするための追加のチェックが多数追加されています。お客様が受け取ったときに表示されるエラーメッセージを確認してください。間違ったものを入れて、お客様が理解しやすいかどうかを教えてください。
また、非常に厳格なケースがあるかどうかも知りたいです-特に異常な顧客データ（本当に長い名前、非常に短い名前、または異常な人物）がある場合彼らの名前の文字、または私たちが考えなかった他の何か、あるいはおそらく彼らの住所に通りの名前やそのような変なものがないのですか？）おそらくあなたはそれらを試すために数分を費やすことができるでしょうか？
つまり素敵なスクリーンキャストを提示し、フィードバックを求め、それをtoo具体的にせずにフレーミングし、単に確認するのではなく、潜在的な問題について考えさせます。テスト計画を盲目的にクリックするのではなく、それらを取得する考える。あなたは基本的にそれらのために 探索的試験憲章 を書いています。 （ Agile Testing Quadrants を見ると、これらは第3象限のテストになります）。
例としてあなたの家を改修してみましょう。請負業者が作成したチェックリストを受け入れて、請負業者があなたのために行ったことを確認するように依頼しますか？または、独自のチェックリストを考えて、請負業者があなたが指定したことを行ったかどうかを確認しますか？
答えは明らかです。要求者は、要求したものが仕様に従って行われたかどうかを確認する必要があります。彼/彼女は彼/彼女の自身のチェックリストを持って来て、アプリをテストするべきです。このリストに対して。
ただし、開発者は独自のチェックリストを用意し、アプリを処理する前に適切な内部テストが行われ、バグが解消されていることを確認する必要があります。 UATのために。理想的には、開発者はこれらのテストのほとんどをテストスクリプトの形式で自動化する必要があります。 TDDを覚えていますか？理想的には、アプリケーションのコンポーネントをテストするためのテストスクリプト（この場合は単体テストケース）を作成する必要があります。次に、これらの単体テストケースを組み合わせて、統合された回帰テストを実行するテストスイートを作成する必要があります。
エンドユーザー受け入れテスト計画は通常、クライアントまたは顧客を代表する会社のビジネスアソシエートによって作成されます。これは、クライアントが必要とする機能を表すものであり、QAの統合テストを補完するものです。ユーザー受け入れテストの主な目的の1つは、QAと開発が顧客の望んでいることを実際に正確であることを確認することであるため、QAも開発もユーザー受け入れテストを効果的に計画できません。