how does test planning differ
自動化プロジェクトは、手動テストプロジェクトとは性質が異なることに同意します。自律自動化プロジェクトは実際には存在しません（または理想的には存在すべきではありません）が、計画時には手動プロジェクトと自動化プロジェクトの両方の処理が異なります。
ミックスプランのプロジェクトは必然的に実行されます。これは、現在のプロジェクトに影響を与え、個人の能力に影を落とすだけでなく、クライアント/管理者に対するチームの信頼を失い、さらなるビジネスに影響を与える可能性があります。私たちテスターは後悔するよりも安全だと言いたいです。
=> 完全なテスト計画チュートリアルシリーズについては、ここをクリックしてください
計画についての良いディルバートコミック：
先に進む前に、この記事が何についてではないかを確認したいと思います。
＃1） これは、自動化フレームワークの詳細な説明ではありません。プロジェクトが異なれば、AUTの性質、アーキテクチャ、複雑さ、チームの専門知識などに応じて、異なるフレームワークが使用されます。
フレームワークに関する情報は、以下のリンクにあります。
テスト自動化フレームワークパート1 そして パート2 。
＃二） これは、テンプレート、フォーマット、または作成に関するものでもありません。 テスト計画文書 。自動化プロジェクトの文書化前の考慮事項について、実現可能性分析のラインで詳しく説明します。
＃3） これも特にツールではありません。 SDLCのすべての活動には、時間、労力、インフラストラクチャ、つまりお金がかかります。
手動テストプロジェクトの場合、コストを消費する要因は次のとおりです。
- 人
- ツール–テスト/欠陥管理
- インフラストラクチャ–環境
- 時間
- トレーニング
自動化プロジェクトの場合、上記の項目に加えて、次の費用が必要です。
- 自動化ツール
- テスト管理ツール統合用のアドイン
- AUTをサポートするためのアドイン（SAP、Oracleなど）
- フレームワークの設定
- ツール固有のトレーニング
これらの状況を考えると、自動化プロジェクトの成功は、コードの記述の程度、再利用可能なコンポーネントの数、またはコードの数行で目的の結果を達成したかどうかに依存しますか？
しない。
成功を決定する唯一の質問があります– 「手動ルートと比較して、より良いROI（投資収益率）を生み出すことができますか？」 –すぐにではない場合、最終的に。
この質問に対する答えが「いいえ」の場合は、自動化プロジェクトを誤って計画しています。
通常、テスト計画には次のセクションがあります。考慮すべき自動化固有の側面に焦点を当てて、それぞれについて説明します。
自動化テストテスト計画セクション
セクション1：範囲
- 複数のサイクルにわたって何度も回帰するテストケース/シナリオを選択します。
- 最も単純なテストケースでは、自動化するために多くの複雑なソリューションが必要になる場合があります。これらが1回限りの使用である場合、それは明らかに意味がありません。再利用性に焦点を当てる必要があります。
- 自動化テストは、探索的テストを実行しない/実行できません。
第2節： テスト戦略
- このセクションは、オートメーションの世界ではフレームワークと呼ばれています。一部のフレームワークは、作成が非常に難しく、効果的でもありますが、時間、労力、能力の面で要求されています。常に妥協点を探し、リソースの過剰使用を危険にさらすことなく、できる限り最善を尽くします。
- 均一性を維持し、生産性を向上させるために、使用するコーディングのベストプラクティス、命名規則、保存するテストアセットの場所、テスト結果の形式などを決定します。
セクション＃3：リソース/役割と責任
- この方向への最初のステップは、チームの能力を理解し、自動化の範囲を先取りして予測することです。これは、自動化と手動の両方のテストのニーズに適したチームを選択するのに役立ちます。また、正しい態度を持っている人を選んでください–それらは手動テストが彼らの身長の下にあるとは思わない。
- AUT、テスト管理、欠陥管理、およびその他のSDLCアクティビティに精通したチームを選択してください
- セクション＃1：範囲
セクション4：ツール
次のルールに基づいて自動化ツールを選択します。
- 会社はすでに特定のツールのライセンスを持っていますか？それを使用できるかどうか試してみてください
- オープンソース（しかし信頼できる）ツールを探す
- チームメンバーはすでにツールを知っていますか、それとも新しい人を連れてくる必要がありますか？または、既存のものをトレーニングしますか？
セクション＃5：スケジュール
- コードのウォークスルーと自動化スクリプトの検査のための時間を含める
- スクリプトをタイムリーに保守します。今後6か月ほど使用しないコードを作成する場合は、失敗の可能性を減らすために、定期的にコードを維持するようにしてください。
セクション＃6：環境
- AUTを実行するターゲット環境と、使用する自動化ツールには互換性がある必要があります。これは、ツールの事前ライセンスと見なされる要素の1つです。
- また、残りの部分が 管理ツール 所定の場所にあり、持ち込もうとしている自動化ツールは相互接続可能であり、追加のメリットがあります。
セクション＃7：成果物
- テストスクリプトは成果物です。ただし、すべての人が自動化/プログラミング言語に精通しているわけではありません。したがって、現在のユーザーと将来のチームメンバーが、あなたがいないときでもこのスクリプトを理解できるようにするための「ハウツー」ドキュメントを作成することを計画してください。
- スクリプトにもコメントを含めます。
セクション＃8： リスク
自動化ソリューションを提案する場合は、費用効果の高いツールとソリューションを選択して、自動化の取り組みがプロジェクトに負担をかけないようにしてください。
自動化プロジェクトのROIをすぐにプラスにすることはできず、長期間にわたって明確に確認できるという期待を設定することが重要です。
したがって、システムの自動化を提案する場合は、次のシステムを選択してください。
- 安定していてメンテナンスが多すぎない
- 巨大な回帰スイートの余地があります
- 手作業による介入が多すぎない、または人間の直感に依存しない
セクション＃9：テストデータ
- データのセキュリティ面を考慮に入れる
- テストデータをスクリプトにハードコーディングしないでください。これにより、スクリプトのメンテナンスが多すぎて、変更中にエラーが発生する可能性があります。
- 非常に具体的にしてください。手動テストステップ–「名を入力」の場合、任意の5文字の名前を入力すると言うことができます。テスト中、テスターは「Swati」や「Seela」などと入力できます。しかし、ツールの場合、そのような仮定を立てることはできません。したがって、正確な値を指定してください。
セクション＃10：レポート/結果
- スクリプトの実行結果も技術的であり、他のチームが簡単に理解できない可能性があります。追加の手段として、詳細な結果をメモ帳またはExcelシートに書き込むことを計画します。
- 詳細なフレームワークドキュメント、レビュー結果、欠陥レポート、実行ステータスレポートも期待されます。
自動化の愛好家である私たちは、クライアント/管理者が自動化の提案を簡単に購入できないと考えるかもしれません。
Windows用の最高のリモートデスクトップソフトウェア
ただし、自動化を通じてROIを最大化することが最終的な目標である場合、管理者/クライアントの目標とも完全に調和しています。 これにより、プロジェクトを自動化するだけでなく、多くの同意、協力、興奮をもって自動化できるようになります。
上記のすべての要因の計画と徹底的な分析は、この旅を通して私たちの味方になることができます。繰り返しますが、ROIはすべてを意味します。
この投稿は、STH作成者のチームメンバーであるSwatiSeelaによって作成されました。
質問や話し合いがありますか？以下のコメントに気軽に投稿してください。
=> 完全なテスト計画チュートリアルシリーズについては、こちらをご覧ください