良いテストケーステンプレート/サンプルはどこにありますか？

Question

私はより正式な要件とテスト手順を確立しようとしていますが、関係するドキュメントの参考例は見つかりません。

現時点では、フィーチャフリーズテスターがデプロイメント前に「アプリケーションをクリックする」の後、テストする必要のある正式な仕様はありません。 （されている

1. ユーザ登録フォーム
   1. 国]ドロップダウン：

      まず、私がテストする必要があるすべての機能を指定した文書のことを考え、このようなもの（これを構成します）よ国が正しく、サーバーからフェッチ？）

   2. パスワード検証（すべてのパスワードルールが観測され、ユーザーパスワードが弱すぎる場合に通知される？）
2. ありがとうございます。

...などです。これは、プログラマーがコーディングを開始する前に、クライアントが要件の一部として署名できるものとしても役立ちます。フィーチャーリストが完成した後、私はこのリストをスプレッドシートの最初の列にすることを考えています。この列には、最後にテストした機能がいつテストされたか、動作したか、動作しなかったかが表示されます。これは、テスターが各テストサイクルの後に満たすことができる文書を私に与えるだろう。そうすれば、プログラマーは、うまくいかない情報と、いつ破たんしたのかという情報を持たなければならない。

1. ロードユーザー登録フォーム：

   第二に、私のような詳細な手順で、テスターのテストケースを考えています。

2. （機能1.1）国のチェックボックスをクリックします。
   1. 国は国に設定されていますか？
   2. 国名はローカライズされていますか？
   3. 各言語の並べ替え順は正しいですか？
3. （Feature 1.2）このパスワードを入力します： "a"、 "bob"、 "password"、 "password123"、 "password123＃"最後のパスワードのみを受け入れる必要があります。
4. 「OK」を押します。
5. （特集2）ありがとうございます。
   1. サポートされるすべての言語にローカライズされたテキストですか？

このは、テスターに​​最初の文書で機能へのポインタで、に注意を払うためにどのような具体的な例とチェックリストを与えるだろう。これにより、私はテストプロセスの自動化を開始することができます（現在、単体テストとは別にテストの自動化はありません）。

私はいくつかの例を探しています。通常、テスターは1時間または2時間ですべてのテストを行うことができます。私は次のバージョンのためにどの機能を実装すべきか、そして新しい機能がすべて実装され、既存の機能がすべて動作していることをテスターが確認してプログラマーに報告するというクライアントの意見を一致させる簡単な方法を探しています。

これはほとんどがWord/Excelドキュメントのカップルでなければならない内部のテスト資料です。私は2日間で1つのテスト/バグフィックスサイクルを維持しようとしています。私はプログラミング時間、新しい機能や他の方法（JIRA）の顧客チケットの実装を追跡しています、これは基本的にドキュメントをテストすることになります。これは私が考えていたライフサイクルです：

1. PMは機能のリストを作成します。顧客はそれに署名する。 （文書1が作成されます）
2. テストケースが作成されます。 （文献2）
3. プログラマーは機能を実装しています。
4. テストケースに応じたテスタテスト機能。 （そして、ドキュメント1にバグを報告してください。）
5. プログラマーがバグを修正しました。
6. すべてのバグが修正されるまでGOTO 4。
7. 内部テストの終了。製品は顧客に示されます。

誰かが、テストケースのあるサンプルドキュメントが見つかる場所を知っていますか？また、上記で概説したプロセスに関するヒントはすべて歓迎します。 :)

Answer 1

私は2つのドキュメントを開発しました。

一つは、あなたのより多くの '標準のウェブサイト'（例えばビジネスWebプレゼンス）のためである：

http://pm4web.blogspot.com/2008/07/quality-test-plan.html

私は、Webベースのアプリケーションに使用する他の1：

http://pm4web.blogspot.com/2008/07/writing-system-test-plan.html

希望それは助ける。

Answer 2

まず、要件文書とテストケース文書を組み合わせることが最も大事なのは、両方の情報が同じで、テスターとテストケースの前にユーザーと開発者は要件を強化し、さまざまな視点を提供します。 http://www.volere.co.uk/template.htm#anchor326763 - テストするステップ、結果として期待されるテスト、エッジ/バウンドのケース - を追加すると、非常に堅牢な要件仕様と1つのテスト仕様が得られるはずです。

