Android の実機ラボは、端末の台数を増やしただけでは安定しません。前回の実行でログイン状態が残っている、権限ダイアログが開いたまま、キーボードや言語設定が変わっている、ストレージが不足している――こうした状態差が、アプリの不具合と同じように見えるからです。そこで、Flow や Appium の実装より先に「Run Card」を書きます。Run Card は、1 回のチェックがどの状態から始まり、何を確認し、どこで停止し、どの証拠を残すかを定義する短い契約です。 1. 目的を 1 つに絞る最初に、この実行がどの判断を支えるかを決めます。リリースを止めるスモークテストQA...

この記事について「モデルは正しい。あとはデータを差し替えて本番につなぐだけ。」デモが成功した日、私たちはたいていそう考えています。そして数か月後、モデルは正しいまま、案件だけが死にます。殺すのは数学ではありません。月曜の朝に返ってくる「解なし」、そして「なぜ私のシフトはこうなんですか?」という問い合わせ。全部、教科書の外側で起きます。この記事は連載「デモで動いた最適化が本番で止まる」(全12回)の第1回です。80行のシフト最適化PoCを実際に作って動かし、それを実測で4回壊します。PoCと本番の間に横たわる4つの谷の地図と、明日のPoCに入れられる4つの保険を示します...

AIエージェントはコードを速く書きます。もっともらしい間違いも、同じ速度で書きます。2026年4月から6月にかけて、Claude CodeとCodexを使い、3つの個人開発を進めました。AIには調査、実装、テスト追加、レビューを任せています。しかし、生成されたコードを採用する責任までAIへ渡したわけではありません。この3ヶ月で作ったのは、AIを信用する仕組みではなく、AIの成果物を信用しなくても開発を前へ進められる仕組みでした。この記事では、実際に起きた3つの失敗と、それを受けて整備した5層の品質ゲートを紹介します。なお、以下の問題がAIだけを原因として起きたと証明できたわけではあ...

テスト

先日、こんな記事を見つけたふむふむ色々考えました・・・・僕の結論・・・複数のAIにきいたらいいんじゃね？？という結論ですじゃあ、どうしようか？１：適当なプログラムつくって２：複数のAIにテストさせて３：それぞれ比較したらどう？？（強引だなあ・・・・...

3行で言うとPostgreSQL 2台に同じデータを書き込むために Kafka を経由させたら、直接書き込みより 6〜25倍速くなりました。遅くなる前提で測っていたので、最初は測定バグを疑いました。Kafka fan-out 構成なら、DB が片方落ちても手を触れずに1万2千件を取り戻せた（ただし条件付き）「Kafka を挟むぶん遅くなる」という直感は、条件を揃えて測ったら外れた速さの代償は CPU ではなく、Kafka ブローカーが常時食う 3.5〜4.7GB のメモリだった普段はオンプレの RHEL / vSphere を見ているインフラエンジニアです。Kafka ...

はじめに 先日、知人と話していて、「ブロッコリーさんは色々とすごいアウトプットをしていて、私はそのような姿をマネできないのでは？」的なことを言われました。ただし、私自身は決してそんな風には思っておらず、知人には最初の頃のアウトプットについてお伝えしました。 そしてたまたま、昔のにしさんのツイートを掘り起こしました。 特に学生さんなんかそうなんだけど、若い内はどのようにエキスパートになればいいか分からなかったりする。自分みたいに能力の低い人はエキスパートになんかなれないってなんか人生を半ば諦めたりする。でもね、エキスパートと呼ばれた人のほとんどは、若い頃はごく普通の人だったんだよ。— Yasuh…

◀前の記事へ 次の記事へ▶︎続きをみる

