ソフトウェアテスター/QAエンジニア

Uber のエンジニアによる、Uber 自身の開発の流れのなかで動いている仕組みについての論文である。DragonCrawl は、CI/CD で継続的に走る1,013件の自動テストにわたって iOS で91.6%、Android で92.2%の合格率を達成し、新しいテストの組み込みにかかる時間を96〜120時間から4時間未満に縮め、テストの保守にかかる開発者の作業を推定27人年分節約したという。かつて台本を実行していたテストエンジニアは「Clickers」(クリックする人)ではなく「Context Engineers」(文脈をつくる技術者)として配置し直され、Uber は、人員を比例して増やすことなく、規模に応じて広げられる品質保証を実現したと述べている。時間の節約は Uber 自身の見積りであり、対象は一社のモバイルの端から端までのテストである。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

米英欧の大企業の上級エンジニア200人による自己申告の調査であり、しかも報告書を出しているのは Lightrun、デバッグの道具を売っている会社である。つまり発見と製品が同じ方向を指している。そこで引かれている Amazon の障害(2026年3月2日と5日。承認を経ずに投入されたAI支援の変更が原因とされ、その後335の系にわたる90日間のコード安全の立て直しが行われた)は独立に報じられた出来事だが、割合のほうはそうではない。対象は企業向けソフトウェアのみである。

失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。

Meta の社員による、Meta 自身の開発におけるテスト生成についての論文である。ミューテーションに導かれた、LLM による堅牢化テストの生成がすでに Meta の継続的インテグレーションの仕組みに導入されていること、それ以前の網羅を基準とする生成器は二年間 Meta で導入され、定期的に改良されてきたこと、捕捉と堅牢化の流れで生成された22,126件のテストを分析したこと、そして弱い捕捉を含む600件の差分を人手で調べた研究で、規則に基づく評価器と LLM による評価器が人の見直しの負荷を約70%減らしたことを述べている。著者ら自身は、捕捉の流れそのものは主にデータを集めるために導入されたと述べており、論文が示す確認済みの捕捉の件数は食い違っている。Meta はこれらの道具を自社で使うためにつくっている。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

大学と ByteDance の著者による査読済みの経験報告の論文で、消費者向けの大手インターネット企業に導入された道具を扱う。サービスをまたぐ業務の流れについての API の回帰テストは今も大部分を QA エンジニアがつくり保守していること、そして2025年3月に始まった9か月の本番運用で、この道具が3,196件のテストケースを生成し、コード全体の採用率が85.4%だったことを述べている。採用率は事業部門によって大きく異なった。道具をつくったのも、その採用を測ったのも著者ら自身である。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

米国の行政府の各機関を拘束する連邦の覚書である。高影響のAIについての最低限のリスク管理の実務として、各機関は、現実に予想される結果を反映した導入前のテストとリスク軽減の計画を策定しなければならない。ソースコード、モデル、データに触れられない場合は、AIのサービスに問い合わせて出力を観察する、あるいはベンダーに評価用のデータを渡すといった代わりのテスト手法を使わなければならない。そして導入後は、実行可能な場合に、AIの利用事例のテストと定期的な人による見直しを行わなければならない。拘束されるのは機関であり、テスターが名指しされているわけではない。対象は高影響の用途に限られる。

規制、補助金、あるいは公共調達が、導入を求めているか資金を付けている——constraint の鏡である。導入が求められていることを示すのであって、起きたことを示すのではないので、一件の mandate は単独では決して足りず、独立した二件で足りる。

Microsoft の AIレッドチームが、生成AI製品の安全面とセキュリティ面の欠陥を試す自らの仕事について書いた論文である。2024年10月の時点でチームは100を超える製品にわたって80件を超えるオペレーションを行っており、その量のために完全に手作業のテストは現実的でなくなったので自動化を築いたこと、そしてそうした道具を人を輪の外へ出す意図で使うべきではないことを述べている。危険の優先順位を付け、攻撃を設計し、新しい種類の害を定義するには人の判断が要るからである。これは製品の QA ではなく専任のレッドチームであり、Microsoft はモデルを売り、自社のオープンソースの道具を広めている。

