2022年5月6日 / 最終更新日時 : 2022年5月9日 user 事例・ソリューション

自動テストより手動テストを選ぶべき場合：ポッドキャストトランスクリプト

どのような場合にテストを自動化すべきなのでしょうか？Idera DevOps Toolsポッドキャストのこのエピソードでは、Ranorexプロダクトマネージャーのジョンレイノルズとジュリーフェルバースが、テスト自動化を使用すべきタイミングと、手動でテストを行うべきタイミングについて説明します。

このポッドキャストは、2021年2月10日に公開されたものです。トランスクリプトは元の録音から若干変更されています。全編をお聴きになるには、以下をクリックしてください。

ジュリーフェルバース: Idera DevOps Toolsポッドキャストの最新エピソードへようこそ。私たちの目標は、ソフトウェア開発における重要なトピックについて皆さんに情報を提供することです。アプリケーションの構築、テスト、デプロイの各ステップで約100万人のユーザーを支援するソリューションを持つ当社の専門家が、魅力的な洞察、視点、情報をご提供します。

私はジュリーフェルバースです。今日はジョンレイノルズと一緒です。二人ともRanorex Studioのプロダクトマネージャーです。今日はソフトウェアのテスト戦略において、手動テストと自動テストのどちらかを選択するタイミングについてお話しします。こんにちは、ジョン。お元気？

ジョンレイノルズ: ジュリー、ありがとう。今日はかなり調子がいいですね。

ジュリーフェルバース: それは良かった。最近、ジョンはウェビナーで手動テストから自動テストに移行するプロセスについて取り上げましたね。そのウェビナーでテストを100%自動化することを期待してはいけないと認めています。また、自動テストと手動テストは互いに補完し合うものだとも述べています。とはいえ、ソフトウェアテストの自動化を始めるためのベストプラクティスは存在するはずです。

では、投資した時間と労力に対してどのテストケースが最も高いリターンをもたらすかを判断するには、どうしたらよいでしょうか？ジョンも私もQAテストの経験があるわけですが、テスト自動化を始めるためのベストプラクティスは何でしょうか？

ジョンレイノルズ: 理論的には、どんなソフトウェアテストも自動化できます。しかし、問題はどこに正しく時間を投資しているかということです。自動テストの開発と保守の方がコストがかかるのか？それとも、手動テストの方が適しているのか？そこに焦点を当てる必要があります。自動化に適したテストを特定し、そうでないテストの存在を認識することです。つまり、労力に見合った最高のリターンを得たいのです。成功するためには、自動化のための一定の基準を満たすテストケースに戦略を集中させる必要があります。テストのリソースは限られているので、テスト自動化プロジェクトを立ち上げる際に最初に考慮すべきことの1つは、どこに焦点を当てるのかということです。皆さんは何を自動化するのですか？

ジュリーフェルバース: 確かに、どのように移行するかは確認できましたね。次に話し合う必要があるのは、何を自動化するかということであり、有益なテストケースに焦点を絞って始める必要があるということですね。

ジョンレイノルズ: その通りです。自動化するテストのリストに優先順位をつけることで、テスト自動化戦略を成功に導くことができるのですね。

どのテストが自動化の候補で、どのテストがそうでないのか？

ジュリーフェルバース: いいですね。では、「どこから手をつければいいのか」について自問自答しながら順に説明していただけますか？というのも、「よし、テストの一部を自動化しよう」と一歩を踏み出した後、どこから始めるべきかについては多くの意見があると思うのです。どのように焦点を絞ればよいのでしょうか？

ジョンレイノルズ: まず「そのテストは繰り返されるのか」という質問があります。テストを自動化することは、テストを再実行する場合にのみ価値があります。なぜなら、もしテストを一度しか行わないのであれば、自動化スクリプトは実行されないからです。そのため、テストを複数回実行するかだけでなく、どのくらいの頻度でテストを実行しているかを確認する必要があります。つまり、最も頻繁に実行するテストは、最大の時間投資収益を得ることができるため、最初に自動化するテストになる可能性が高いということです。

