誰がテスト計画を書くべきですか？

私は社内の開発チームに所属しており、マーケティングチームの要件に従って会社のWebサイトを開発しています。受け入れテストのためにサイトをリリースする前に、従うべきテスト計画を提供するように依頼されました。

ただし、開発チームは、要求者からの要求であるため、何をテストするか、何を探すべきか、どのように動作するかなどについて最良の知識を持っているため、テスト計画は不要であると感じています。私たちは常にこれについて議論しています。開発者は次のようなことを書き留めるのは時間の無駄です。

1. ボタンAをクリックします。
2. フォームフィールドにXYZと入力し、ボタンBをクリックします。
3. 動作Cが表示されます。

これは、要求された要件/機能ごとに繰り返す必要があります。これは基本的に、要件ドキュメントに既にあるものを言い換えたものです。

プロジェクトの管理にはアジャイルアプローチを使用する方向に進んでおり、これは各反復の終了時にも要求されます。

単体テストと統合テストは別として、エンドユーザー受け入れテスト計画を立てるのは誰ですか？それは要求者ですか、それとも開発者ですか？

よろしくお願いします。

CK よろしく

テスト計画は開発者によって書かれるべきではありません。テスト計画が行うことの一部は、開発者が要件を正しく解釈したかどうかを確認することです。開発者は、作成するコードでテスト計画を効果的に作成できません。テスト計画は、QAを実施する予定の人またはビジネスアナリストが作成する必要があります。開発者が計画を書く必要がある場合は、誰かが彼が書くプログラムの部分の計画を書くように割り当てないでください。

これは、開発者が書いたコードをテストして、期待どおりに機能するかどうかを確認する必要があるため、ユニットテストの設計とは異なることに注意してください。ただし、テスト計画は、アプリケーションが期待どおりに動作するかどうかをテストすることです。これは、アプリケーションが効果的に機能するように技術的に設計されている方法を知らない人が行う必要があります。

QAチームはテスト計画を作成して実行する必要があります。

理想的には、テスト計画は機能仕様と並行して作成する必要があります-機能をテストする方法について考えることが頭に集中し、仕様を改善するのは驚くべきことです。

スクラムの答え：「完了の定義」を定義したい場合、テスト計画を持つことがすぐに1つの項目になることがわかります。テストされていない場合に、実行するストーリーを他にどのように説明できますか。

テスト計画を作成する責任があるのは誰ですか？チーム

チームは誰ですか？製品の実現に取り組むすべての人は、チームのメンバーである必要があります。

したがって、あなたのケースでは、「開発チーム」にテスト計画を書くことができる人を含める（または雇う）ことができます。アジャイルに移行する場合、テスト計画の作成が開発の並行で行われることに気付くでしょう。どちらも同じストーリーから始まり、コミュニケーションを通じて最終的に同期して同時に配信されます。利害関係者が批判的であるとみなすテストケースに合格する前に、ストーリーを「完了」と宣言しないでください。

機能テスト計画は、機能/ビジネスアナリストが作成する必要があると思います。彼らは機能分析を記述し（アジャイルで作業している場合でも、分析があることを前提としています）、テストのためにアプリケーションのどのパスをたどるべきかを書き留めます。

それは完全にあなたがどのように働いているかに依存しますが、私の意見では、開発者はアプリケーションのテスト方法、それをテストするために使用するデータなどに関する機能文書を書くべきではありません。

以下は、両方のグループを幸せにし、アジャイルアプローチに移行するのに適したアイデアです。

ユーザー受け入れチェックを自動化し、それらをスクリーンキャストします。

http://pragprog.com/magazines/2009-12/automating-screencasts

あなたが抱えている問題の一部のように思えますが、作成しているテスト計画は非常に反復的であり、純粋に確認的なものです。正直に言って、私はあなたがテストを書いていることをまったく呼ばないでしょう-それが要件を確認するだけであるなら、それはチェックしています。これを自動化してスクリーンキャストすることで、顧客向けのきちんとしたデモを定期的にパッケージ化できます（毎日短い時間で送信することもできます）。テスト計画を開いたり、デモを見たりするよりも、デモをクリックして見る可能性が高くなります。それを通して作業を開始するので、うまくいけば、より迅速なフィードバックが得られます（よりアジャイルなアプローチに移行する場合は非常に重要です）。コンポーネントを再利用できるため、作業負荷が軽減されます。

また、要件を実際に実行する方法も提供します。GojkoAdzicの実行可能な仕様に遭遇しましたか？ここを見てください：http : //gojko.net/2010/08/04/lets-change-the-tune/ これを、顧客にデモするために要件を実行可能な形式にする方法として考えている場合、それから突然、それははるかに無意味になります。

今、私のテスターの帽子をかぶって、スクリーンキャストがうまくいかない場合、あなた/あなたの利害関係者がいくつかの適切なテストを行うために解放されることを指摘できることを光栄に思っています。要件を確認するだけでなく、スクリーンキャストを提供することをお勧めします。たとえば、次のように、フィードバックを追加したい分野についての短い質問または提案を提供します。

1）これが新しい登録フォームです。このスクリーンキャストを見て、どのように機能するかを確認してください！

フィードバックのお願い：このフォームには、お客様が間違ったデータを入力できないようにするためのチェック機能が追加されています。お客様が受け取ったときに表示されるエラーメッセージを確認してください。間違ったものを入れて、お客様が理解しやすいと思うかどうか教えてください。
また、特に異常な顧客データ（本当に長い名前、非常に短い名前、または名前に異常な文字が含まれている人など）がある場合は、厳格すぎるかどうかも知りたいです。または私たちが考えていなかった他の何か、またはおそらく彼らの住所に通りの名前またはそのような変なものがない？

つまり、素晴らしいスクリーンキャストを提示し、フィードバックを求め、具体的すぎることなくフレーミングし、確認するだけでなく、潜在的な問題について考えさせます。それらを取得思考だけではなく、テスト計画を通じて盲目的クリックするのを、。あなたは基本的に彼らのために探索的試験憲章を書いています。（アジャイルテストの象限を見ると、これらは象限3のテストになります）。

例としてあなたの家を改修してみましょう。請負業者が作成したチェックリストを受け入れて、請負業者があなたに代わって何をしたかを確認してもらいますか または、独自のチェックリストを考えて、請負業者があなたが指定したことを行ったかどうかを確認しますか？

答えは明らかです。要求者は、要求したものが仕様に従って行われたかどうかを確認する必要があります。彼/彼女は彼/彼女の自身のチェックリストを持って来て、アプリをテストするべきです。このリストに対して。

ただし、開発者は独自のチェックリストを用意し、アプリを処理する前に適切な内部テストが行​​われ、バグがクリアされていることを確認する必要があります。UATのために。理想的には、開発者はこれらのテストのほとんどをテストスクリプトの形式で自動化する必要があります。TDDを覚えていますか？理想的には、アプリケーションのコンポーネントをテストするためのテストスクリプト（この場合は単体テストケース）を作成する必要があります。次に、これらの単体テストケースを組み合わせて、統合テストとその後の回帰テストを実行するテストスイートを作成する必要があります。

エンドユーザー受け入れテスト計画は通常、クライアントまたは顧客を代表する会社のビジネスアソシエートによって作成されます。これは、クライアントが必要とする機能を表すものであり、QAの統合テストを補完するものです。ユーザー受け入れテストの主な目的の1つは、QAと開発が顧客が望んでいるものを実際に正確であることを確認することであるため、QAも開発もユーザー受け入れテストを効果的に計画できません。