個人で作っている iOS アプリを TestFlight に出しました。そこで手が止まりました。それまでの検証を、全部 __DEV__ でやっていたからです。60 秒で開封、匿名ログイン、サンプルの録画。つまり 本番だけを通る経路は、一度も実行していませんでした。実機を持っていないので、できる最大のことは、その経路をコードで洗うことだと考えました。結果、8 件見つかりました。全部、本番でしか起きないものでした。結論を先に書きます。開発環境が「都合よく」してくれているところを数え上げると、そこに欠陥が並んでいます。 バグを探すより、都合のよさを探すほうが速い。 60 秒で...

お久しぶりです。Hirotoshi Uchidaです。これはテスト投稿です。

!実際のプロダクト名・チーム名・PRの詳細は伏せていますが、体験自体は実務で起きたことをベースにしています。 はじめにこんにちは、修行中エンジニアのKomugiです。半年ほど前、受託案件で手動テストを担当する機会がありました。それをきっかけに、手動テストや自動テストに関心を持つようになり、最近、業務で実際にテストコードを書かせてもらえる機会を得ました。今回は、当時の自分の感覚のままPRを出したら、実務のレビュー密度に何度も突き返された話です。突き返されるたびに、「これは当時の自分だったら絶対に気づかず、そのまま見逃していただろう」という穴が見つかりました。何が見逃されていた...

はじめにソフトウェアテストを学び始めると、単体テスト、結合テスト、システムテスト、E2Eテスト、回帰テストなど、似た言葉が一度に出てきます。さらに、同値分割や境界値分析といったテスト技法、テストピラミッド、カバレッジ、CI/CDまで並ぶと、それぞれが何を表しているのか...

この教材についてJupyterの上で最適化モデルが動いて、良さそうな解が出た。ここまでは楽しい仕事です。問題はその先です。壊れたデータが毎朝流れ込み、ある日突然「解なし」が返り、現場からは「なぜ私のシフトはこうなの?」と問い合わせが来る。最適化の案件が死ぬのは、たいてい数学ではなく工学の側です。この連載では、PoCで動いた最適化モデルを本番システムとして動かし続けるための技術を扱います。テスト、データ検証、シミュレーションによる評価、API化、可観測性、説明責任、効果検証、そして保守。凡例: ✅ 公開済み / 📝 執筆予定 第1部 モデルを工学する編 1-1....

ドキュメントを書いていたら、テストの抜けが見つかったagent-cost という小さな OSS CLI を公開しています。Claude Code / Codex CLI のローカル利用ログを読み込み、トークンコストを見積もるツールです。このツールのドキュメントを整えながら、そこに書く主張をコードやテストと一つずつひも付けていました。その作業中に、回帰テストがないケースを2つ見つけました。どちらのコードも、すでに意図したとおりに動いていました。見つけたのは実装バグではなく、その挙動を将来の変更から守るテストの抜けです。2件とも実装には手を入れず、回帰テストだけを追加しました。き...

現在の最新版であるRanorex 12.7では、Ranorexの動作に必要なソフトウェア要件の一つである、Visual Studio Build Tools 2022および2026が新たにサポートされました。それにともな […]The post Visual Studio Build Tools 2022のインストール手順 first appeared on テスト自動化ツール 『Ranorex』.

冒頭の失敗告白私は Claude Code に npm test を一発で叩かせていました。100 回のうち完走したのは 28 回。3 コマンドに分けて順に叩かせたら、次の 100 回のうち 87 回完走したのです。同じリポジトリ、同じテスト、同じモデル。変えたのは「渡し方」だけでした。この記事はその測定と、明日から真似できる 3 ステップの導入手順の話です。 逆説命題AI に全部やらせるより、3 つに分けて渡す方が完走率も速度も上がる。直感に反するかもしれません。人間なら「まとめて全部やっといて」の方が指示は楽です。ところが LLM ハーネスでは、まとめて渡した瞬間に...

