はじめに
テスト自動化エンジニアのシラバスを再度読み直し、各章をDailyで読めるようにしてみた
7 Verifying the Test Automation Solution を今回は翻訳・解説する
テスト自動化環境の検証計画（テストツールのセットアップを含む）
当たり前のことですが、テスト自動化を実行させる前に、テスト自動化環境およびTASの他のすべてのコンポーネントが期待通りに動くことを検証する必要がある。
各ステップは次のとおりです
テストツールのインストール、セットアップ、構成、カスタマイズ
TASは多くのコンポーネントで構成され、信頼性と再現性のあるパフォーマンスを保証するために必要です。
自動化されたインストールスクリプトや手動配置があり、定期的なサービスパックやアドインで互換性を確保します。
自動インストールやリポジトリからのコピーにより、異なるSUTで同じバージョンと構成のTASを保証できます。アップグレードもリポジトリを通じて行われ、標準的な開発ツールと同様のプロセスが適用されます。
テスト環境のセットアップ/ティアダウンの再現性
TASは、さまざまなシステム、サーバー、およびCI/CDパイプラインをサポートするために使われる。
TASがどのテスト環境でもうまく動くようにするためには、TASをテスト環境にロードしたりアンロードしたりするための計画が必要です。
TASの構築や再構築が、どのテスト環境でも同じように動くことが重要です。
TASの設定管理を行うことで、特定の設定を確実に作成できます。
これが終わったら、TASの各部分を文書化します。
これにより、テスト環境が変わったときに、TASのどの部分が影響を受けるか、または変更が必要になるかを理解しやすくなる。
内部および外部のシステム/インターフェースとの接続性
TASを特定のSUT環境にインストールした後、SUTを使う前にいくつかのチェックを行う必要がある。
これには、内部システムや外部システム、インターフェースへの接続が利用可能かどうかを確認することが含まれる。
具体的例
- サーバーにログインする。
- テスト自動化ツールを起動する。
- テスト自動化ツールがSUTにアクセスできることを確認する。
- 設定を確認する。
- システム間のテストログとテストレポートの権限が適切に設定されていることを確認する。
これらの前提条件を確立することで、TASが正しくインストールされ、構成されていることを確認できる。
TAFコンポーネントのテスト
TAFコンポーネントもアプリケーションと同様に、個別にテストおよび検証する必要がある。機能テストと非機能テストです。
また、テストログとテストレポートは、テスト自動化とSUTの動作の状態に関する正確な情報を生成する必要がある。
非機能テストの例としては、TAFのパフォーマンス低下、メモリリークなどの欠陥を示す可能性のあるシステムリソースの利用、およびTAF内および/またはTAF外のコンポーネントの相互運用性の欠如の理解などが挙げられます。
テスト自動化スクリプト、スイートの期待通りの動作
自動テストスイートは、完全性、一貫性、および正しい動作についてテストする必要がある。
さまざまな種類の検証チェックを使って、自動テストスイートがいつでも使用可能であるか、使用に適しているかを確認する。
テストスイートの構成をチェック
完全性をチェックします（たとえば、すべてのテストケースに期待される結果があり、テストデータが存在すること）。
また、TAFとSUTの正しいバージョンを確認します。
TAFの新しい機能に焦点を当てた新しいテストを検証
TAFの新しい機能が初めてテストケースで使用される場合、その機能が正しく動作することを確認する。
テストの再現性を考慮
テストを繰り返す場合、一貫性を持ってテスト結果は常に同じである必要がある。
レースコンディションなどにより信頼できるテスト結果が得られないテストケースは、一旦アクティブな自動化テストスイートから外し、原因特定の分析する必要がある。
そうでなければ、これらのテストの実行を繰り返し分析するのに時間がかかってしまう。
自動化テストツールの侵入性を考慮
TASは多くの場合、SUTと密接に結合されます。
これは、相互作用のレベルに関してより良い互換性があるように設計されている。
しかし、この緊密な統合は、悪影響をもたらす可能性もあります。
たとえば、TASがSUT環境内に配置されている場合、SUTの機能は、手動でテストを実行する場合と異なる可能性があり、パフォーマンスにも影響を与える可能性がある。
高いレベルの侵入は、本番環境では明らかではないテスト中に失敗を示す可能性があります。
これが自動テストで失敗を引き起こす場合、TASに対する信頼が大幅に低下する可能性があります。
開発者は、テスト自動化によって特定された障害を可能であれば手動で再現し、分析を支援する必要がある場合があります。
テスト自動化による予期しない結果の特定
テストスクリプトが予期せず失敗または成功した場合、根本原因分析が必要です。
これには、テストログ、パフォーマンスデータ、セットアップ、テストスクリプトのティアダウンの検査が含まれます。
断続的な障害は分析が難しく、欠陥はテストケース、SUT、TAF、ハードウェア、ネットワークに存在する可能性があります。
システムリソースの監視やテストログの分析が役立ちます。
必要に応じて、テストアナリストや開発者のサポートを受けることも重要です。
また、すべてのアサーションが適切に配置されているか確認することも必要です。
静的解析によるテスト自動化コード品質の向上
静的コード解析は、プログラムコードの脆弱性や欠陥を発見するのに役立つ。
自動スキャンにより、SUTの欠陥をレビューし、コード品質基準を満たすことができます。
これは、DevSecOps実装において重要な役割を果たします。
スキャン結果は重大度で分類され、開発チームは優先順位を設定できます。
静的解析ツールは、コードの修正提案や品質向上のためのアドバイスを提供します。
テスト自動化コードもスキャン対象に含めることで、セキュリティリスクを軽減できます。