手順については、テスター、開発者などが評価結果を評価し、次のラウンドの要件/テスト文書を更新する評価手順を含めることを忘れないでください（多くの場合、あなたが考えることができなかったし、仕様に追加する必要があります...両方の要件の観点からとテスト1）。

mindmapping/work-breakdown-structureを使用して、すべての要件を正しく取得していることを確認することを強くおすすめします。

Answer 3

作業を開始する前に、詳細な仕様が絶対必要です。それ以外の場合は、開発者は何を書き込むべきか、いつ終了するかを知らない。 Joel Spolskyはこのトピックについて、例を挙げてa good essayと書いています。しかし、開発中に仕様が変更されずに残っているとは思わないでください。

上記のmeadeは、テストと仕様を組み合わせることを推奨しています。これはTest Driven Developmentとして知られており、非常に良いアイデアです。自然言語はしばしばそうではないように物事を固定し、仕事の量を削減します。

また、ユニットテストと自動化について考える必要があります。これは時間を大幅に節約し、品質を向上させます。 GUIレベルのテストは自動化が難しいかもしれませんが、できるだけ薄いGUIレイヤーを作成し、その下にある機能のテストを自動化する必要があります。これは、アプリケーション全体を徹底的にあなたが好きなだけテストすることができるので、開発の後の大きな節約になります。マニュアルテストは高価で遅いので、コーナーをカットする強い誘惑があります。「Fooモジュールを変更しただけなので、テスト7,8,9を繰り返すだけです。その後、顧客は、Barモジュールの何かが壊れていると不平を言い、FooはBarが開発者が見逃した不明瞭な副作用があることが判明しました。自動化されたテストは実行するのが安価であるため、自動化されたテストがこれを捕捉しますこのようなバグについては、hereを参照してください。

アプリケーションが必要な大きさであれば、TDDを使用してモジュールを指定し、それらのモジュールテストを自動テストに変えます。

非常に単純なアプリケーションでない限り、すべての手動テストを実行するには少し楽観的です。すべてのエラーケースとメインパスをテストする必要があることを忘れないでください。

Answer 4

デビット・ピーターソンのConcordion web-siteは、優れた仕様（および前記仕様を実行するためのフレームワーク）を記述するための手法について非常に優れたページを持っています。彼のアドバイスは簡単で簡潔です。

Dan NorthのBehavior-DrivenDevelopment（BDD）については、classic blog postを参照してください。非常に役立ちます！

Answer 5

古いバグレポートを確認し、テストケースを作成します。特定の古いバグをテストし、さらに一般化することができます。同じ種類のバグが何度も繰り返される傾向があるので、実際のバグを捕まえ、不可能な（または非常に高価な）完全なカバレッジに関するテストスイートを提供します。

GUIとWebオートメーションを利用します。例えば、Seleniumである。あなたが思っている以上に多くのことを自動化することができます。たとえば、ユーザー登録シナリオは簡単に自動化されます。人間がチェックする必要がある場合でも、ブラウザのクロステストなど、正しいことを確認する場合は、QAエンジニアが監視している間にテストを記録して再生することができます。開発者は、バグを自動化し、それをQAに伝えるために難しいステップを記録することもできます。それらをプロジェクトの一部として保存します。彼らにテストの意図についての良い説明を与えてください。チケットにリンクしてください。テストがもはや機能しなくなるようにGUIが変更され、それが起こると、その意図をカバーするようにテストを書き直すことができます。

私は、ポール・ジョンソンがGUIレイヤーをできるだけ薄くすると言ったことを強調します。フォーム（GUIまたはHTMLまたは書式）と機能（機能）を分離し、機能のテストを自動化します。国リストを生成する関数を持って、それを完全にテストしてください。そして、それを使ってHTMLやAJAXなどを生成する関数です。実際の作業を行う関数が十分にテストされているため、正しいかどうかテストするだけです。ユーザーログイン。パスワードチェック。メール。これらはすべて、GUIなしで動作するように記述することができます。これは、行わなければならない手間のかかる手作業によるテストの量を大幅に削減します。