ジュリーフェルバース: その通りです。そして、ここには複数のメリットがあると思います。反復テストにかかる時間と費用を節約できるだけでなく、少なくとも私の経験では、手動の反復テストをなくすことで士気が向上します。つまり、QAチームの士気を向上させ、より困難なタスクにもっと関わらせることができるのです。手動テストの場合はミスが発生しやすいので、人的要因を排除することも検討する必要がありますが、これは精度を高めるのに役立ちます。より難しいテストに時間を割くことができるようになるのです。反復テストは別として、QAチームから大きな負担を取り除くことができたわけですからね。

では、次は何でしょうか？テストの自動化で素晴らしい成果を得られる場所は他にもあるでしょうか？

ジョン レイノルズ: 回帰テストとスモークテストの2つも自動化の候補です。これらのテストは最終的に最も頻繁に実行されるものなので、頻度に関する質問に戻りますが、一般的にこれらは製品全体をある程度カバーするテストです。これらのテストを自動化することで、製品全体の品質と安定性をより迅速に評価できます。

回帰テストスイートを自動化することで、DevOpsパイプラインのビルドプロセスと統合し、ビルドプロセスに品質をシフトさせることもできます。これらのテストは、いずれにせよ、ビルドのたびに実行することになる項目です。自動化することで、自動化プロジェクトに移行して開始するための重要な候補となります。

ジュリーフェルバース: 回帰テストの話ですが、少なくとも私の経験では、回帰テストが得意で、常にそれを実行している企業があります。しかし、ビルドアウトや新しいソフトウェアのアップデートを急ぐと、回帰テストが見落とされることがあります。これは、回帰テストを確実に実施する上で、大きな影響を与えます。回帰テストは理にかなっており、常に行うべきものです。しかし、急いでいるときや、アジャイル環境で素早くコードを展開しようとしているときには、回帰テストが見落とされることがあります。

ジョンレイノルズ: CI/CDパイプラインを通じて、ビルドプロセスの一部として回帰テストを追加すれば、毎回確実に回帰テストを実行できます。時間がないために結局は手動で行うテストを一部失うかもしれません。しかし、少なくとも回帰テストとスモークテストは、「私のアプリケーションは少なくとも安定しているのか？デプロイできるのか？」といったことを判断するのに役立ちます。たとえカナリアリリースやそのようなものを行おうとしている場合でも、少なくともアプリケーションがどのように動作するかの最初のベースラインを得るのに役立ちます。

次に、自動テストを検討する際に、どのテストを並行して実行するかを決定することも、デリバリーを迅速化するための助けとなります。順次実行に対して並行実行できるテストがあれば、これらのテストを異なるVMやマシン、インスタンスで同時に実行することで、時間を大幅に節約できます。これにより、デリバリーが迅速になり、より多くのテストをより短時間で実行できるようになります。

順次テストについては、もしこれらのテストが特定の順番でしか実行されないのであれば、自動化のための最良の候補とは言えないかもしれません。自動化することは可能でしょうが、時間を有効に使うことができないかもしれません。あるいは、自動化したいことの優先順位が低いだけかもしれません。特に、自動化への移行期であれば、並行実行できるテスト、順次実行されないテスト、他のテストへの依存度が低いテストは、より簡単に (あるいはより良く) 開始できる候補です。

そして、並列テストなど、他にもいくつかの項目があります。通常、テストを並行して実行できるかどうかを示す項目には「複数のデータセット、パス、または環境でテストを実行しているか？クロスブラウザーテストはあるか？」といったものがあります。これらは並行実行に最適なテストです。異なる認証情報または入力を使って異なるログインを実行する必要はありますか？データソースがある場合は、おそらくそのデータを使ってログインテストを並行実行することもできます。