はじめに — 2人目QAを迎えるまでに何を用意したかこんにちは。株式会社ZENKIGEN QAエンジニアの横田です。普段はQAエンジニアとして、Webアプリケーションのテスト設計・実施・改善に取り組んでいます。今回は、1人目QAとして2人目のメンバーを迎えるまでに何を整備し、何が足りなかったかを振り返ります。私は2024年2月に「1人目QA」としてZENKIGENに入社しました。QA専任メンバーがゼロの組織で、品質管理の基盤をゼロから構築してきた経緯は、過去の記事でも触れてきました。「Claude Code」でバグ起票を自動化した話（2月）QAの守備範囲、広がりすぎ...

この記事の要点AIによる品質保証の流れには実装からテストまで含まれる。AI導入には効率向上のメリットがあるが、課題も存在する。適切な人材と教育が成功の鍵となる。はじめに近年、AI（人工知能）が私たちの日常のさまざまな業務に浸透していますが、特にソフトウェア開...

はじめに社内でTDD（テスト駆動開発）の勉強会を開催することになり、事前説明用の資料を作成していました。TDDの基本サイクルは次の3ステップです。Red（失敗するテストを書く）Green（最小限の実装でテストを通す）Refactor（コードを整理する）私自身、これまでTDDを実践する中で、特に疑問を持つことなくRedから始めていました。しかし、資料に「なぜ最初に失敗するテストを書くのか？」という説明を書こうとしたとき、ふと手が止まりました。わざわざ失敗させる理由を、自分の中で十分に言語化できていなかったのです。そこで、勉強会の準備や実際の演習を通して気付いたことを...

こんにちは！広報たがみです。社員旅行2026のレポート2日目を書いていきます！！1日目のレポートはこちら続きをみる

「カバレッジ100%」は追うな！単体テストで「本当に価値ある部分」を見極める実践戦略こんにちは！駆け出しエンジニアの皆さん、そしてベテラン開発者の皆さん。ソフトウェア開発において「単体テスト」は、コードの品質を保証し、未来の自分やチームメンバーを救うための強力な味方です...

🎯 はじめにAIエージェントにテストを書かせている。カバレッジも上がるし、速い。ただ、あるときから引っかかっている。テストは検証器だ。 AIが書いたコードが正しいかを判定するための仕組みを、同じAIに書かせているとしたら、それは自己採点ではないのか。この記事では、AIエージェントの実地調査を1本と、開発者の生産性を測ったRCTを1本、計2本の論文を読んだうえで、テストの委譲にどこで線を引くべきかを考える。結論を先に書くと、こうなる。テストの委譲は「何を確かめるか」が決まっているときだけ成立する。だから「この関数のテストを書いて」は委譲していい。「このモジュールをテストして」...

Over the past decade, many test adequacy metrics have been proposed for deep learning that characterize test dataset adequacy from different perspectives, e.g., neuron activation behavior, latent feature coverage, decision-boundary exploration, etc. However, these metrics are typically released as independent research prototypes with substantially different installation and preprocessing requirements, execution workflows, and configuration mechanisms. These complications make them quite difficul

大規模リファクタリングのテスト戦略では、既存のテストを増やす前に、変更する境界を決めます。入力の解釈、ユースケースの判断、依存方向、外部システムとの接続では、壊れ方が異なるためです。それぞれの失敗を検出できる場所へテストを置きます。ここでは、クリーンアーキテクチャへ移行したvscode-ajsbutlerを例にします。題材は VS Code 拡張ですが、扱うのは特定のフレームワークに依存しないテストの分け方です。コードを層と業務機能のどちらで分けるかは、Feature-firstとLayer-firstの使い分けで整理しています。ここでは、分けた境界をリファクタリング中にどう守るかへ...

コーディングエージェントは、ほとんどのタスクを同じ言葉で締めくくります。「完了しました。テストはすべて通っています。」本当のこともあります。ただ、6月の論文(arXiv 2606.09863)が測ったところ、自己採点した失敗ランのうち75.8%が、それでも成功を主張していました。同じ論文はLLMの審査員にこの嘘を見抜かせる実験もしていて、5モデル×5プロンプト戦略で最高AUROC 0.65、最低0.54。ほぼコイントスです。審査員は実際のマシンの状態ではなく、自信に満ちた締めの文体を読んでしまうからです。テストランナーは、失敗したスイートを1.0で検出します。だから、Stopフックを...

