7テストケースERPソフトウェアテストプロセスを改善するためのヒントを書く
テストケースは、ERPソフトウェアテストプロセスの品質を確保するた これらはテストサイクルの最初のステップであり、テストケースの品質が十分でない場合、プロジェクト全体が”負担”になります。 “偉大な”テストケースを書くことは、単にそれを行うことによってフォームを取得するスキルです。 しかし、それはあなたを助けることができるいくつかの洞察力を持っていることは非常に便利です。 この記事では、私はあなたに手を差し伸べると、それが簡単に、より楽しく、より良いように提案を与えたいと思います。 与えられるヒントは、特にERPシステムの受け入れテストでのテストケースに関連しています。
テストケースとは何ですか？
ソフトウェアテストの世界では、テストケースの定義がたくさんあります。 このため、私たちの定義に名前を付けることが重要です。 私たちの哲学では、テストケースは（IEEE610に基づいて）：”特定の目的のために開発された一連のテスト入力、実行条件、および期待される結果。”良いテストケースを書く方法を知ることは、テストしたい人にとって非常に便利です。 それは機能テスト、ユーザー受け入れテスト、webアプリケーションまたはERPシステムのモジュールをテストするかどうか。 上記のすべての状況において、テストケースは、結果が事前に設定された目標についての評決を与えるものを拡張するかを決定します。
なぜテストケースを書くのが難しいのですか？
定義で説明されているように、テストケースは、ソフトウェアが事前定義された要件を満たしているかどうかを判断するために、一連のテスト命令 テストケースの実行は、その特定の目標または目標を実現するための情報を収集し、発見するのに役立ちます。 私たちが直接遭遇する最初の問題は、可能なターゲットの多様性です。 また、テストと目標にはさまざまな種類があるため、対応するテストケースにはさまざまな種類があります。
第二の問題は、実際のテスト命令またはステップの内容に関連しています。 これらの命令のレベルは、この情報を解釈し、意見を与える必要がテスターのタイプに依存しています。 専門のテスターはERPシステム
ヒント1の受け入れテストに関与しているエンドユーザーとは対照的に、異なる指示が必要になります: あなたの目標と何を報告したいかを決定する
あなたが報告したいものについて考えて、あなたの派生目標を決定することができます。 それをベースとして使用すると、テストケースの概要が表示されます。 テストを実行しようとしているときに、何を学んだり達成しようとしているのかを常に自問しなければならないさまざまな目標があります。 ここにいくつかの例があります:
- 欠陥の発見：これはテストの古典的な目的です。 テストは欠陥を露出するために行われます。
- バグの数を最大化する: “バグの数を最大化する”と”欠陥を見つける”の違いは、カバレッジよりもバグの総数が重要であるということです。
- 早期製品リリースのブロック:このテストの目的は、誰も製品を生産に持ち込まないように、できるだけ多くの重大な欠陥（showstoppers）を早期に見つけることです。
- 経営者の意思決定を支援する：経営者はリスクに基づいて意思決定を行う。 テストカバレッジとしてのリスク表示、見つかった問題の影響など それらに決定を基づかせるためによりよい背景を与えなさい。
- 仕様に従って適合性を評価する：疑惑の仕様は、その動作のためにチェックされます。 仕様に関連付けられていないすべての事項は無視されます。
- 品質を評価する：品質は多次元であるため、これは困難な目的です。 品質の性質は、製品の性質に依存しています。 品質を評価するには、明確な基準が策定されるべきであり、実際に測定可能にすることができる方法で定義されています。
テストケースから派生したテスト結果は、目標に関する直接的な関連情報を提供します。
ヒント2:十分な設計時間を予約する
テストケースを設計するのに十分な時間を予約して、目標に一致するようにします。 貧弱なテストケースは、テストプロセス全体を通してあなたを悩ませます。 テスト結果の比較、いくつかのテストラウンドの報告など 基本的にはテストケースの品質によって決まります。
すでに設計時間が不足しているが、それでもテストを開始したい場合は、少なくとも主なリスクを定義していることを確認してください。 10人のテスターが5つのテストケースを1つのテストステップで確認する必要がある場合、これは50のテスト結果になります。 これらの50の結果がそれから何もしない質についてのより多くの情報を与えても。 これはおそらく網羅的ではないでしょうが、それは最初のステップです。 その上から、特定の部品の詳細レベルを決定することができる。
私たちは、あなたがテストをどのように設計すべきかについて事前によく考え、テストの結果が目的に対する本当の答えを与えることを好む。 しかし、実際には、これは時には手に負えないことがあります。
ヒント3:テストケースに名前を付ける
テストケースに名前を付けることは重要です。 平均的なERPテストでは、簡単に500以上のテストケースを持っています。 論理名構造が検索可能性を高めることを理解するでしょう。 文献では、多くの場合、プロセス、モジュール、オブジェクトなどをテストすることで、可能な限り完全な名前として言及されています。 すべて名前に含まれています。 このような完全なタイトルで500のテストケースを提供すると、混沌とした管理が得られると想像できます。 簡単なExcelシートを使うと、容易に概観を緩めます。 テスト管理ツールは、名前を”汚染”することなく、テストケースを再利用可能なオブジェクトに関連付けることができる構造を提供します。 また、これらの関係を別の方法で整理するテスト登録ツールもあります。
たとえば、TestMonitor内で別のソリューションを発明しました。 このツールでは、テストケースにリンクできるラベルまたはタグを定義できます。 TestMonitor内では、テストケースは1つまたは複数のビジネスプロセス、リスク、要件、またはアプリケーションラベルにリンクされています。 これにより、テストケースをグループ化し、さまざまな視点から取得することができます。
TestMonitor内のテストケースの名前については、テストケースの目的を明確に説明するだけで十分です。 それを簡単にするために、暗黙的な期待を持つ活動を記述します。
テストケース名の例：
“リース独立住宅の終了”
“顧客の作成””仮予約領収書”
など。
複数のラベルにリンクされているテストケース”仮予約領収書”の例:
- 業務プロセス’入庫’
- 要件’契約要件’
- リスク’オペレーショナルリスク’
- アプリケーション’ERP’
テストケースごとに期待される結果を記述することが重要です。 テスターは、”答え”がどの方向にある必要があるかを知り、明示的なテストフレームワークを直接取得します。
ヒント4:テストステップの説明
定義で説明されているように、テストケースは、特定の目標を達成するための情報を発見するのに役立つテスト手順
テストケースには、テストケースが合格したか失敗したかを判断するために、明確な開始と終了が必要です。 さらに、テストケースは、所望の結果を達成するために可能な複数のパスがある、１つまたは複数のテスト命令またはステップから構成される。 成功の道をテストするだけでは不十分なことがよくあります。 特定の状況では、成功していないパスに従うだけで違いが生じる可能性があります。
ユーザー受け入れテストのエンドユーザーが何をすべきかを正確に把握できるように、テストステップをできるだけ明確に定義することが重要です。 もちろん、機能レベルのテスター、新しいシステムの知識、可能な調整されたビジネスプロセスの知識など、思い付くべき前提条件があります。 しかし、本質的に誰もがすべてのテストステップを理解する必要があります。
単純な成功パスのためのテストケース”Lease termination–independent home”をさらに記述するとします:
- ユニットを選択し、リースの終了を開始します。 リースの終了を受け入れることができない/受け入れられない前提条件があるかどうかを制御し、これの記録を作成します。
- 最終検査の予定をスケジュールします。
- リースの終了画面にデータを入力します。 リース終了カードのテナントデータを再確認します。
- リースの終了を登録し、コンフォメーションレターを送信します。 確認書がデジタルアーカイブに入っているかどうかを確認します。
- 現在の契約が終了したこと、終了した契約がリースの終了にリンクされていること、新しく作成された空室契約があることをユニットから契約書
- レンタルポリシーと要素テンプレートに基づいて、新しい（空室）契約を確認してください。
あなたは何に気づきますか？
- 各テストステップは動詞
- で始まり、トピック
- が続き、詳細とおそらく制御の質問で終わります。 コントロールの質問を別々のテストステップに置くことを選択することもできますが、実際には、コントロールの質問はアクションの改良であり、論理的に
上記の例では、特定の分野の専門家がテストステップを評価することを前提としています。 そして、彼または彼女は専門家であるため、入力条件が与えられていないか、専門家はまだ彼の袖の上に彼自身のケーススタディを持っており、彼の期待
現在専門家がいない場合は、入力条件と明示的な期待でテストステップを拡張することができます。
例えば、テストケース”リース独立住宅の終了”でステップ1を詳細にテストします。
- ユニット”フリートストリート677″を選択し、リースの終了を開始します。 条件は延滞が支払われた前にこの単位が終わることができないことを保障する。
- など
ヒント5: 1つのテストケースに10個以下のテスト命令
私たちは定期的に>50個のテストステップが1つのテストケースに割り当てられているテストプロジェク これはいくつかの理由で多すぎます:
- テストケースが判定を受ける前に、すべてのテストステップを個別に実行する（または明示的に合格する）必要があります。
- テストケースの最終的な評価は、”最悪”スコアによって決定されます。 したがって、49のテストステップが「良い」と評価され、1つが「間違った」テストケースになると評価される可能性があります。 テストステップの測定はここに類似しています。 それによって、私は事実上すべてのテストステップが評価の効果と等しくなければならないことを意味します。 あなたが従わなければならない10のテストステップを持っている場合は、彼らが他の8つのテストステップに不釣り合いである2つの小さなテスト 同じことが、厳しいテストステップでは逆の方法で適用されます。
- テストケース内のテストステップが多すぎると、テスターはすぐに失われます。 私たちはそれについて科学的研究をしていませんが、実際にはテストケースに10以上のテストステップを含めるべきではないことを示しています。 多くの例外（変換制御など）を考えることができますが、実際にはERPシステムのユーザー受け入れテストではこれが最適です。
- 見つかったエラーを開発者が再現することは困難です。 多くのテストステップでは、開発者は状況を再制定しようとすると多くの時間を失うことになります。
- 大規模なテストケースの再実行または再テストには時間がかかりすぎます。 テスターによって障害が検出されると、対応するテストケースを再テストする必要があります。 再テストは非常にステップが再評価されることを必要とします、あなたは明らかに回帰エラーを防ぎたいです。 あまりにも多くのテストステップを取ることによって、あなたは最も可能性の高いテストが多すぎています。 このようにして、テストプロセスに時間がかかり、最終的にテスターに過負荷がかかる可能性があります。
それに加えて、テストケースをさまざまな形式でテスターに提示できるテスト登録ツールもあります。 たとえば、TestMonitorには2つの異なるビューがあります。 TestMonitorには、ページごとにすべてのテストステップを個別に表示するディスプレイと、すべてのテストステップを含むテストケースがページごとに表示される最初の表示の利点は各テスターが各テストステップのためのより多くの情報を得ることができることです。 テスターがより経験豊富な場合の欠点は、次のテストステップに進むたびに”次へ”をクリックする必要があります。 各テストケースの他のビューでは、長所と短所はその逆です。
ヒント6:非デザイナー/サプライヤーによるレビュー
実際には、ソフトウェアサプライヤーのプログラマーによって準備されたテストスクリプトを定期的に 最終的なテスターによってこれらのテストスクリプトを確認するとき、通常は回答よりも多くの質問があります。 逆に、これは自分の従業員によって準備されたテストスクリプトでも同じように機能します。 それはソフトウェア製造者によってこれらを見直す実質の付加価値を与える。 彼らは、完成したテストスクリプトをさまざまな目で見て、常に意味のある追加や変更を思い付きます。
ソフトウェアサプライヤの専門家とクライアント組織とのブレーンストーミングの少しで、あなたはすぐにテストする必要があるものの本質に焦点を その後、テストケース、非成功のシナリオを検討する時間を取ると、あなたのテストモデルが急速に、より広範かつ詳細になっていることがわかります。 それに加えて、あなたはあなたが可能と考えた品質についてのより多くの情報を得ます。
ヒント7:TestMonitor
それに加えて、プロのテストプラットフォームを利用し、品質を本当に洞察に満ちたものにします。 今日TestMonitorの無料トライアルを要求し、参照してくださいし、自分のための違いを体験してください。
あなたがテストの世界で新人なら、あなたは簡単に周りに投げられるすべてのテスト用語に圧倒されるようになります。 この記事では、私たちはちょうどそれをすべて少し理解できるように、あなたの毎日のテストの生活の中で遭遇する可能性のある専門用語のいくつ
TestMonitorでテストを開始
連絡を取り合う？ TwitterとLinkedInでTestMonitorに従ってください。
Leave a Reply