4

私は新しいプロジェクトの主任開発者であり、システム エンジニアと協力して、機能要件をテストするためのテンプレートを作成する機会があります。優れたテスト手順テンプレートの作成方法や優れたテンプレートの例について誰かが意見を持っているかどうか疑問に思っていました.

ありがとう！

4

1 に答える 1

4

これは簡単に答えられるものではありません。それはいくつかのことに依存します:

1) 機能テストケースとは何かの定義/解釈

2) 受け入れテストにおけるサポートスタッフの役割

3) テストの寿命

これは、私自身の経験に基づいた純粋な意見です。

(自動販売機に2セントを投入)

1)機能テストケースとは? - あなたとシステム エンジニアは、これについて調整する必要があります。システム エンジニアは、あなたよりも高い (粒度の低い) レベルで物事に取り組むことが (私がしたように) わかるかもしれません。たとえば、特定の要件が Web サービスの作成に関するものであると仮定すると、エンジニアは次のことを知る必要があります。

  • インターフェイスは正しく動作していますか?
  • テスト ケースの入力パラメータは、成功/失敗を誘導するためのものですか?
  • 失敗した場合、適切なエラー/エラー コードが返されますか? 時間によっては、エンジニアは、製品/サービス全体に影響を与える主要/重要な障害状態 (または否定的な応答) のみに固執する場合があることに注意してください (たとえば、「ホストが見つかりません/タイムアウト エラー」がインターフェイスにあるはずですが、必ずしもテストする必要はありませんが、「クライアントの資金が不足している」などのユースケース関連の失敗は、エンジニアにとって重要です。
  • 取引状況は正しく記録されていますか？

繰り返しますが、あなたとシステム エンジニアは、機能テスト ケースとそうでないものを明確にする必要があります。通常、機能テストは、提供された機能仕様から直接派生します。特定の製品では、タイムアウトでの再試行は機能しないものに分類されますが、Web サービスがタイムアウトで 17 回再試行してからあきらめる必要があるエンジニアがいる場合があります。エンジニアがこれを指定する場合は、それを含めます。

2) これらのテストはどのように実行され、誰が承認しますか? これに応じて、機能テストを合理化または肉付けする必要がある場合があります。

あなたとシステム エンジニアが居心地の良い部屋に半日閉じ込められて各テスト ケースを処理する場合は、作業を簡素化してください。2 人は要件に精通している必要があり、エンジニアはドキュメントを確認して、すでにコメントを提供しています。一方、エンジニアの代わりにサポート エンジニアにテストを実行してもらうこともできます (これが私たちのやり方です... システム エンジニアはテスト ケースをレビューし、最初に少し留まり、飽きたらその場を離れます)。 ）。私はどこにいたのだろう？そうですね、この場合、ドキュメントは、テストされているシナリオを説明するために、もう少し手を加える必要があるかもしれません。これで、長々とした雑談の最後のポイントにたどり着きます...

3)文書の寿命

私の側ではよくあることですが、一連の機能テストが終了すると、それらはすぐに忘れられます。ただし、これらのテストはシステムと製品を検証するものであり、サポート エンジニアは次のことが必要なときにいつでもテストを実行できる立場にある必要があります。

  • 問題を解決する (「この種のケースは稼働前にテストされましたか?」)
  • 問題を再度解決します (「こいつらはこの特定のシナリオをテストしたのか?」)
  • 大きな変更後のシステム/製品の完全性を検証する
  • 製品やサービスの現状の機能について学ぶ (多くの場合、人々は製品がどのように動作することになっているのかを忘れており、サポート スタッフは要件仕様、特に時代遅れでシステムの現在の動作が異なる要件仕様を読むことを嫌います。当初のスペックより）

（深呼吸）

したがって、次のことを確実にカバーする必要があります。

  • テストのセットアップ パート 1: テストを実行するための要件は何ですか? どのようなツールが必要ですか? ネットワーク接続？
  • テストのセットアップ パート 2: どのテスト データを使用しますか? 必要な場合はどこにありますか、またはどのように生成しますか?
  • 期待される動作が何であるかを少なくとも伝えるための機能要件/テストの概要。
  • テストされる主要なシステム コンポーネントの概要
  • テストの制限についての考え - 特定の機能テストはシミュレートすることしかできないか、ライブ エンド システムに対してテストすることができないなど - 制限を説明し、それをどのように偽装するかを読者に示す必要があります。

また、システム エンジニアは、コンポーネント テスト、統合テストなどの詳細なテストも既に完了していることを期待します。彼がどれだけ素晴らしいかにもよりますが、エンジニアはこれらのコンポーネント テストのドキュメントを要求し、自分でいくつかテストを実行する場合があります。

テンプレートを使用すると一貫したプレゼンテーションが提供され、すべての重要なコンテンツがカバーされていることを確認するのに役立ちますが、目的を固定し、その目的を達成することに焦点を当てる必要があると思います.

私はいくつかのセントを作ったことを願っています:)

于 2010-09-15T20:55:31.787 に答える