test scenario vs test case
テストシナリオとテストケースの違い。
6年前 、中規模のMNCで作業しているときに、テストケースと呼ばれる完全な証明文書の準備に時間を無駄にするのではなく、テストシナリオを文書化することを提案したとき、すべての頭がイライラして私に向き直りました。
顔の表情は、私がそれを提案することによって大きな間違いを犯したことをはっきりと伝えていました。誰もその考えを否定しませんでしたが、誰も受け入れさえしませんでした。誰もが伝統に従う、つまりテストケースドキュメントを書く方が安全だと感じていました。私は議論することができませんでした。
4年後 、会社はテストプロジェクトを受け取りました。そこでは、唯一の制約は時間であり、唯一の期待は完全な証拠でした。 テスト。
私たちは再び会議に参加し、重要な期限に間に合わせるためのアイデアについて話し合っていました。このアプリケーションは主に、さまざまなメニュー項目を介してさまざまなレポートを検索および生成することを目的としていました。テストケースの文書化はほとんどの場合ひったくりになるはずでしたが、その文書がクライアントにどれだけ使用されるかはわかりませんでした。
私はテストシナリオを文書化することを提案しました、そしてどういうわけか少しためらって、誰もが同意しました。ドキュメントの貴重な時間を節約し、テストに利用できることは言うまでもありません。
学習内容:
テストケースはテストシナリオにすばやく置き換えられていますか?
時間とともに、すべてが変化するにつれて、ソフトウェア業界とプロセスも大きく変化しました。
外付けハードドライブへの無料のコンピュータバックアップソフトウェア
伝統的 滝 そして Vモデル アジャイルで反復的なモデルに置き換えられています。 書類が必要です しかし、期限を守り、プロセスを簡単かつ透明にするために、文書化の方法を変更することができます。
テストケースの文書化はいつ重要ですか?
- クライアントは、プロジェクトの一部として同じことを求めています。
- 時間の制約はありません(それは不可能だと思います)。
- テスターは、製品が新鮮であるか不明です。
- 会社の方針(変更できると強く信じています)。
私はあなたと1つの経験を共有させてください:
私と私のチームは、柔軟なタイムラインでFortune500企業のプロジェクトのテストに携わりました。利用可能な最良のテンプレートを使用してテストケースを文書化し、クライアントに承認されました。
ビルドがQAチームにリリースされ始めると、ほとんどの場合、私たちの義務は、1日あたり100のテストケースを機械的に追跡し、合格/不合格の結果でドキュメントを更新し、1日の終わりにクライアントに送信することでした。ほとんど チームメンバーは不平を言い始めました 単調な仕事 しかし、会社は収益を上げていました。
その後、テストする新しいビルドがない状態で、その間に1日の休憩がありました。私たちは一日の初めに一緒に座って、その日のために何をするつもりかについて話し合っていました。テストケースドキュメントを改善するためにさらにアイデアを生成することを提案したとき、チームメンバー全員が努力を拒否しました。
彼らによると、私たちはすべてのシナリオをカバーしたので、これ以上考えることは何もありませんでした。そして彼らを説得して 箱から出して考え、より多くのアイデアを生み出す 本当に大変でした。
ほとんどの場合、私たちがテストケースを文書化し、それがクライアントによって承認された後も、人間の心は私たちが自分の仕事をしたと考え、 私たちの心は、製品をテストする他の方法を考える努力を考えるのを自動的にやめます。
そして私を信じてください、テストケースドキュメントが準備されるとき、私たちはそれを機械的に追跡したいだけです。あなたのキャリアの中で、あなたまたはチームメートが承認されたテストケースドキュメントに追加のテストケースを提供したことを何回経験しましたか?
もう1つの経験:
毎週のチームチャレンジ活動中に、アプリケーションを発表し、チームメンバーにテストシナリオを投入するように依頼しました。
遅い応答者または非応答者を含むすべてのチームメンバーがアイデアを出しました。どうして?機能のすべてのシーケンスと各テストケースの前提条件について期待される結果を記入する必要がある正式なドキュメントはありませんでした。 1日に40のテストシナリオを収集しましたが、それは素晴らしい経験でした。
私の経験を支持するために、 例を挙げたいと思います。
サンプルアプリケーションを取り上げます。たとえば、ユーザー名、パスワード、ログイン、キャンセルボタンが表示されたログインページです。同じテストケースを作成するように求められた場合、さまざまなオプションと詳細を組み合わせて、50を超えるテストケースを作成することになります。
ただし、テストシナリオを作成する場合は、次のように10行で済みます。
高レベルのシナリオ: ログイン機能
低レベルのシナリオ :
1.アプリケーションが起動していることを確認するには
2.ログインページのテキスト内容を確認するには
3. [ユーザー名]フィールドを確認するには
4. [パスワード]フィールドを確認するには
5.ログインボタンを確認し、ボタンの機能をキャンセルするには
関連項目=> Webおよびデスクトップアプリケーションをテストするための180以上のサンプルテストシナリオ。
配列javaに値を追加する方法
私たち全員が時間が足りないので、テストシナリオはその昔のIODEXではなく鎮痛剤スプレーとして機能します。それでも、効果は同じです。
表形式のテストシナリオとテストケースの違い
最後に、テストシナリオとテストケースの違いを要約します。
テストケース | テストシナリオ | |
---|---|---|
それは何ですか=> | 何をテストするか、実行する手順、および同じ結果として期待される詳細情報を提供する概念 | 何をテストするかについての1行の情報を提供する概念。 |
約=> | 詳細を文書化することが重要です。 | 詳細について考え、話し合うことが重要です。 |
重要性=> | テストがオフショアで開発がオンサイトで行われる場合は重要です。詳細を含むテストケースを作成すると、開発チームとQAチームの両方が同期するのに役立ちます。 | 時間が少なく、ほとんどのチームメンバーがワンライナーシナリオの詳細に同意/理解できる場合に重要です。 |
利点=> | すべてのテストケースの1回限りの文書化は、将来の数千回の回帰テストを追跡するのに役立ちます。 ほとんどの場合、バグ報告時に役立ちます。テスターは、テストケースIDの参照を提供するだけでよく、1分ごとの詳細に言及する必要はありません。 | 新世代のソフトウェアテストコミュニティが好む、時間の節約とアイデアの生成活動。 変更と追加は簡単で、個人に固有のものではありません。 人々のグループが特定のモジュールしか知らない巨大なプロジェクトの場合、このアクティビティは、他のモジュールを調べてブレインストーミングを行い、話し合う機会を全員に提供します。 |
=>に有益 | 完全なテストケースドキュメントは、新しいテスターの生命線です。 | アプリケーションをテストシナリオに分割することで、良好なテストカバレッジを実現でき、製品の再現性と複雑さを軽減します。 |
短所=> | 何をテストするか、どのようにテストするかについてすべてを詳しく説明するためにより多くのリソースが必要になるため、時間とお金がかかります | 特定の人が作成した場合、レビュー担当者または他のユーザーは、その背後にある正確なアイデアを同期しない可能性があります。より多くの議論とチームの努力が必要です。 |
結論
テストケースはソフトウェア開発ライフサイクルの最も重要な部分であり、テストケースがないと、何かを追跡、理解、追跡、推論するのは困難です。しかし、アジャイルの時代では、テストケースはテストシナリオに急速に置き換えられています。
一般的な テストチェックリスト テストシナリオと組み合わせた各タイプのテスト(データベーステスト、GUIテスト、機能テストなど)は、ソフトウェアテスター向けの最新の砲兵です。ディスカッション、トレーニング、質問、および練習により、の最終的なグラフが確実に変わる可能性があります あなたの生産性 バグレポートマトリックスも同様です。
いつものように、私たちはあなたの考えや質問を歓迎します。どうぞお楽しみに。