現在弊社ではmablを使って自社プロダクトに対する手動UIテストを自動化するプロジェクトに取り組んでいます。このプロジェクトでは、自動テストほぼほぼ未経験の手動テスターの方が将来メインとなって自動テストを実装・保守・運用していくことが想定されています。
他社さんでも同様に「自動テストほぼほぼ未経験の手動テスターの方が自動テスト担当になっていく」ということは多々あるのではないでしょうか。
そんなプロジェクトに参画しているアーキテクトの方/エンジニアの方に向けて、今回はmabl公式ブログが先週公開していた「3 Tips to Help Transition from Manual to Automated Testing」を翻訳しました。
文中ではmabl固有の操作方法等が出てくるため"mablを使って"とタイトルには入れましたが、アンチパターン自体はあらゆるテストツールに通ずるものと思います。ぜひどうぞ！
翻訳
はじめに
手動テストから自動テストに移行することは簡単なように思えるかもしれませんが、事態はそれほど単純ではありません。実際やってみると、手動テストを通して培われたいくつかのスキルが、自動テストの文脈に持ち越すことができないと気づくでしょう。
実のところ、十分なトレーニングを受けていない手動テスト担当者が書いた自動テストには見ればすぐに分かってしまうくらいの「痕跡」が残ってしまいます。自動テストツールを導入する際には、手動テスターたちがツールを完全に使いこなせるように丁寧なオンボーディングをしてあげる必要があります。
手動テスト vs 自動テスト
もしあなたが手動テスターなら、きっと効率的にテストを実行できることでしょう。
例えばUIテストでは、シナリオに沿ったテスト実行をして、なにかおかしな事があればメモしますよね。あなたの目そのものがテストツールであり、あなたのアプリケーションに対する理解をもとに検証を行うというわけです。アプリケーションが期待通り動いていないことなんかも触ってみればわかるでしょう。
ここで重要なのは、こうした人間の洞察をコードとして表現することはできない、ということです。
多くの場合、手動テスターが十分なトレーニングを受けないままに自動テストツールを利用すると、手動テストを実行する際に習慣化されている手順をそのまま自動テストに書き起こしてしまい、アサーションのない非常に長いテストを作成してしまいがちです。
こうしたテストは実行に時間がかかり、誤検出(False-Positive)につながる可能性が高くなります。さらに、これらのテストは、アプリケーションの品質向上につながる価値あるデータを提供せずにFailすることがよくあります。
こうした事態を防ぐために、手動テストの考え方が自動テストでは仇となる3つのアンチパターンを紹介します。
1. アサーションのないテスト
はじめに簡単な例として、ログインページからログインすると、コンタクトページに遷移するアプリケーションをテストするシナリオを考えてみましょう。
まずメールとパスワードを入力してログインし、次に表示されるコンタクトフォームに何かを記入するようにしてみましょう…。と。ここまで順調のように見えますが、実はここに問題が潜んでいます。
アサーションが追加されていないことです。アサーションがないと何が起こるのでしょうか？
アサーションがあることで、mablのような自動テストツールは、「ログイン後、コンタクトページが読み込まれる」というようなことを知ることができます。
もしコンタクトページがロードされない場合、テストはFailするはずです。ここで重要な点は、アサーションがなければ、コンタクトページが読み込まれない場合に自動テストツールはテストがFailしたことが分からないという点です(少なくともmablでは)。例えばmablでは、テストがFailするのではなく、次のテストステップへと進みます。mablはコンタクトフォームのように見えるページ要素を見つけて、コンタクト情報をその要素にダンプして、無意味にテストにPassさせようとします。
ページを遷移するときにアサーションを挿入することは、より信頼性の高く、意味のあるフィードバックをもたらす効果的な自動テストを構築するための重要なベストプラクティスです。
訳注
mablやAutifyといったAI自動テストツールは、もし取得対象の要素が存在しない(変更された)場合、ページ構造から変更先の要素を推定し自動で取得要素を修正する機能を有しています。(Auto-healing)
実際にmablでテストを作成していくと、テスト実装時に注意を払わないとテスト実行時に意図せずAuto-healingが発動してしまいテストがFailすることが多々ありました。
この「ページを遷移する際にはアサーションを入れよう」というプラクティスが第一に挙げられているのは、AIテストツールベンダの方ならではの視点といえるのかもしれません。
2. 不必要なテストステップを加える
航空会社のウェブアプリケーションをテストしているとしましょう。フライトを検索する機能をテストしているのであれば、自動テストであれば簡単に検索パラメータを入力し、返却された値を検証することができます。一方、アプリケーションでフライトを「予約」する機能を自動でテストしている場合は、検索はテストに含める必要がないので検索フィールドをスキップすることができ、特定のフライトのURLからテストを開始できます。
一方、手動でテストを行っている場合、シナリオの途中からテストを開始することは難しいでしょう。予約機能だけをテストしたい場合でも、フライトの検索から始めることがほとんどかと思います。この違いを意識せずに自動テストケースを設計してしまうため、手動テスターがテストを自動化すると、オーバーテストになる傾向があります。
オーバーテストは、Failの原因となる要素が複数あるため、価値あるフィードバックを提供しないことが多々あります。この例では、仮に検索機能が失敗した場合、予約機能が正しく機能しているかどうかはわからなくなってしまいます。
もっと極端な例で言えば、500の条件付きステップを持つテストを想像してみましょう。もしどのステップも失敗すると、テスト全体がFailするとしたら、このテストから有用な情報を抽出することは困難ですよね。
ここでの重要なプラクティスは、テスト名の隣にある、テスト実行結果の「Fail」という文字を見ても何がFailしたのか分からない場合、テスト設計を再考すべきだということです。
3. ツールが提供する高度な機能を使わない
最後に、手動テスターは自動テストツールが提供する高度な機能を使わない傾向があります。例えば、mablにはAPIコールとUIテストを組み合わせる機能があります。APIコールを使えばいつでも好きなときにデータを作成・編集・削除することができます。一方で手動テスターは、APIテストを使ってテストするために、わざわざダミーレコードを作成してしまうことがあります。
より効率的な方法は、2つのテストを作成して組み合わせることです。まずテストレコードを作成するAPIコールを行うAPIテストを実行し、UIテストをその後に実行させることで、UI上でテストレコードを最初に作成しなくても、APIで生成されたデータを使って動作できるようにすることができます。このようにテストを数珠つなぎにすることで、アプリケーションの大部分をより速く、より効率的にテストすることができます。
訳注
「高度な機能を使わない傾向がある」というと若干冷たく聞こえますが、実態としては「機能の存在を知らないか、もしくは知っていても使いこなせない」の方が適切なように思います。
最大の原因は教育が不足していることでしょう。それが「最後に」での教育に関する話題に繋がっています。
最後に
mablチームは、良いテスト習慣は一朝一夕には身につかないことを分かっています。私たちは、最先端の自動テストツールだけでなく、最高水準のトレーニングも提供することに専念しています。どのようにお役に立てるかお聞かせください。
訳注（？）
訳者は今度現地技術者のトレーニングを受けられそうです。たのしみ！