手動テストと自動テストのパラドックス

このブログは「The Manual Testing and Automated Testing Paradox」を翻訳・一部加筆したものです。

自動テストは手動テストなしでは存在しません。これらはソフトウェアテストの世界における鶏と卵の関係です。

ソフトウェアテストの経験が豊富であっても、この役割に初めて取り組む人であっても、自動テストと手動テストという用語に必ず出会ったことがあるでしょう。これらの用語は対極にあるものとして位置付けられ、自動テストが手動テストの後継技術と称されることがよくあります。自動テストがソフトウェアテストの優れたアプローチだと主張する人々は、同時に手動テストは死んだ技術だ、または現在のソフトウェア開発のアプローチには適していないと断言します。自動テストを行っているなら手動テストは必要ない、という主張も聞かれます。

しかし、ここにパラドックスがあります：自動テストは、手動テストの代替手段として提案されていますが、その効果を発揮するためには、手動テストから得られる思考、探索、アプローチ、観察に依存しています。これらがない場合、私はあなたの自動テストが不十分であり、ほとんどまたは全く価値を提供しないことを保証できます。事実、これらは競合するものではなく、システムの知識を獲得し確認するための無限ループとして共存しています。その知識こそが、チームがソフトウェアに関する重要な意思決定を行う際に活用されるものです。

基本概念の定義

この関係についてさらに深く掘り下げる前に、この記事の背景を説明するために、手動テストと自動テストを定義する必要があります。

手動テスト: 事前に作成された手順に従ってソフトウェアとインタラクションし、その動作が期待される結果と一致するかどうかを確認する人間によるテスト。

自動テスト: ソフトウェアを使用して、事前に定義された指示を自動的に実行し、結果をコード化された期待される結果と照合するプロセス。人間の介入なしに実施されます。

それらは、事前に用意された一連の指示（スクリプトと呼ばれることが多い）が実行される方法を除けば、ほぼ同一です。

探索的テストについてはどうでしょうか？この記事の残りの部分は手動テストと自動テストに焦点を当てていますが、探索的テストについて触れないままでは不完全です。探索的テストは手動テストの同義語としてよく使われますが、両者は異なります。唯一の共通点は「人間が主導する」点です。探索的テストを行う際、人間には指示がほとんどないか、または最小限の指示しか与えられず、期待される結果もありません。この手法は、人間のスキルと観察に依存しています。人間は、事前に書かれた指示や結果に縛られず、大幅に自由な探索が可能です。ここに隠れたパラドックスがあります。手動テストで発見されるバグの多くは、人間が事前に書かれた指示から外れたために発見されるからです。これは驚くべきことではありません。人間は指示に従うのが苦手であり、探求したいという欲求や好奇心は人間の性質だからです。

自動化の境界

一方、自動化は好奇心を持たず、探求せず、決定論的です。確かに、AI、特にエージェント型AIは注目を浴びていますが、人間のテスターにはまだ遠く及ばない状態です。大多数の自動テストは、指示されたことを正確に実行するだけです。それ以上でも以下でもありません。彼らは固定されており、決定論的で、指示された内容を一切の逸脱なく繰り返し実行します。

少なくとも、そうすべきです。

では、なぜ自動テストにおいて最も話題に上るトピックの一つが「テストの不安定性」なのでしょうか？

テストに正確な手順を提供し、持っている知識をすべて活用したにもかかわらず、なぜテストが非決定論的になるのでしょうか？それはパラドックスのためです。テストに組み込んだ知識が不十分だったり、間違っていたりすると、テストはその欠点を反映し、さらに悪化させます。あなたが特定の状態を待っていたことに気づかなかったように、テストも気づきません。ページが異なる順序で読み込まれる可能性があることに気づかなかった場合、テストも気づきません。APIやコンポーネントの一貫性がないことに気づかなかった場合、テストも気づきません。テストの不安定さは、システムやツールの知識不足から生じ、その知識不足は探索の不足から来ています。自動化されたテストは、それらを書いたエンジニアの能力以上にはなりません。

自動化の人的側面

自動テストの出発点は、自動テストが実行する必要がある手順、テストケース、指示、またはアクションを検討することです。テストしたい動作を引き起こすアクションです。そのために必要なデータは何か、そのデータはどこから取得されるのか？別の出発点としては、要件を理解し、実装メモを調査し、自動化しようとしている動作を観察することが挙げられます。最も重要で、しばしば最終的なステップは、この動作をどのように検証するか、期待される結果は何で、正常な動作や機能する状態はどのように見えるかを考えることです。システムの理解を深めるために必要な作業です。つまり、手動テストを実施することです。