ジュリーフェルバース: 確かにそうですね。さて、「これだけのコストと時間の節約をするのであれば、QA にこれほど多くのリソースが必要だろうか」と思われるかもしれません。私が発見したのは、今でも必要だということです。QA担当者は解放され、より複雑なテストケースに取り組んでいます。そのようなテストケースは長く、退屈で、手動で実行する必要があるかもしれません。多くの場合、これらは回避されますが、品質とユーザーエクスペリエンスに影響を与えます。また、テストのカバレッジと精度が低下する可能性もあり、そこでも障害が発生しやすくなります。では、より複雑な機能に移行する場合、何を最優先すべきだと思いますか？

ジョンレイノルズ: より複雑な機能を検討し始めたら、「より優先順位の高い機能は何か」を検討し始めるとよいでしょう。より複雑な機能であれば、ツールの他の部分と統合されているため、障害が発生しやすくなる可能性があります。そこで、これらの機能自体に優先順位を付ける必要があります。自動化の投資収益率を大きくするのはどの機能でしょうか？すでに説明した他の基準に基づいて、自動化の候補となると同時にテストする必要があるものに優先順位を付けます。つまり、失敗する可能性が高いものだけに注目するのです。過去のレポートから、そのような分析を得ることができるかもしれません。

そして、いくつかのテストの失敗率を見て、より高いROIを得られるのはそれらのテストだと考えてください。

ジュリーフェルバース: まったくそのとおりです。おっしゃるとおり、製品の安定性を保証するためには、失敗しやすい部分が重要です。これは、顧客維持、品質、ユーザーエクスペリエンスという点で非常に大きな意味を持ちます。しかし、優先度の高い機能とは、重要なビジネスパスや、顧客が期待する製品の主要機能であるかもしれません。以前ウェビナーであなたがおっしゃったこと、そして私も申し上げたことですが、テストケースの100％自動化を期待すべきではないという話題に戻りたいと思います。手動テストと自動テストの適切なバランスを見つける必要があります。そうすれば、時間をかけてじっくりとテストすることができます。

どの自動化ツールを選べばいいのか？

ジュリーフェルバース: ここまではテストケースについて話してきました。使用するツールについてはどうでしょうか？どのツールをいつ使えばいいのか、どうやって判断するのでしょうか？

ジョンレイノルズ: そうですね、注意すべき重要なことの1つは「テストケースを100%自動化できないだけでなく、テストを100%実行することもできない」ということです。アプリケーションを完全にテストすることはできないのです。アプリケーションのテストカバレッジを100%にすることはできません。なぜなら、非常に多くの不確定要素が存在するからです。ですから、目標は可能な限り多くのカバレッジを取得することです。

ジュリーフェルバース: それは素晴らしいポイントですね。

ジョンレイノルズ: ありがとう。カバレッジの側面では、自動化のために選択するツールに限界があることが挙げられます。自動化ツールの中には、コード化された自動化には向いていないものがあります。たとえば、WebDriverのエンドポイントやAPIのエンドポイントを利用した自動化や、負荷テストを実行するテスト自動化などです。しかし、それぞれのツールにも限界があります。負荷テストツールを使用してUIをテストすることはありません。PostmanのようなAPIテストツールを使ってWebインターフェイスのすべてのボタンが存在するかを確認することはありません。ですから、自動化を行う際に、どこに重点を置くかを決めれば、ツールはその重点に沿ったものになるはずです。APIテストやシングルフォーカス以上のことをするツールがあってもいいでしょう。しかし、ツールによって制限されることに変わりはありません。したがって、今持っているツール、あるいはこれから使おうとしているツールに基づいて、テストケースに優先順位を付ける必要があります。

ジュリーフェルバース: ということは、ウェビナーの前半で手動から自動に移行するタイミングについての話がありましたが、ツールを選ぶときには、何を自動化したいかについて、すでに十分な考えを持っている必要があるということですね？