雇用主がそれを本番に置いた。基準線を動かしうる——規模と、その場がどれだけ似ているかで重みづけされる。

一社における、既存の単体テストの改善であり、ビルド/合格/網羅の各条件でふるいにかけている。生成されたケースの75%がビルドでき、57%が安定して通り、25%が網羅を増やした。会社自身が書いた論文であり、日常の開発の流れのなかでの利用ではなく、期間を区切った集中期間での設定である。

実際の場での小規模な試行。導入の条件が試されていることを教えてくれるのであって、それが成り立つことを教えてくれるのではない——だから一件の試行は単独では決して足りず、独立した二件で足りる。

手動のテスターとして入ることは、このサイトのなかで最も弱い入口である。そこが最も速く消えている業務だからである。代わりに、敵対的な構えと新しい分野から入ること——誰も仕様に書かなかったことを壊せるようになること、そしてモデルを抱えた系を評価できるようになること。そこには経験のある人がほとんどおらず、チームは人を採っている。コードが書けることは、いまやこの職のなかの専門ではなく前提である。

一週間の大半が回帰テストと台本の保守なら、この職はあなたの足元で統合されつつある。向こうが動かす前に、自分から動いたほうがよい。あなたの本当の資産は、この製品がどう壊れるかについての頭のなかの模型である。それを、探索的なテスト、出荷の判断、そしてあなたのチームがほぼ確実に足しつつあるモデル由来の機能の評価に変えること。それらは上級の位置であり、先に名乗り出た人から埋まっていく。

職の形を組み替える

テストを実行する側から、品質を引き受ける側へ

「十分にテストした」とは何かを決め、出荷の判断を握り、探索的な仕事を引き受ける人が要る。その役割は残る。実行する役割のほうは残らない。

職の形を組み替える

モデルを抱えた系の評価に絞る

新しく、希少で、テスターがすでにやっていることのすぐ隣にある。モデル由来の機能を出すチームは、それが壊れていると前提する人を必要としている。

隣へ移る

テスト開発、あるいはプラットフォームエンジニアリングへ

チーム全体がテストできるようにする仕組み、環境、道具立てをつくることは、安定した需要のある開発の仕事であり、何がどう壊れるかというテスターの知識を使う。

手動でテストを実行することは、そのとおりであり、しかも速い。品質という営みのほうはそうではない——系がどう壊れるかを想像し、出してよいかを決め、そして次第に、振る舞いが一意に定まらないソフトウェアを評価する人が要る。その最後のやり方を知っている人は、まだほとんどいない。この職はテストを実行することから危険を引き受けることへ、固定の出力を突き合わせることから振る舞いを評価することへ移りつつある。その移動をやり切った人は、かつてのテスターより価値がある。やらなかった人は、自分の周りでこの職が統合されていくのを見ることになる。

信号は、今四半期、自分のチームで誰が回帰テスト一式を書いているかである。その一式が生成され、画面が変わったあと自分で直るようになったとき、たいていの検証の職を支えていた時間の塊は消えている——それが動いた具体的な能力であり、どの報告書より先に、自分たちのリポジトリのなかで目にすることになる。

手動の回帰テストとテストケースを書くことであり、自動化と印がついている二つである。手動の回帰テストだけでも、たいていの検証の職で最も大きな時間の塊である。探索的なテストと出荷の判断はそうではないが、そのどちらも、回帰テストが一週間を埋めていた人たちを吸収できるほど大きくない。

評価用のデータ集合、振る舞いの回帰検出、敵対的な指示——本物の、そして伸びている分野であり、検証の構えはそのまま移る。正直な留保は、最終的にどれだけの大きさになるかを誰も知らないほど若いこと、そして検証ではなくモデルをつくるチームの側に人が置かれる形に落ち着くかもしれないことである。