私たちはそう呼ぶことはありませんが、関係がないわけではありません。手動テストの順序と完全に一致しないかもしれませんが、すべてのステップ、技術、スキルは含まれています。唯一の本当の違いは、出力物が人間が従うテストケースではなく、コンピュータが従うスクリプトである点です。ただし、そのスクリプトが価値あるものとなるためには、この作業が不可欠です。

私はこれが真実であることを知っています。なぜなら、私自身がそうしているからです。また、数百人のエンジニアが同じことをしているのを観察してきました。私たちはテスト対象の動作を手動でトリガーし、自動化の対象となる全体像を把握するために、その動作を全体的に再現します。その後、コードを構築していく過程で、テストケースのステップを書くのと同じように、手動でフローを完了させます。自動テストを書く上で最も重要な部分と言えるでしょう。なぜなら、ここがまさに私たちの観察をコード化するためのポイントだからです。ここで強い観察型のテストマインドセットを確立することで、コードの正確性、再現性、および意図した動作を実行する能力が保証されます。特にユーザーインターフェースのテストの場合、この点は特に重要です。

自動化における幅広いスキル

自動化されたテストを作成する際、私たちは手動テスト、テスト設計、探索、コーディング、実行を同時に実施しています。これらの工程の順序は流動的で連続的ですが、すべてが含まれています。

自動化から最大の価値を引き出すためには、エンジニアがこれらのスキルをすべて習得しているか、チーム全体として習得していることを確認する必要があります。これらのスキルのいずれかに欠如があると、自動化の価値が低下します。エンジニアが不安定なテストの修正に一日中追われる「赤緑無限ループ」に陥る可能性があります。または、テストは失敗しないが生産環境に重大なバグが残る「緑の幻想」状態になるかもしれません。または、テストへの信頼が完全に失われ、テストが荒廃してしまう可能性があります。私はこれらすべてを目撃してきました。そのため、自動化の真のスキルはコードやツールではなく、テストに組み込まれるテスト思考にあると、これまで以上に確信しています。しかし、業界はコードやツールに焦点を当て、それらで解決しようとしている問題自体に目を向けていないのが現実です。

無限ループ

自動化、探索、および手動テストは無限ループです。これらは互いに支え合い、依存し合っています。高価値な自動テストを設計したいですか？自動化する対象を明確にし、システムを手動テストし、探索し、理解する必要があります。維持可能な、確定的なテストを望みますか？適切にコーディングし、良い実践に従い、パターンを実装する必要があります。テストが失敗する原因を特定したいですか？手動テストを実施し、システムを探索して、テストが間違っているのか、バグが見つかったのかを確認する必要があります。なぜ失敗したのかをより深く理解したいですか？手動でシステムを探索する必要があります。その知識を基に、テストを改善し、目的を果たさなくなったテストを削除することも可能です。これは、確認、検証、学習、報告、改善の連続したループです。

自動化テストの未来、特にAIの分野におけるそれは、テストスキルに焦点を当てることです。テストに組み込む思考と観察を向上させれば、その価値は倍増します。信頼できるテスト、理解できるテスト、そしてチームが重要な意思決定を支援するテストを手に入れることができます。手動テストは死んでいません。自動化や手動、探索的テストといった用語は単なる総称に過ぎません。重要なのは、これらの用語の下にあるスキルです。例えば、テスト設計、オラクル、リスク識別、システムモデリング、好奇心、技術スキル、コーディング、コード設計など、多くのスキルが挙げられます。

結論

自動化エンジニアがこれらのスキルを積極的に実践していない、またはそれらを保有していることに気づいていない場合、投資する時期が来ています。なぜなら、これらのスキルが欠如していると、入力がゴミなら出力もゴミになるからです。手動テスト担当者や探索的テスト担当者が自動化は飛躍的に難しいと感じている場合、彼らに既に必要な基礎を全て持っていることを伝え、その基礎は多くの自動化エンジニアよりも堅固である可能性が高いと説明してください。さらに良いのは、これらのスキルを全てマスターするのは困難であり、一人に求めるのは過大な要求です。チーム内のメンバーを組み合わせ、協力を促すことです。なぜなら、テストと品質はチーム全体の責任だからです。

自動テストの投稿について

あなたは、私たちの自動テストシリーズの第1部にご参加いただいています。このシリーズは、Richard Bradshaw氏とのコラボレーションによるものです。このシリーズでは、テスト自動化のさまざまな側面とその実装方法について深く探求していきます。

次回の記事は、2025年6月17日に公開予定です。今回は、さまざまな種類のUI自動テストとその最適な活用事例について解説します。お楽しみに！