ジョンレイノルズ: はい、ツールを評価するのに何ヶ月もかかってしまうかもしれませんから。事前に計画を立てておかないと、ROIの低いツールを評価してしまう可能性があります。もしあなたが、ツールでより多くの単体テストを実行できるように時間を解放する必要があるなら、つまり単体テストに集中する必要があるなら、UIテストの自動化は適切なツールではないかもしれません。逆に、開発者のコードやビルドプロセスにすでに優れた単体テストが組み込まれていて、大きなWebインターフェイスがある場合は、Webインターフェイスで自動化できるものに集中することをお勧めします。

ジュリーフェルバース:したがって、現在のプロセスを評価し、テスト自動化戦略の目標を設定することで、実現可能性のいくつかに対処する必要があります。ただし、おっしゃるように、自動化がすべての手動テストに取って代わるわけではありません。トレードオフがあるのです。

ジョンレイノルズ: その通りです。手動テストから自動テストに移行するとき、あなたが何度か言及していますが、手動テスターを排除することはありません。彼らが最も得意とすることに時間を割けるようにするのです。それはスモークテストではなく、探索的テストや、製品を壊してみようとすること、あるいは自動化できない複雑なタスクを実行することです。

どのテストを実際に手動でテストするかを評価する際、時間とともに変化するアプリケーション領域を見ていますか？あるいは、すでに開発中の製品やプロジェクトがあり、UIを一新しようとしているのでしょうか？もしあなたが自動テストに切り替えようとしていて、UIの全体的な見直しを計画しているなら、UIの自動テストは、UIが更新されるまで中断してください。テストをやり直すのは無意味です。

そこで、製品ラインやその他の統合機能、関連機能で行われる変更点を詳しく調べてください。もしそのような変更があるのなら、それは今すぐ自動化するテストではありません。それらのテストは、リリースが終了して安定するまでは手動テストとしておきます。そして、それらの手動テストを回帰スイートに移行して、新機能のテストを開始することができます。

ジュリーフェルバース: 良いポイントですね。「ある種のテストケースは自動化し、他のテストケースは自動化しない」というのは十分な理由があります。また、成功するために対処する必要のあるテストケースとテスト自動化戦略の他の領域を自動化しないのも、十分な理由があると思います。では、他に成功するために考慮すべきことは何でしょうか？

ジョンレイノルズ: 提供した入力をアプリケーションが受け入れるかどうかを確認するだけでなく、誰かが予期せぬことをしたときにアプリケーションで障害が発生しないようにする必要があります。インターフェイス上でランダムなアクションを実行しようとすると、自動化でその動作を模倣するのは難しい場合があります。たとえば、チェックアウトの途中で「戻る」「進む」ボタンを押したり、コンピュータが苦手でイライラしているユーザがやりそうなことをしている場合などです。ここで私の妻を巻き添えにするつもりはないのですが・・・

ジュリーフェルバース: そう言おうと思ってたの。私みたいですね。

ジョンレイノルズ: 接続がタイムアウトしたために怒って、チェックアウトの途中でノートパソコンを閉じてしまう人。このようなランダムな行動は、自動化では得られないものです。処理の途中でデバイスのプラグを抜くとかね。このようなことは自動テストでは起こりえないので、手動テストの担当者が色々と試すための時間を確保する必要があります。

テスト自動化のメリットは何か？

ジョンレイノルズ: 自動テストを行う際、テスト自動化ツールは、ソフトウェアの品質に関する洞察をレポートで提供してくれます。しかし、これらのレポートが自動化を行う唯一の理由であってはなりません。自動テストを実行し、成功のテスト結果を常に得るだけで、本当にそのレポートを見ているのでしょうか？失敗したテストとその原因を見て、何を修正する必要があるかを判断しているでしょうか？

