こんにちは！
最近お仕事でmablやAutifyといったAIテスト自動化ツールを触るようになりました。
これらの最新ツールを導入することによって自動テストの実装がかなり手軽になり、これまで「テストケースをどう実現するか」というところにかけていた時間を、「そもそもどうテストすべきか」という戦略の部分を考える時間に当てられるようになったと肌で感じています。（勿論、本来からそうあるべきではあったのですが。）
そこで今回はmablの公式ブログより、「6 Strategies to Maximize Your End-to-end Testing Impact」という記事を翻訳してご紹介します。(mabl公式より許可を頂いています。)
私自身そこまでは考えていなかった！という点も多々あった非常に示唆に富んだ記事なので、皆さんにも参考になるのではないかと思います。是非どうぞ！
翻訳
はじめに
mablのようなインテリジェントなテスト自動化ソリューションは、テストカバレッジを向上させることで、QAをよりインパクトのあるものにし、チームがより高品質なソフトウェアをより早くリリースできるようサポートします。これらのローコード(Low-code)ツールはとても使いやすく、初めて使う人でもパワフルなテスト自動化をすぐに利用できるようになります。
新しいテスト自動化ツールを使い始めるときに、すぐにたくさんのテストを作りはじめるのもいいです（これが楽しかったりする！）が、自動化の長期的な成功を収めるためにはより戦略的な自動化アプローチを取ることが必要です。
この記事では、多くのチームが"テスト自動化ジャーニー"を始めるのに役立った戦略を6つ紹介します。
1. 目標、コミュニケーション、整理からはじめる
"ソフトウェア品質の父"と呼ばれたWatts Humphreyはかつてこう言いました。
"Unplanned process improvement is wishful thinking."
無計画なプロセス改善は単なる希望的観測に過ぎない。
テスト自動化の成功の鍵の一つは、あなたが技術プロジェクトと組織の進化プロセスの両方を推進していることを認識することであり、その両方を計画する必要があると認識することです。
テスト自動化を始める準備ができたら、プロジェクトの主要な利害関係者全員と時間を割いて、
最低限以下のことについて議論し、合意するようにしてください。
-
目標(Goal)
- 自動化の取り組みの目的は何か？
- 成功をどのように定義し、測定するか？
- どのように組織や会社の目標と整合させるのがベストか？
-
役割(Roles)
- 以下のような品質のすべての側面について責任を持つのはチーム内の誰か?
- テストケースの定義
- テストケースの作成
- テスト失敗時のトリアージ
- 古くなったテストの更新
- テストの実行時期の決定
-
計画(Plan)
- テスト自動化のロールアウトにはどのような段階があるか？
- 各ステージで完了しなければならない主要なタスクは何か？
- どのようなタイムラインで自動化を進めるか?
-
プロセス(Process)
- どのようにコミュニケーションをとるか？
- どのように協力するか？
- どのようにテストや計画などを管理するか？
- どのようにして進捗をモニターし、学んだ教訓を取り入れ、時間をかけて改善するためにサイクルを回すか？
どんなプロジェクトでもそうですが、目標と期待値について少し前もって作業をしておくと、より良い成果が得られるでしょう。また、ソフトウェア開発がサイクル的なプロセスであるのと同じように、目標、コミュニケーション、整理の仕方も定期的に見直すことで、アプローチに磨きをかけていきましょう。
2. テストカバレッジに配慮する
End-to-End(E2E)テストはその定義上、アプリケーションを介した顧客の「旅」（訳注：ここでの「旅」はユーザーストーリーやユースケースのようなものを指しています）を捉えるものです。E2Eテストは、この視点を反映し、エンドユーザのニーズに焦点を当てるべきです。これらの「旅」のリストを作成し、優先順位をつけてください。(受け入れ基準としてすでに利用されているかもしれません。)
自動化の予算を念頭に置き、最も重要なフローのためのテストを最初に実装していることを確認してください。また、「旅」のリストを固定のものとして扱わず、常に更新しましょう。ビジネスの利害関係者と定期的に再評価し、可能であれば顧客の利用状況をテスト時に考慮しましょう。品質を判断するのは顧客であることを忘れないでください。
またE2Eテストの範囲を広げたくなるかもしれませんが、その誘惑には負けないようにしてください。例えば、境界値テスト、入力データに対するバリデーションテスト、パフォーマンステスト・ストレステスト・スケーラビリティテストなどは、ユニットテスト、統合テスト、システムテストなど他のテストレベルで行うのが最適です。
E2Eテストは、コード中の低レベルのロジックをテストするためのものではありません。ユニットテストでこの機能を実装してください。E2Eテストのような高レベルのテストは「外部から」の視点を持っているのに対し、ユニットテストは「内部から」製品をテストします。
（訳注：内部品質と外部品質の対比を指しています。このあたりにご興味がある方はつながる世界のソフトウェア品質ガイドやSQuaREシリーズを参照されるとよいかと思います。）
3. チーム全体でのアプローチをとる
"Shift Left"の最も重要な利点の一つは、チーム全体を品質に関与させることができることです――もうQAエンジニアが孤立して、品質の全責任を持つ必要はありません。
その代わりに、QA、開発者、サポート担当者などが一体となり、最初から製品の品質を作り込むことができるようになります。
このアプローチにおいてローコードテストツールを採用することは、ソフトウェア開発の専門知識なしに、チーム全体がテスト自動化にアクセスできるようにする重要な役割を果たします。
たとえば、開発者はコードをコミットする前に自動テストをローカルで作成して実行することができ、QAはコミット前またはコミット後にテストの拡張や改良を行うことができます。また、開発者はプロダクトオーナーなどと協力して、E2Eのリグレッションテストスイートを作成・維持することができますし、運用やサポートを担当している人は、本番環境でのシンセティック・トランザクション監視のために、ローコードテストを活用することができます。
mablのようなローコードツールを使用している場合は、最初からチーム全体を巻き込んで、ソフトウェア開発ライフサイクル全体のコラボレーションとビルドの品質を向上させましょう。
4. 実行効率、実行速度、再利用性を高めるために時間を費やす
多くのソフトウェア開発のベストプラクティスは、プロダクトコードに適用されるのと同じ様に、ローコードテストにも適用されます。テストスイート全体の再利用性、実行スピード、実行効率を改善するために時間を費やすことが、長期的には大きな利益をもたらすでしょう。
一般的に、E2Eテストはユニットテストよりも実行に時間がかかり、CI/CDパイプラインの一部として実行されることが多いです。チームへのフィードバックループを短縮するため、テストの実行速度を上げる方法を調査してください。
たとえば、大きなモノリシック(一枚岩)なテストを小さなかたまりに分割して、並列実行することができるかもしれません。また、テストの並列実行を可能にするために異なるユーザアカウントを使用するなどして、互いに独立したテストを設計することもできます。価値を提供しなくなったテスト、何度やっても失敗しないテスト、顧客が使用する可能性が低いユーザーストーリーをカバーするテストは、削除することを検討すべきです。
定数時間の待機を使用するなどのアンチパターンは避けましょう――これはテストを不安定(flaky)なものにする時限爆弾のようなものです。代わりに、チームと協力して、一般的なケースでは影響を最小限に抑えながら、一部のケースにおいて時折の実行時間増加を許容できるような動的な待機を考え出してください。
プロダクトコードと同じく、E2Eテストでもメンテナンスの労力を最小限に抑えるために一部のステップを再利用することが有益です。これによって最小限の変更で大規模なスイートを簡単に更新することができます。例えばログインやナビゲーションに対する操作は共通化することができます。これらの再利用可能なステップのライブラリを作成し、他のチームメンバーが簡単に活用できるようにすることを検討してください。
また、検証しようとしている動作の一部でない限り、ホスト情報、ロケーションデータ、ブラウザ固有の情報などの環境情報はテストステップにハードコーディングしないようにしましょう。例えば、同じフローを異なるユーザプロファイルやロールでテストしたい場合があります。このときには、各ロールごとに個別のテストを作成するのではなく、1つのステップ・セットを作成してパラメータとしてロールを渡すのがよいでしょう。
5. 品質シグナルを継続的に監視し、アクションのトリガーを定義する
近年、かつてのQAがやることが決まりきっていた時代から全くもって働き方が変わり、製品や組織、品質を柔軟かつ継続的に進化させる時代へシフトしています。1日、1時間、1秒ごとに新しい情報がチームに流入し、チームの行動、テスト、検証、思考などに影響を与える可能性があります。チームは、さまざまな情報の流入を可視化し、効率的かつ構造化された方法で仕事をしなければなりません。
現在のようなリモートワークの時代には、ほとんどの人がSlackのようなコミュニケーションツールを持っています。たとえば、顧客のバグを報告してもらうサポートチャネル、テストやCI/CDの失敗が特定のチームや担当者のアクションのトリガーになっているチャネル、新しいバグを報告するチャネルなど、チームメンバが注意をしなければならないチャネルは沢山あるはずです。
ここに上げたようなチャネルへのポストは、それぞれチームのアクションのトリガーとなるはずです。これらの品質シグナルの流入をどうグループ化し、どう行動するかをチームそれぞれで決める必要があります。
またQAエンジニアは、これらの品質シグナルの流入について真っ先に考える人間となり、フィードバックに基づいて特定のテストを手直しする必要があります。
特定の領域でバグが突然増加した場合、QAエンジニアはその領域のカバレッジを改善するようにチームにアラートを上げなければなりません。その事実をチームで話し合い、どこで追加のカバレッジを作成できるかを確認する必要があります。
6. テストの失敗が行動を促すようにする
私たちは、チームのワークフローにテストを完全に組み込むことができず、チームが望む品質の結果を得るのに苦労している光景を何度も目の当たりにしてきました。戦略1を参考にすると、最善のアプローチは「テストの失敗が特定のアクションを促す」ように決めることです。
具体的には、CI/CDパイプライン上でテストが失敗した際には、テストの更新、問題の修正、テスト環境の調整のいずれかによってその失敗に対処するまで、コードを変更できないようにするというのが考えられます。テストの失敗が既知の問題に起因するものなのか新規の問題に起因するものなのかを検討し（必要があれば課題管理システムに連携させ）、問題をトリアージし、それに対処する必要があります。
自動化に成功しているチームでは、問題の傾向を把握するために、テストの実行失敗をドキュメント化して分類する時間を取っているようです。失敗の分類は非常に重要です。なぜなら、バグ、実行環境の問題、問題が多いテスト設計のパターンを特定するのに役立ち、それがフィードバックループとなってチームの改善や効率化に役立つからです。
最後に：楽しもう！
新世代のテスト自動化ツールの最も重要な利点の一つは、テストをより楽しくすることができるということです。これらのツールはレガシーな自動化フレームワークで起きがちなイライラする不安定さの多くを排除し、チーム全体での共同作業が容易にします。
これらの戦略が、テスト自動化への投資を最大限に活用するのに役立ち、多くの人がテストをもっと楽しめるようになることを願っています!