6

現在よりも正式な要件とテスト手順を確立しようとしていますが、関連するドキュメントの適切な参照例が見つかりません。

現時点では、機能フリーズテスターが展開前に「アプリケーションをクリックして」実行した後、テストする必要のある正式な仕様はありません。

まず、テストする必要のあるすべての機能を指定するドキュメントについて考えています。これは次のようなものです（これを構成します）。

  1. ユーザー登録フォーム
    1. 国のドロップダウン（国はサーバーから正しくフェッチされていますか？）
    2. パスワードの検証（すべてのパスワードルールが守られていますか？パスワードが弱すぎる場合はユーザーに通知されますか？）
  2. 登録ありがとうございます

...等々。これは、プログラマーがコーディングを開始する前に、クライアントが要件の一部として署名できるものとしても機能する可能性があります。機能リストが完成したら、このリストをスプレッドシートの最初の列にして、機能が最後にテストされたのはいつか、機能したか、機能しなかった場合はどのように壊れたかを示すことを考えています。これにより、テスターが各テストサイクルの後に記入できるドキュメントが得られるので、プログラマーは、何が機能せず、いつ壊れたかについての情報を含む、やることリストを作成する必要があります。

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

  1. ユーザー登録フォームをロードします。
  2. （機能1.1）国のドロップダウンメニューを確認します。
    1. 国のドロップダウンには国が表示されていますか？
    2. 国の名前はローカライズされていますか？
    3. 言語ごとにソート順は正しいですか？
  3. （機能1.2）次のパスワードを入力します： "a"、 "bob"、 "password"、 "password123"、 "password123＃"。最後のパスワードのみを受け入れる必要があります。
  4. 「OK」を押します。
  5. （特徴2）お礼状を確認してください。
    1. テキストはサポートされているすべての言語にローカライズされていますか？

これにより、テスターに​​特定のケースとチェックリストを提供し、最初のドキュメントの機能へのポインターを示します。これにより、テストプロセスの自動化を開始することもできます（現在、単体テスト以外のテスト自動化はあまりありません）。

あまり事務処理をせずに、他の人がこれをどのように行ったかの例を探しています。通常、テスターは1〜2時間ですべてのテストを実行できる必要があります。次のバージョンでどの機能を実装するかについてクライアントに同意させ、テスターがすべての新機能が実装され、既存のすべての機能が機能していることを確認し、プログラマーに報告する簡単な方法を探しています。

これは主に内部テスト資料であり、Word/Excelドキュメントのカップルである必要があります。1回のテスト/バグ修正サイクルを2日以内に維持しようとしています。プログラミング時間、新機能の実装、他の方法での顧客チケット（JIRA）を追跡しています。これは、基本的にドキュメントのテストになります。これは私が念頭に置いていたライフサイクルです。

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

テストケースを含むいくつかのサンプルドキュメントを見つけることができる場所へのポインタを誰かが持っていますか？また、上記で概説したプロセスに関するすべてのヒントを歓迎します。:)

4

5 に答える 5

2

私が使用する 2 つのドキュメントを開発しました。

1 つは、より「標準的な Web サイト」 (ビジネス Web プレゼンスなど) 用です。

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

もう 1 つは Web ベースのアプリケーションに使用します。

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

それが役立つことを願っています。

于 2009-05-17T05:07:08.483 に答える
1

DavidPetersonのConcordionWebサイトには、優れた仕様を作成するための手法（およびその仕様を実行するためのフレームワーク）に関する非常に優れたページがあります。彼のアドバイスはシンプルで簡潔です。

同様に、Behavior-DrivenDevelopment（BDD）に関するDanNorthの古典的なブログ投稿を確認することをお勧めします。非常に役立ちます！

于 2009-05-11T00:01:04.440 に答える
1

まず、要件ドキュメントとテスト ケース ドキュメントを組み合わせることが最も理にかなっていると思います。なぜなら、情報の大部分は両方で同じであり、要件をテスターの前に置き、テスト ケースをユーザーと開発者の前に置くことで要件が強化されるからです。それらのさまざまな視点を提供します。ドキュメント レイアウトの良い出発点は次のとおりです。かなり堅実な要件仕様とテスト仕様が 1 つにまとめられています。