はじめにNode.js v26.6.0 のリリースノートを眺めていたら、Notable Changes が4件しかないのに、そのうち2件が test_runner でした。ひとつが context.log() と test:log イベントの追加（PR #64389）、もうひとつが TestStream イベントへの entryFile 追加（PR #64309）。しかも作者が同じ人です。t.log() は、テストの中から「このログはこのテストのものだ」という情報付きでメッセージを流せる API です。すでに console.log も t.diagnostic() もあるのに...

AIが書いた UPDATE を、人間が承認してから実行するライブラリを作っている。売りは一点だけで、承認画面に出る値は推測ではなく実測だという点だ。トランザクションの中で本当に実行して、実行前後の値をデータベースから読み直して、必ずロールバックする。人間はAIの説明ではなく、その実測値を見て承認する。公開翌日、そのライブラリが承認画面に出していない列を本番に書き込んでいたことが分かった。 実際の出力公開済みの 0.4.0 を npm install して動かしたもの。データは name='田中', postcode='00100'。 UPDATE customers SET...

はじめにRAG、チャットボット、エージェント。LLMを組み込んだアプリを作り始めると、必ずぶつかる壁があります。それは「この出力、本当に良いの?」という問いです。コードのテストなら、assert result == 4 のように正解が明確です。ところがLLMの出力は「だいたい合っている」「まあ悪くない」といった曖昧なものになりがちで、良し悪しの判定がとても難しくなります。そこで多くの人は目視でチェックします。しかし目視には大きな問題があります。再現性がない: 同じ出力でも、日によって「OK」と「NG」の判断がブレるスケールしない: 100件、1000件のケースを毎回人...

はじめに最近、AI Coding Agentを使った開発方法が大きく変わっています。以前は、人間↓コードを書く↓Testを書く↓Reviewするという流れでした。しかし現在は、人間↓Issue作成AI Agent↓実装↓Test追加人間↓Reviewという開発も現実的になっています。Claude CodeなどのAgentは、単純なコード補完ではなく、Repositoryを理解しながら複数ファイルを変更する開発支援ツールとして利用されています。ただし、ここで新しい問題があります。 AIがコードを書けるなら、誰がそのコードを確認...

再現できない状態は、レビューされないコーディングエージェントに一覧画面を作ってもらった後、レビューで最初に詰まるのはここでした。0件やエラーの画面を、どうやって出すのか。本番のAPIが正常に動いている環境では、エラー画面は出せません。データが入っているアカウントでは、初回0件も再現できません。結果として、正常データが入った画面だけを見て「問題なさそう」と判断することになります。よくあるのは、見た目が整った一覧を先に見て「ほぼ完成」と感じたあと、0件表示に切り替えた時点で修正箇所が一気に増える流れです。表のヘッダーだけが残り、その下に何もない画面が出てくる、という形になりま...

1. はじめに — 採点の物差しを変えてみる自分はQAエンジニアで、普段のテスト設計に生成AI（Claude）を使っています。これまでこの連載では、モデルの実力を「テスト観点がどこまで出るか」で測ってきました。固定の採点項目を用意して、10回走らせて、何回出たかを数える方式です。前回の Opus 5 測定もこの方式でした。ただ、測りながらずっと引っかかっていたことがあります。深い観点——仕様の矛盾や欠落の指摘——は、実務では観点リストの形ではなく、仕様作成者への質問の形で出てくるものです。実際、過去に人間の目で判定核を裁定したときも「到達しているが、実務上はバグ断定でなく質問の...