より多くの「成功のテスト結果」を得るためだけに自動テストを行うべきではありません。実際にレポートを見て、テストを管理し、モニターすることが必要です。テスト結果をスポット的にチェックし、物事がまだ機能していること、つまり自動化があるべき形で機能していることを確認します。自動化へ移行する際には、これらすべてに留意する必要があります。それでも、メンテナンスは必要です。テストをうまく作成し、モジュール化し、可能な限り独立させれば、メンテナンスの必要性は若干低下するはずです。しかし、それは自動テスト戦略の一部です。

ただし、テスト結果を確認するときは、「OK、100％成功です。すべて素晴らしい」というだけでなく、実際にテスト結果を見ていることを確認する必要があります。そこで、自動化された結果をバックアップするために手動プロセスが登場します。「自動化に成功しただけでなく、探索的テストでも何の問題も発生しなかった、あるいは、数個の小さな問題しか発生しなかった」と言えるようにするためです。

ジュリーフェルバース: まったくそのとおりですね。レポートを見ていると、成功を表す緑色ばかりのレポートを見たくなるのは分かります。しかし、私の意見では、私の経験上、製品をできる限りハードにテストしていることを確認するために、多少の失敗は必要です。私がいつも言っているのは、すべてはビジネス上の意思決定から得られる損益計算書とROIに帰結するということです。

そこでジョン、私たちは、自動テストによって得られるメリットをいくつか挙げました。主に生産性の向上による時間と費用の削減です。しかし、今日の指摘の中には、品質やユーザー満足度など、ROIに有効な影響をもたらすものもあります。つまり、これは顧客維持に大きく貢献するのです。

QAテストを始めた頃、より深く複雑なテストに取り組む時間があることを、いつもとても嬉しく思っていました。あなたがおっしゃるように、探索的テストを行うべきだとわかっていても、直感的に何か心配事があるかもしれないと思いながらも、時間的な余裕がなかったのです。時間的な要素がありませんでした。私は探索的テストを行う必要があり、それが製品の品質に影響を与えることを知っていました。しかし、機能的な回帰テストを繰り返し行っていたため、時間がありませんでした。私は、もっとデータ駆動型テストやシナリオテストを実行し、顧客が製品を使用する際のさまざまなデータや使用事例を再現したいと思いました。それで、つまり、うまく言えないのですが。ソフトウェア製品を本当にテストしたかったのですが、その能力も時間もなかったのです。そういう経験はありますか？

ジョンレイノルズ: 自動化戦略をうまく計画し、優先度が高くて繰り返しの多いテストを特定すれば、コスト削減と投資の回収を早期に実現できます。したがって、「同じ入力をクリックしなければ」という作業や、同じ値や少し異なる値を何度も入力したりするような、反復的で冗長な作業を減らすことができれば、言い換えると、そのような作業を自動化に移行できれば、その分テスターの時間を解放し、A、B、Cの入力を見てD、E、Fの出力を期待するだけではない現実的なシナリオを、テスターがつついて探し回ることができるようになるのです。

ジュリー フェルバース: 「つついて探し回る」という表現が良いですね。私はいつも言っているように、良いストーリーのある問題が大好きで、物事を壊したり、解決しようとしたりするのが好きです。あなたのおっしゃる通り、これは優秀な QA テスターにも言えることです。彼らが最も楽しんでいることは、あちこちつついて探し回り、問題がありそうな箇所を見つけ、ビジネスのためにそれを解決することです。

ジョン、私たちはいつも素晴らしいディスカッションをしています。私たちは共に Ranorex Studioのプロダクトマネージャーですしね。時間を取ってくれてありがとう。そして、聴いてくださったすべての皆さんに感謝します。今後のエピソードを聞き逃さないよう、ぜひ我々のポッドキャストのサブスクリプションを登録してください。

ジョンレイノルズ: はい、ありがとうございました。素晴らしいディスカッションになりました。またすぐこのような機会があると嬉しいですね。

ジュリーフェルバース: ええ、本当に。今日はありがとう！

（この記事は、開発元 Ranorex 社 Blog 「When to Choose Manual over Automated Testing: Podcast Transcript」2022年2月10日の翻訳記事です。）