when opt automation testing
プロジェクトの自動化テストを検討する必要がありますか？自動化テストはいつ行うべきですか？
テストは、エンドユーザーに高品質の成果物を提供するために実行されます。 テストフェーズ の主要な側面の1つです STLC 。
品質が最適な顧客満足度をもたらすため、どの企業もソフトウェアテストに重点を置いていますが、多くの企業は、自動テストまたは手動テストのいずれかを使用して、実行するテストの種類を選択するのに苦労しています。
この記事は、読者が自動化テストとは何か、いつそれを実行するか、そして最も重要なこととして、いつ実行しないかを理解するのに役立ちます。また、の最適な利用を学びます テスト用の自動化ツール 。
どのような作業を行う場合でも、それは効果的に実行されるべきであり、費用効果も高くなければなりません。さらに、顧客が成果物に満足していると感じるように、それは理にかなっている必要があります。
学習内容：
- ソフトウェアテストと費用便益
- ソフトウェアテストの背後にあるインテリジェンス
- 自動化–それは本当に不可欠ですか？
- なぜ自動化？
- 危険因子
- 自動化を優先すべきではないのはいつですか？
- 自動化のコストとROI
- 自動化はどこで最小限から無料の削減を実現できますか？
- 結論
- 推奨読書
ソフトウェアテストと費用便益
ソフトウェアテストは通常、ソフトウェアテスターによって実行されます。テスターと実際のユーザーの違いは、テスターはビジネスまたはタスクに使用されるソフトウェアの部分的な使用法しか知らず、ソフトウェアを完全には知らないということです。一方、テスターはソフトウェアのすべての技術的および機能的要件を認識します。クライアントから提供された要件に基づいて、テスト計画とテストケースを準備する必要があります。
テスト計画は、テストプロセスの実行方法の詳細な計画に他なりません。これには、テストに関係するリソースとソースの数、何をいつ行うか、何を行わないか、テストが実行される環境などに関する完全な詳細が含まれます。
テストケースは、ソフトウェアの機能的および技術的側面を明確に理解した後で準備する必要があります。テスターは、鋭い観察能力とソフトウェアに関する完全な知識を持っている必要があります。
さらに、ここではコストが効果的な役割を果たします。顧客は、最小限のコストで最高品質のソフトウェアを受け入れることを好みます。手動テストを行う場合、すべてテスターが手動で行うため、プロセスは面倒で時間がかかります。
例えば 、「n」個のテスターが必要な場合 回帰テストを実行する 、すべてのテストケースを実行するのに50時間近くかかる場合があります。また、リソースの可用性に基づいて、テストケースが実行されます。ただし、自動テストにかかる時間が短いため、手動テストと比較した場合、リソースの最適な利用が実行され、テストケースのカバレッジが最大になります。
ソフトウェアテストの背後にあるインテリジェンス
組織にとって、テストプロセスをいつ開始し、いつ終了するかを知ることは非常に重要です。開発フェーズが完了し、必要な基準が満たされていないときにテストを開始することは役に立たないため、テストを開始するタイミングを知っているはずです。開発の進行中に、テスト設計フェーズから開始することが常にベストプラクティスです。
以下に、ソフトウェアテストの開始と終了の基準を示します。
C ++への未定義の参照
エントリー基準
設計ドキュメントが承認されたら、計画段階でテスト計画を準備する必要があります。テスト計画は重要な役割を果たします。必要なハードウェアを適切にインストールおよび構成し、ハードウェアの機能を確認する必要があります。機能要件は明確で承認されている必要があります。開発されたコードは、開発者が単体テストしてサインオフする必要があります。
テストケースとテストデータを準備して承認する必要があります。テストデータとアプリケーションが利用可能である必要があります。テスターは、アプリケーションに関する重要かつ十分な知識を持っている必要があります。リソースはツールについて十分にトレーニングされている必要があり、必要なすべての機能を備えている必要があります。
テスターが利用可能である必要があります。いずれかの基準が満たされない場合、テストのエントリー基準は差し控えられます。
(注意：画像をクリックすると拡大表示されます)
終了基準
必須のテストケースの少なくとも95％が「合格」の結果でロックされている場合にのみ、製品のテストフェーズを終了できます。ただし、ソフトウェアテストをいつ停止できるか、またはそれでも実行する必要があるかどうかを判断するのはそれほど簡単ではありません。そして、この種の状況も一般的に発生します。
主な基準は以下のとおりです。
- すべてのバグが修正されたとき。
- 締め切りに達したとき。
- 予算が使い果たされたとき。
- すべてのテストケースに合格したとき。
- 契約が承認されたとき。
- 一定の割合のテストが行われたとき。
- いつ アルファ そしてベータテストは終わります。
終了基準は、リスクやコストなどの要因に基づいて純粋に導き出すことができます。主要な機能要件のテストが達成されると、テストは通常停止され、マイナーなバグを探すことはありません。これにより、問題が発生します。後の期間。
例： ソフトウェアABCは設計段階にあります。開発とテストの構築は、通常、同時に行われます。デザインが凍結された後、ソフトウェアの開発が始まります。合意されたソフトウェアの開発の完了は、エントリー基準を示します。ここでの成果物は開発チームからのものです。リリースノートと既知の問題が含まれています。
テストを数回繰り返した後、解決待ちのメジャー/ブロッカー/ショーストッパーがなく、テストの95％が合格した場合、それは終了基準と呼ばれます。
自動化–それは本当に不可欠ですか？
必要かどうかを判断する必要がある場合 自動テスト技術 利用できるリソースの問題はここで発生します。自動化する必要がある理由は、開発されたデータフローと機能が手動の介入なしで期待どおりに機能しているかどうかを確認するためです。これは主に、ソフトウェアが複数のリリース/サイクルなどの形で変更される場所で使用されます。
各サイクルの開発の最後に、現在追加されている機能のテストが行われます。さらに、古い機能のテストが行われ、古い機能が壊れていないことを確認します。これは、自動化の余地がある主要な部分です。
コード駆動型ロジックとGUI要件を検証する場合、リスク要因が高い場合は自動テストを選択できます。
例： ソフトウェアABCの場合、頻繁にアップグレードが行われ、更新はクライアントによって求められ、開発者によって提供されます。したがって、テストの一環として、すでに稼働していて本番環境で実行されているソフトウェアに対して回帰が行われます。リリース、アップグレード、アップデートの数に関係なく、現在のバージョンが有効になります。
回帰テストのカバレッジには10日間の手動作業が必要であり、それらを自動化するために最大限の注意を払う必要があるとします。少なくとも60％の労力と、10 * 8 = 80時間の手作業を節約できます。
自動化は80/24 = 3。33日のみ完了できます。これにより、約6.67節約できます。
なぜ自動化？
自動化は、次の場合にのみ選択できます。
- このアプリケーションには非常に広大な領域があり、回帰に多大な投資を行っています。
- 手動エラーが原因でコストの最適化が行われました。
- ソフトウェアには複数のバージョンとリリースがあります。
- 長期的には費用効果が高いです。
- テスト実行の範囲が広いほど、リスク係数は高くなります。
- コストの数値と数学的計算は、ソフトウェア機能に含まれています。
- ソフトウェアの品質とともに、実行テンポ、効率が大幅に向上します。
- リスクの高いソフトウェアテストの場合でも、ターンアラウンドタイムは短くなります。
危険因子
リスク要因は、時間要因に多くの依存関係があるビジネスで主に一般的になります。トランザクションシステムに基づいて機能し、複数のアプリケーション間で機能するソフトウェアでは、ソフトウェアがソフトウェア設計に従って理想的に機能する必要があります。この場合、正しい機能動作を記録することには多くのリスクが伴います。
ここで、自動化は、ソフトウェアメカニズムに従ってより良いペースで機能トランザクションを実行するのに非常に役立ちます。
例えば 、外国為替市場指標の場合、時間的要因は非常に重要で重要です。在庫と商品の変化は、時間に対して、時には数秒未満で発生します。ここで自動化は、リスクの高いそのようなソフトウェアのテストに役立ちます。
例： ソフトウェアABCには複数のアップデートとアップグレードがあります。手作業を節約し、テストフェーズのターンアラウンドタイムを短縮するために、基本バージョンまたは古い機能を自動化できます。これは、基本機能が変更されない場合にのみ有効になります。
自動化の利点は、手動の介入なしで実行できることです。これでも、新しい機能のテストと並行して実行できます。したがって、自動化は多くの労力と時間を節約します。
自動化を優先すべきではないのはいつですか？
いくつかの組織の間で疑問があります–なぜ100％自動化が不可能なのですか？
専門家からの答えは しない 熟練したユーザーは自動テストを実行する必要があり、十分なトレーニングを受けている必要があるためです。基準の初期段階では自動化を実行できず、アプリケーションの要件が明確になりません。
通常、自動化は、ソフトウェアリリースの2回目の反復から優先されます。ユーザーインターフェイスが変更される可能性があり、コストが高くなり、スクリプトのメンテナンスにもコストがかかります。自動化ツールに必要なコストがプロジェクトの予算を超える場合は、ノーと言えます。
例： ソフトウェアXYZは、クライアントの要件が凍結されず、クライアントの要求に応じて変化し続けるタイプのeコマースサイトです。
ここで、この場合、自動化は回帰を助けることができません。これは、無効な古い機能をテストする必要がないため、手動で実行する必要があるためです。たとえば、クライアントは、ドロップダウンボックスとして変更するために、ベースソフトウェアのすべてのリストボックスを持っている必要があります。
自動化のコストとROI
自動化は初めて費用がかかるため、最初に自動化を行う場合、ROIは非常に低くなります。ソフトウェアのテストにおける手作業が2番目のリリースの反復から低下するにつれて、ROIは増加し続けます。自動化の前に、テストケースの予想される結果を認識しておく必要があります。
自動化とツールを選択するときは、テストケースの設計をより重要に考慮して、コストが増加しないようにします。
自動化はどこで最小限から無料の削減を実現できますか？
テストに必要なツールを購入する必要があるため、自動化のコストもかかります。リソースは、特定のツールを使用してトレーニングする必要があります。選択したツールは、ソフトウェアのすべての領域をテストするために実行可能でなければなりません。
したがって、ツールの選択は、自動化テストの専門家が慎重に行う必要があります。
例： 保険を扱う製品XYZを考えてみましょう。コスト要因を減らすために、同社は手動テストのみを使用しましたが、保険に関しては、リスク要因が高く、保険料の計算のいずれかが失敗した場合、会社の費用がかかる可能性があります。またはエンドユーザーに。会社が負わなければならないのに対して、エンドユーザーは損失を負わないでしょう。
計算された保険料額が元の保険料と一致しない場合（つまり、フロントエンドとバックエンドの保険料の計算に違いがある場合）、顧客と製品販売者の間で大きな問題が発生します。自動車、家庭などの多くのモジュールも含まれている可能性があります。
何かがうまくいかないとき、それは完全な損失です。計算の違いはテスターにとって意味があり、バグを引き起こす可能性があります。このプロジェクトでは、 手動テスト TIN番号、ソーシャルID、およびユーザーポートフォリオに関連するその他の情報の確認など、基本的なUIに対して実行できるため、リスク要因が低い場所で手動でテストできます。 m 会社が利益を得るほど、ソフトウェアのテストに自動化を好むようになります。
結論
自動化と手動テストの両方に長所と短所もあります。概念と要件が明確な場合にのみ、実行するテストの種類を選択できます。
手動テストまたは自動テストだけでプロジェクトをテストすることはできません。それは、ソフトウェアが開発された設計、プラットフォーム、およびテクノロジーによって異なります。したがって、決定を下すときは、テストの方法を慎重に選択し、専門家のアドバイスを使用する必要があります。
上記の記事では、いくつかの要素を見逃している可能性があります。自動化または自動化のためのツールを選択する際に重要と思われる要素を共有してください。
その間、この記事についてのあなたのコメント/提案を自由に共有してください。