ステップについては、評価ステップを含めることを忘れないでください。ここで、あなた、テスター、開発者などがテスト結果を評価し、次のラウンドのために要件/テスト ドキュメントを更新します (多くの場合、できなかったことに出くわします)。要件の観点とテストの観点の両方から、仕様に追加する必要があります)。

また、すべての要件を適切に把握するために、マインドマッピング/作業分解構造を使用することを強くお勧めします。

于 2009-05-08T02:33:44.350 に答える
0

作業を開始する前に、詳細な仕様が絶対に必要です。そうしないと、開発者は何を書くべきか、いつ終わったのかわかりません。Joel Spolskyは、このトピックに関する優れたエッセイを例を挙げて書いています。ただし、開発中に仕様が変更されないことを期待しないでください。計画に改訂を組み込みます。

上記のmeadeは、仕様とテストを組み合わせることを推奨しています。これはテスト駆動開発として知られており、非常に良いアイデアです。自然言語ではできない方法で物事を固定し、作業量を削減します。

また、単体テストと自動化についても考慮する必要があります。これは、大幅な時間の節約と品質の向上につながります。GUIレベルのテストは自動化が難しい場合がありますが、GUIレイヤーをできるだけ薄くし、その下の機能のテストを自動化する必要があります。アプリケーション全体を何度でも徹底的にテストできるため、これは開発の後半で大幅な時間の節約になります。手動テストは費用がかかり、時間がかかるため、「Fooモジュールを変更しただけなので、テスト7、8、9を繰り返すだけで済みます」という強い誘惑があります。次に、顧客はBarモジュールの何かが壊れていると不平を言って電話をかけ、Fooが開発者が見逃したBarにあいまいな副作用を持っていることがわかりました。自動テストは実行するのが安価であるため、自動テストはこれをキャッチします。こちらをご覧くださいそのようなバグについての実話のために。

アプリケーションがそれを必要とするほど大きい場合は、TDDを使用してモジュールを指定し、それらのモジュールテストを自動テストに変換します。

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

于 2009-05-08T17:25:43.713 に答える
0

古いバグ レポートに目を通し、そこからテスト ケースを作成します。特定の古いバグをテストし、さらに一般化することもできます。同じ種類のバグが何度も発生する傾向があるため、これにより、完全なカバレッジという不可能な (または非常にコストのかかる) タスクよりも実際のバグをキャッチすることに重点を置いたテスト スイートが得られます。

GUI と Web 自動化を利用します。 たとえば、セレン。あなたが思っている以上に多くのことが自動化できます。たとえば、ユーザー登録のシナリオは簡単に自動化できます。たとえばクロス ブラウザー テストで正しく表示されることを確認するなど、人間によるチェックが必要な場合でも、QA エンジニアが見ている間にテストを記録し、後で再生することができます。開発者は手順を記録して、自動化が困難なバグを再現し、それを QA に渡すこともできます。指示を書き留めるという、時間のかかる、しばしば欠陥のあるタスクを実行する必要はありません。プロジェクトの一部として保存します。テストの意図について適切に説明してください。それらをチケットにリンクします。GUI が変更されてテストが機能しなくなり、それが発生する場合は、その意図をカバーするようにテストを書き直すことができます。

GUIレイヤーをできるだけ薄くすることについてPaul Johnsonが言ったことを拡大します。フォーム (GUI または HTML またはフォーマット) を機能 (何をするか) から分離し、機能のテストを自動化します。国のリストを生成する関数を用意し、それを徹底的にテストします。次に、それを使用して HTML や AJAX などを生成する関数を作成します。実際の作業を行う関数は十分にテストされているため、見た目が正しいことをテストするだけで済みます。ユーザーログイン。パスワードチェック。メール。これらはすべて GUI なしで動作するように記述できます。これにより、実行する必要がある、時間と費用がかかり、欠陥のある手動テストの量が大幅に削減されます。

于 2009-05-17T05:23:26.090 に答える