最近、多くのテスターが耳にし、あるいは口には出さずとも心の中で感じている不安があるかもしれません。
AIはテストケースを書くことができます。
AIはスクリプトを生成できます。
AIはログを読むことができます。
AIはテストデータの作成を支援し、エッジケースを提案し、さらにはPlaywrightのスクリプトのドラフトまでも、それなりのクオリティで作成してしまいます。
では、テスターはどこへ向かうのでしょうか?
少し深刻に聞こえるかもしれません。しかし正直なところ、これは的外れな問いではありません。ただ、より詳しく見てみると、問題は「テスターの仕事がなくなる」ということではなく、「テスターのこれまでの古い働き方の価値が薄れている」という点にあります。
もし、テスターの主な仕事が「要件を受け取り、フォームに従ってテストケースを書き、テストを実行し、バグを報告する」というサイクルをスプリントごとに繰り返すだけのものであれば、確かにAIはその領域に非常に速いスピードで侵入しています。そして、それは機械が得意とする領域でもあります。速く、一定で、疲れ知らず、構成のコピーも苦にせず、回帰テストがどれほど長くても不満を言いません。
しかし、テスターの役割をより高いレイヤーで見れば、話は全く変わってきます。
AIが得意なのは「操作」の部分であり、「正しく理解する」ことではありません。
ここを切り分けて考える必要があります。
AIは要件からテストシナリオの作成を支援できます。
AIはオートメーション用のテストスクリプトを生成できます。
AIはハッピーパスに沿ったテストケース一式をドラフトし、妥当な例外ケースをいくつか提案することさえ可能です。
うまく活用すれば、トレーサビリティマトリクスの作成、カバレッジのリビュー、不足している箇所や重複している箇所の特定も手助けしてくれます。
これらは現実であり、今後さらに進化していくでしょう。
しかし、これらすべてには一つの条件があります。それは、インプットが十分に明確であること、使う側が何を問いかけているのかを自覚していること、そしてアウトプットが人間の思考によってリビューされることです。
AIは、現実の世界で自社のシステムがどのように運用されているかを自律的に理解しているわけではありません。
要件定義書が簡潔に書かれていた場合、ビジネスフローのどこが「極めて重要」なのかを、AIが自ら察知することはありません。
また、ロジックの欠陥が見逃され、リリース後に問題が噴出したとしても、AIがその責任を負うことはありません。
AIは加速させるための道具としては非常に優秀です。しかし、使う側が慣性だけでテストを行っている限り、AIが自動的に「信頼できる品質」へと変えてくれるわけではないのです。
これは耳の痛い話かもしれませんが、はっきりと言うべき点です。
長い間、多くの現場でテスターの役割は、知らず知らずのうちに「実行」に近いものへと引き寄せられてきました。
・ドキュメントを読む
・テストケースを書く
・テストを実行する
・バグを報告する
・再テストをする
・チケットをクローズする
もちろん、これらの作業は依然として必要です。しかし、テスターの価値が主にこの部分にあると解釈されるのであれば、AIによるプレッシャーは非常に速いスピードで強まるでしょう。なぜなら、これらは構造が比較的明確で反復が多く、ツールによって加速させやすい種類の業務だからです。
テスターをより強くするのは、ある日の午後にどれだけ多くのテストケースを書けたかではありません。
より重要なのは、以下の点です。
・ビジネスフローを理解しているか
・曖昧な要件を発見できているか
・不足しているシナリオを見抜けているか
・どこを深くテストし、どこを最低限の確認に留めるべきかを知っているか
・単なるチェックリストレベルではなく、システムレベルで品質を守れているか
言い換えれば、強いテスターとは単に「ソフトウェアを試す人」ではありません。
彼らは、品質をどこで設計すべきか、どこで制御すべきか、そしてリスクがどこに潜んでいるかをチームが明確に把握できるよう支援する人なのです。
AI時代のテスターは、ビジネス分析(Business Analysis)にさらに近づくべきです。
これは非常に価値のある方向性だと私は考えています。
実際、多くの優秀なテスターはずいぶん前からこれを行ってきましたが、明確に言語化されていなかっただけです。彼らはコードが完成するまでテストを待つことはありません。早い段階で要件を読み込み、業務ロジックを精査し、不明な点を問い直し、例外フローについてチームに注意を促し、デリバリーのライフサイクルの最初から品質を引き上げています。
AI時代において、この方向性はさらに重要になります。
AIがアーティファクト(成果物)の作成を強力に支援できるようになった今、人間の役割はより上流のプロセスへとシフトする必要があります:
・要件の明確化
・ビジネスルールの切り出し
・欠陥の発見
・前提条件へのチャレンジ(検証)
・境界ケースの特定
・ビジネスの意図とシステムの検証方法の橋渡し
ビジネスを深く理解しているテスターは、単に「システムは正しく動くか?」と問うだけではありません。
彼らはさらにこう問いかけます:
・「誰にとって正しいのか?」
・「どのような条件下で正しいのか?」
・「ユーザーが標準フローから外れた操作をしたらどうなるか?」
・「2つのビジネスルールが衝突した場合、どちらのルールが優先されるか?」
・「技術的にはパスしていても、業務上の期待値と異なる場合はパスとみなすのか、フェイルとみなすのか?」
これこそが、品質が真に意味を持ち始める領域なのです。
おそらく最も有益な見方は、「AIはテスターの代わりではない」ということです。AIは、テスターが単純作業から解放され、より価値のある業務に時間を割くための「てこ(レバレッジ)」なのです。
1. AIをテストシナリオのドラフト作成に活用する
要件定義、ユーザーストーリー、業務フロー、あるいは会議の議事録から、AIは初期のシナリオセットを非常に素早くドラフトできます。これは、生のドキュメントからレビュー可能なテストの枠組みへと移行する際に特に有効です。
しかし、価値は「AIが早く書くこと」にあるのではありません。
価値は、テスターがそのドラフトを使って以下の作業ができる点にあります:
・漏れているフローの精査
・例外パスの追加
・リスク度合いに応じたシナリオの切り分け
・分析段階での欠陥の特定
2. AIをテストマトリクスとカバレッジレビューの支援に活用する
ここは、多くのテスターが大幅にスピードアップできる部分です。
例えば、要件とシナリオ一覧から、AIは以下の支援が可能です:
・機能ごとのカバレッジのグルーピング
・条件と期待結果の照合
・トレーサビリティマトリクスのドラフト作成
・重複箇所の精査
・カバーされていない可能性のある領域のハイライト
以前はテスターが多くの時間を費やして表を埋め、手動でチェックしていましたが、今ではAIが枠組みを即座に作成してくれます。それにより、テスターは「表を埋めること」にエネルギーを注ぐのではなく、「このカバレッジでリリースを守るのに十分か?」という重要な問いに集中できるようになります。
3. AIをテスト成果物(アーティファクト)のリビューに活用する
これは非常に実用的ですが、見落とされがちな部分です。
テスターはAIを「副次的なリビュアー」として以下のように活用できます:
・要件とテストケースの整合性の確認
・シナリオに反映されていないビジネスルールがないかの確認
・期待結果が抽象的すぎないかの確認
・テストセットがハッピーパスに偏りすぎていないかの確認
・検討すべきエッジケースが他にないかの確認
AIは本物のリビュアーに代わるものではありません。しかし、膨大な資料を読み直すことを厭わない、非常に忍耐強く迅速な校正者になってくれます。
4. AIをオートメーション(例:Playwright E2E)の加速に活用する
これは非常に明確な活用領域です。
ある程度固まったシナリオセットから、AIは以下の支援が可能です:
・Playwrightスクリプトのスケルトン(骨組み)作成
・初期段階のロケーターマッピングのドラフト
・アサーション(検証点)の作成
・テストデータのバリエーション生成
・重複するスクリプトのリファクタリング
・テストスイート構成の提案
適切に活用すれば、テスターやQAエンジニアは初期作成や反復作業の時間を大幅に節約できます。
ただし、明確にすべき点があります。AIがスクリプト作成を支援できるからといって、「そのテストが存在する価値があるか」をAIが理解しているわけではありません。無意味な自動テストセットも、AIなら一瞬で生成できてしまいます。長く、不安定で、メンテナンスが困難なE2Eテストは、人間が書こうがAIが書こうが技術負債に変わりありません。
だからこそ、AIで素早くスクリプトを作成すればするほど、品質の思考を持つ人間が以下を判断する必要があります:
・どのテストを自動化すべきか
・どのテストを探索的テスト/マニュアルテストに留めるべきか
・E2Eではなく、ユニットテストや統合テストの階層で担保すべきものはどれか
・どのアサーションが真に価値があるか
「テスト実行者」から「品質設計者」へ
おそらく、これが最も特筆すべき転換です。
かつて多くのチームでは、テスターを最後の方塞(ほうさい)として見ることに慣れていました。
・ビルドが終わったらテストに渡す
・テストが終わったら報告する
・バグ修正が終わったら確認する
単にチェックリストを実行するだけの人ではありません。
次のような役割を担う人です:
・要件の明確化に貢献する
・チームがリスクを見極める手助けをする
・意味のあるシナリオを設計する
・カバレッジを制御する
・どこを自動化すべきかを決定する
・AIを使って実行を加速させるが、判断(ジャッジメント)の部分は手放さない
言い換えれば、テスターは機械が得意とする部分でAIと競うべきではありません。
テスターはAIを活用することで、より思考を要し、よりシステムを理解し、よりビジネスに近い「品質」の領域へと自らを押し上げるべきなのです。
本当に恐ろしいのは、周囲のすべてが変わってしまったのに、以前と同じやり方でテストを続けていることです。
・要件定義が終わるまでプロジェクトへの関与を待っている。
・フォームを埋めるようにテストケースを書いている。
・チェックリストに従ってテストを実行するだけで、業務ロジックに疑問を持たない。
・オートメーション(自動化)を「他部署」のことだと考えている。
・バグの数だけを品質の主な指標(メトリクス)と見なしている。
もしそのやり方に固執するなら、AIによって多くの人が取り残されたと感じることになるでしょう。
しかし、もしテスターがAIを作業的な部分を加速させるツールとして使いこなし、同時に自らの役割をビジネス分析、シナリオ設計、マトリクスレビュー、そしてオートメーション思考へと広げることができれば、話は全く別です。
そうなれば、AIはテスターの存在を希薄にすることはありません。
それはただ、テスターがより「本質的な役割」へと進化することを後押しするだけなのです。
AI時代のテスターの仕事がなくなることはありません。しかし、手動の実行だけに終始し、型通りにケースを書き、慣性でテストを走らせるような働き方の価値は、以前よりも速いスピードで失われています。
より大きな機会は別のところにあります:
・ビジネスをより深く理解する
・要件定義の段階からより早く参画する
・AIを活用してシナリオ設計を加速させる
・マトリクスとカバレッジをより高度に制御する
・成果物(アーティファクト)をよりスマートにリビューする
・真に投資価値のある部分でオートメーションを推進する
結局のところ、問うべきなのは次のようなことではないでしょうか。
「AIが実行部分を肩代わりしたとき、どのテスターがより強くなれるのか?」
その答えは、おそらく最も多くのテストを実行した人ではありません。
それは、より優れた「品質を設計できる人」なのです。