はじめに本記事では、AIを使った開発においてバグ発見の記録のために検討したログ設計について説明します。私は、ExcelなしでVBAを実行し、テストできるVBA言語の評価エンジン VBA Runner を開発し、公開しました。詳しい背景は、ExcelなしでVBAを実行できる環境を構築しAIでのVBA開発を促進する にも書いています。現在も、VBA言語仕様の完全互換を目指して、AIによる評価と修正を繰り返しながら日々トークンを消費しています。現在は主要な言語機能の実装が一通り完了し、残った仕様差やバグを調べています。そこで、AIにバグを発見させ、最小再現を作り、修正し、回帰テ...

Compiler optimizations are essential for achieving high performance in modern software. However, recent studies highlight the persistence of performance bugs, i.e., subtle defects where the compiler generates functionally correct but computationally inefficient code, leading to significant performance degradation. Existing detection and testing methods typically employ a bottom-up approach, focusing on specific low-level code properties and remaining confined to known optimization rules. Consequ

はじめに一般的に、QAエンジニアは、外部品質の改善に関わることが多い反面、内部品質の改善に関わることはあまりありません。しかし、外部品質の改善のみで、ソフトウェアの全体的な品質を担保していくのはとても難しいです。今回は、内部品質と外部品質について説明した後、内部品質と外部品質の関係性を説明し、QAエンジニアが内部品質の改善にアプローチできる方法をいくつか紹介していきます。 内部品質とは何か内部品質とは、ソフトウェア内部の作り込みの品質について指していて、ソースコードや仕様書の品質のほか、保守性や柔軟性、移植性、テストのしやすさなどが含まれています。この品質は、利用時の品...

はじめに一般的に、QAエンジニアは、外部品質の改善に関わることが多い反面、内部品質の改善に関わることはあまりありません。しかし、外部品質の改善のみで、ソフトウェアの全体的な品質を担保していくのはとても難しいです。今回は、内部品質と外部品質について説明した後、内部品質と外部品質の関係性を説明し、QAエンジニアが内部品質の改善にアプローチできる方法をいくつか紹介していきます。 内部品質とは何か内部品質とは、ソフトウェア内部の作り込みの品質について指していて、ソースコードや仕様書の品質のほか、保守性や柔軟性、移植性、テストのしやすさなどが含まれています。この品質は、利用時の品...

ナレッジワークでQAエンジニアをしている かとあず です。2026年7月24日、JaSST'26 Hokkaidoにて登壇してきました。現地で温かく迎えてくださった参加者のみなさま、素晴らしい場を作り上げてくださった実行委員のみなさま、本当にありがとうございました。北海道についたら、とりあえず！本記事では、私が今回発表のテーマとしてスキルマップ・スキルアセスメントを選んだ背景や当日の会場で得た気づき、これから現場で活かしていきたいことを記します。JaSST Hokkaidoランチはスープカレー。初対面の人ともわいわい！ 登壇の背景 自分にとっては「当たり前の日常」だ...

CIが全部greenになった、それだけで安心していませんかバグ修正のPRを出す。CIが全部greenになる。それを見て「直った」と判断してマージする——ここまでは自分も含め、多くの現場で当たり前にやっている流れで、疑ったことがある人はあまりいないと思う。だが少し意地悪く考えてみると、そのgreenは修正前に同じテストが赤かったことを確認した上でのgreenなのか、それとも修正後に一度実行しただけの「たまたま出たgreen」なのか、見た目ではまったく区別がつかない。CIやAIエージェントの自動修正ループのように、実行が速く何度でも回せる環境ほど、この区別を省略しても表面上は困らない...

今回は「AIに『レビューして』はもう古い？『敵対的検証』のすすめ」とい …

はじめに「AI コーディングで品質が落ちている」という調査結果が、この夏話題になりました。New Relic が 2026 年 7 月 30 日に発表した「The 2026 State of AI Coding Report」(米国の中堅・大企業の IT リーダー 200 人対象) は、AI がコードの過半を書くようになった現場で、本番障害が増えているという数字を並べています。この記事は、その調査への反論でも、AI コーディング擁護でもありません。私たち自身が AI を使ってソフトウェアを開発し、商用製品としてリリースしている当事者として、では、何を管理すればよいのかを実務の視点...