これはなにAIにコーディングを丸投げするなら、テストコードくらい確認しろという愚痴。 背景 | ただの愚痴私はここ1年ほど毎日のように、コードの構造や仕様をAIへ与え、それに基づいてテストケースを作らせている。もちろんコード自体も書かせている。そしてAIに書かせたコードをチームメンバーにレビューさせ、チームメンバーがAIに書かせたコードをレビューしている。まあこんなのはもはや、プログラマーにとっては日常だろう。だが、最近私はそれに困り悩まされている。自分が他人のコードを、とくにテストコードをレビューするとき、そもそも書かれたテスト自体まるで無意味なことが増えたからだ。たと...

こんにちは。小学生向けのニュースサイト、こどもニュースをつくっています。このサイトの E2E は、dev サーバではなくビルド成果物に対して回しています。デプロイするものと同じ静的 HTML を検証したいからです。正しい代わりに、毎回ビルドが走ります。pre-commit で回すには重すぎました。ソースを 1 文字も触っていないコミットでも待たされます。入力が変わっていなければビルドを省略する、という仕組みを入れた話です。 入力を決めるまず「何が変われば再ビルドが要るか」を列挙します。export const BUILD_INPUT_ROOTS = ['web', 'lib...

画像AIを比較するとき、「それっぽい画像が出たか」だけで判断してしまうことがあります。しかし、入力画像も指示文も毎回違う状態では、ツールの差なのか、条件の差なのか分かりません。そこでこの記事では、画像AIを比較するときに固定したい5つの条件を整理します。これはランキングを作るための方法ではありません。自分の用途に合うワークフローを、再現可能な形で選ぶための小さなテスト設計です。 1. 入力画像を固定する最初に、同じ元画像をすべてのテストで使います。解像度、縦横比、圧縮率まで変えません。人物写真なら、顔が見える・光が均一・背景が複雑すぎない画像を選びます。文字除去なら、単色背景...

はじめに前回の記事では、自分がこれまでシステム開発で考えてきたことを棚卸しし、その考え方を ARPCA という形で整理していたことを書きました。今回は、そのARPCAについてもう少し具体的に書いてみます。とはいえ、いきなり細かなルールを説明するつもりはありません。まず書いておきたいのは、ARPCAは何を解決しようとしていたのか。という部分です。昔の資料もいくつか載せながら振り返ってみます。細かな定義や言葉遣いは今なら変えると思うところもありますが、考え方の根っこは、今の自分がシステム開発で大事にしていることとかなりつながっています。 ARPCAは「仕事の曖昧さ」...

AI エージェントを使って、動物病院向けの電子カルテ・売上管理システムを一人で作っている。その過程で決めた「AI の出力をどう受け入れるか」のルールと、それによって実際に見つかった不具合 2 件を書く。 前提：AI が書いたコードは、レビューでは落ちないAI の出力はそれらしく仕上がる。命名も、構造も、コメントも整っている。だから読んで「おかしい」と気づける不具合は、そもそもあまり出てこない。危ないのはそこではなく、構造は正しいのに値が間違っているケースだ。これは目で追っても分からない。動かして、数字を突き合わせて初めて出る。業務システムだと、これが直接カネの計算に効く...

!この記事はAIと書きました。$ x=42$ expects "$x" to_be 10FAIL: expected {actual} to_be '10', but {actual} is '42'$ expects "$x" to_be 42 && echo PASSPASS$ expects "$x" not to_be 10 && echo PASSPASSbin/expects - aiya000/bash-toys はじめにシェルスクリプトでちょっとした検証を書いていて、こんな経験はありませんか？「[ "$...

2日のあいだに、何も検査していないのに緑だったテストを3件見つけた。どれもカバレッジには計上される。行は通っている。だがバグを戻しても赤くならない。さらに数日後、同じ形をもう1件踏んだ。合計4件、全部ちがう理由で空振りしていた。この記事は、その4つの形と、それぞれをどう捕まえるか。 大前提：カバレッジは「通った」しか言っていないdef test_発注できる(): place_order(Order("AAA", "BUY", 10, 100.0)) # 例外が出なければ通るこのテストは place_order を100%カバーする。そして何も検査していない。...

EAの変更前後を、同じ条件で比べられていますか。実験メモと決済済み取引CSVから、条件の不一致を検出し、差分と入力ハッシュを残す小さなPythonツールを作ります。標準ライブラリだけの完全コード、架空データ、15件のテストを掲載。MT5のHTML解析や売買ロジックは扱いません。最初の2章は無料です。

Webの現場では、同じ確認作業なのに名前が何種類も出てきます。英語では unit / integration / feature。日本語の工程では単体試験・結合試験・総合試験。会話が噛み合わないとき、原因の多くはこの呼び分けです。この記事では、フィーチャーテストが何かを押さえたうえで、4つの名前の違いを整理します。読み終わるころには、それぞれの違いを自分の言葉で説明できるようになるのがゴールです。想定読了時間は 5〜10 分です。 4つの名前は、同じものさしに並んでいない先に地図を出します。単体・結合・総合は「どこまで組み立てて見るか」という工程の名前です。フィーチャーテストは「...

この記事は、連載「読まない技術」の第 6 回です。各回はファイルやスクリプトを一つ置けば完結します。連載の全体像と各回の一覧は序論にあります。今回は、指示ファイルに書くルールの話です。守ってほしいことを書くのをやめて、代わりに何を置くかを扱います。まず一つだけ、確かめてみてください。あなたの指示ファイルに書いてある禁止事項を 1 つ選びます。開発のときに AI に許さないと決めたルールのことです。それが先月何回破られたか、答えられますか。答えられないのが普通です。AI に破られても何も起きないからです。ルールが効くには、AI に読まれる → 覚えられている → 従われる、の三つ...

こんにちは、AI師範です。普段はAIを組織のように使って、業務自動化ツールの製作と、その運用の引き継ぎ支援をしています。AIに実装を任せると、最後にこう返ってきます。テストは全件通過しました。問題ありません。たいていは本当です。ただ、この報告には構造的な弱点があります。実装したのもAI、テストを書いたのもAI、通ったと判断したのもAI。同じ相手が同じループの中で「終わった」と言っている。先月、うちの受け入れで実際にこうなりました。27件を全部チェックするはずの処理を、わざと「1件しか見ない」形に壊してみたんです。テストは27件すべて緑のままでした。全件を踏んでいることを確かめ...

テスト自動化を導入したが、メンテナンスが追いつかない、フレイキーなテストが増えてCI/CDが不安定になる——これらは自動化「する」決断より「どう設計するか」が問題であることが多い。本書は失敗事例から逆算してテスト自動化の設計を学ぶ実践書だ。「とりあえず自動化」が失敗する...

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

AI コーディングエージェントでは開発用テストと採用評価を分けるAI コーディングエージェントは、コードを書くだけでなく、リポジトリを読み、ファイルを編集し、テストを実行して失敗結果を次の修正へ利用できます。SWE-agent でも、エージェントがコードの編集、リポジト...

Claude Code に任せる範囲を広げていくと、どこかで「全部読んでレビューする」が破綻します。差分が大きいうえに、出力はいつも自然な日本語と動くコードだからです。読んで違和感が無いことと、正しいことは別物です。そこで方針を変えました。守らせたい不変条件を、文章ではなく機械に書く。CLAUDE.md（Claude Code がリポジトリごとに読む指示書）に「出典を必ず付けること」と書いても、守られるかは運です。テストに書けば守られます。落ちるので。題材は、僕が個人で運営しているフリーランスエージェントの比較サイトです。Next.js製で、いまテストが1,347個あります。この記...

!本記事は Anthropic 公式チャンネルの動画「How Spotify runs agents across 20M+ lines of code, with Niklas Gustavsson」（26:11）の紹介と論評を目的としています。翻訳の全文掲載はしておらず、要点を抽出したうえで筆者の見解を添えたものです。元動画の網羅でも代替でもありません。関心を持たれた方は必ず元動画をご覧ください。話し手は Niklas Gustavsson、Spotify の VP of Engineering です。社内のエージェント基盤「Honk」を率いています。Spotify のエンジニ...

!「テストが本当に効いているかを確かめるために、わざと実装を壊して赤になるか見る」── その確認のほうが偽の緑を出していた、という記録です。扱うのは変異テスト（ミューテーションテスト）を手作りで回したときの落とし穴だけで、専用のフレームワークの使い方は書きません。対象は Claude Code に書かせて運用している小さな自動化機構1本（n=1）です。 3行で言うと赤には少なくとも2種類ある。狙った不具合を捕まえた赤と、測定そのものが失敗した赤である手作りの変異テストは、後者を前者として数えていた。1時間のうちに2回、実際に踏んだ気づいたきっかけは所要時間だった。1件が ...

! この記事の要点判断・計算は純粋関数へ。DB・時刻の取得は外側へ。計算に渡すのは db や clock ではなく、取得済みの値。実装時の参照用に分類早見表とコード・テスト例。純粋関数のメリットは分かっていても、DB の参照や時刻の取得が挟まると、切り出す境界に迷います。 FCIS の境界は引数と戻り値注文の「明細を取得する → 送料込みの金額を計算する → 保存する」を考えます。取得と保存を外側に残し、計算だけを独立した関数に取り出します。矢印はデータの流れです。保存を呼ぶのは Shell で、Core は計算結果を返します。この分け方が F...

今日、自分のコードで緊急停止の2層目が丸ごと機能していないのを見つけた。呼び出す側は書いてあった。呼ばれる側のメソッドが存在しなかった。しかもドキュメントには「実地確認済み」と書いてあった。嘘ではない。接続を切って試して、期待どおりのエラーが出るのを確かめてある。メソッドが無い場合も、出力が一字一句同じだったというだけだ。この記事は、そういう「作ってあるが働いていない安全装置」を、わざと壊して確かめる話を、動くコードで書く。前回（「落ちない」は安全ではない）が「黙って間違う経路を塞ぐ」なら、今回は「塞いだものが本当に働くか」。 まず：なぜ「実地確認済み」が嘘になったの...

レイヤーごとに関心ごとは異なることを把握しようインタクラター層の最大の関心ごとは「ビジネスロジックの正確性・条件分岐・例外処理」だ。その上で、Springを起動させないピュアなJavaとしてテストが動作させることが絶対的な鉄則になる→さもなければ、数千ファイルであっても数秒で終わるという本来のインタラクターテストのメリットが逆にCI/CDのボトルネックになってしまうからだサンプルコードを見てみよう。外部APIなどのI/Oを伴う依存関係は全てモックして使う// Spring Bootのアノテーション(@SpringBootTestなど)は絶対に使わない🤯@ExtendWi...

自作の測定スクリプトに嘘をつかれた。エラーは出ていない。落ちてもいない。正しい形をした、間違った答えを返しただけだった。この記事は、そういう「黙って通る」壊れ方を5つの型に分けて、直し方と、それを捕まえるテストをセットで置いていく。直し方はどれも数行で済む。難しいのは直すことではなく、在ることに気づくほうなので、テストの書き方に重心を置く。 発端：語をひとつ替えたら、答えが100倍変わったYouTubeの検索需要を測るスクリプトを書いた。検索語を渡すと上位の再生数の中央値を返す。主観で発信ネタを選ばないための道具だ。最初に「Claude Code 失敗」で引いたら、上位...

4,893記事、反響11,420。集計スクリプトが出した数字です。合っていません。わたしが書いた記事は186本です。出力はこうでした。全4893記事 / 反響合計 11420zenn 4800本 反響11379 中央値 0.0 0本2809 上位1本の占有 7.2%qiita 93本 反響 41 中央値 0.0 0本 62 上位1本の占有 12.2% ストック 32Qiita の93本は合っています。Zenn の4,800本は、Zenn 全体です。dev.to は1行も出ていません。エラーは1つも出ていません。 同じ間違いに、3つの返り方があ...

はじめにこんにちは、りゅうです！今日は私が扱うプロダクトの機能のひとつとして音声（通話）をテキストに変換する「文字起こし」機能があります。この精度を継続的に改善していきたいという話が持ち上がったのですが、その時に改善を行なってもどう良くなったかが評価しずらいと感じていました。「モデルやパラメータをいじったら、精度が上がった 気がする」以上のことが言えない、というのが一番の問題です。いくつかのサンプルを目視で見比べて「なんか良くなったっぽいね」と判断する。この状態のまま改善を積み重ねても、本当に良くなっているのかは客観的にはよく分からないままです。むしろ、ある施策が別のケー...

実装をAIに任せると、出てくるものは驚くほどよく動きます。問題は、動いているのに目的が果たされていないときで、そこにはエラーが出ません。私はコードが読めないまま6つのサイトと1つの有料商品を公開して、索引から36ページを消し(データ3,449件ぶんの表示面)、公開直後2日間の記録を永久に失い、誰も来ていないサイトに年18,700円の課金を走らせ、内部ファイル10種を本番URLで半日公開しました。どれもエラーは出ていません。画面も壊れていません。全部「動いて」いました。この本は、コードを一行も読まずにそれを見つける検査の手順書です。検収を5つの問い(動いたか/正しいか/壊れないか/出してよいか/引き継げるか)に割り、各検査に所要時間と、実際に起きた事故の日付と数字を付けました。最終章に、そのままコピーして使える15分版・30分版・60分版のチェックリスト(全18項目)を全文置いています。すべての項目に (a)公開されている一次資料で裏が取れたもの /(b)自分で試して結果が出たもの / (c)試して効かなかったもの のラベルを付け、ラベルの付かないものは書いていません。見ていない数字は「

はじめに今回は、誤用しやすいエラー、欠陥、故障の違いや関係性と、根本原因に関して、私自身も誤用しやすいため、JSTQBに準拠した備忘録としてまとめてみました。正しい意味で用語を理解し、使うことは、コミュニケーションの疎通をスムーズに進める上でとても大切です。 エラーとはJSTQBシラバスでは、下記のように記載されています。人間はエラー（誤り）を起こす。そのエラーが、欠陥（フォールト、バグ）を生み出し、その欠陥は、故障につながることもある。人間は、時間的なプレッシャー、作業成果物、プロセス、インフラ、相互作用の複雑度、あるいは単に疲れていたり、十分なトレーニングを受けてい...

こんにちは、こまさ(KMSLAB)です。今回は、テストについて、私がいつも言っていることを書いてみます。 テストは何のためにあるのかみなさんは、ソフトウエアのテストを何のために実施していますか。バグを見つけるため、動作を確認するため、ソフトウエアの品質を上げるため。場合によっては、納品に必要だから、というのもあるかもしれません。現実的には、まさにその通りだと思います。テストを実施して、問題を見つけて、問題処理票を書いて、不具合を直して。そして、増える一方の問題処理票と格闘する日々。振り返ってみると、あまり建設的ではありません。私も昔はテストで問題を発見することに励んでいました...

はじめにこんにちは！jinjerプロダクト開発部 SEの関根です。今年1月に双子の弟に誘われてjinjer株式会社に入社しました。今回は、開発未経験からSE（システムエンジニア）としてスタートし、前職のQA/QC（品質保証・品質管理）で培った視点を活かすことで、設計段階での手戻りを減らし、スムーズに設計書を作成できるようになったプロセスについて書いていきます。結論からお伝えすると、QA/QCの経験は単なる「テスト工程の知識」ではなく、「要件・設計段階から不具合を防ぎ、品質を作り込むための大きな武器」になります。 プロダクト設計の難しさと、最初にぶつかった壁SEとしてキ...

[特定非営利活動法人ソフトウェアテスト技術振興協会][画像1: https://prtimes.jp/i/54604/58/resize/d54604-58-4ed08eff5524fb1f8ba9-0.png ]JSTQB（ソフトウェアテスト技術者資格認定組織）は、2026年10月16日（金）に開催する無料オンラインイベント「JSTQB カン...

こんにちは、Platform Engineering部 QAの池上です。GENDAではMagicPodを使ったE2Eテスト自動化を複数のプロダクトで運用しています。私はその中で、バッチ実行の結果確認やテスト環境の整備といったテスト自動化関連の業務を主に担当しています。GENDAでは自動テストのツールとしてMagicPodを採用しています。GENDAはM&Aによって取り扱うプロダクトの種類・数が時間とともに増えていく組織で、QA以外の職種のメンバーも含めて誰でも自動テストを実装できる体制を作りたいという狙いがありました。そのため、ノーコードツールであること、また社内で使われている...

概要 執筆の意図ユーザーストーリーという体裁で提出された要望が、実態としてはエピック相当の大きさだった事例に遭遇したこの事例を構造的に分析すると、ウォーターフォールとアジャイルの成果物対応があいまいなまま運用されていることが根本原因だと考えた本記事では、両手法の成果物・粒度がどう対応するかという静的な構造マッピングを整理する実際に要望がどのタイミングでチケット化されるかという動的なフローについては、続編のフロー編で扱う移行手順（Stage設計）や、要望の原因分解・判定フローの詳細設計は本記事のスコープ外とし、別記事で扱う 要約ウォーターフォールは粒度ごとに独...

概要 執筆の意図前回の構造編では、ウォーターフォールとアジャイルの成果物が粒度としてどう対応するかという静的な構造を整理したしかし冒頭で紹介した事例で実際に起きたのは、この静的な対応関係が崩れたことではなかった要望というインプットが本来通るべき精査の工程を経ないまま、いきなり大きな受け皿であるストーリーに流し込まれたことが問題だった本記事では、要望が実際にどのタイミング、どのルートでチケット化されるかという動的なフローを整理する要望の原因分解・判定フローの詳細設計や、移行手順（Stage設計）は本記事のスコープ外とし、別記事で扱う 要約現場の要望がチケットに...

同じリリースを数えて、478件と497件自治体向けの業務システムを作っていて、私はそのQAをしています。数か月ごとにメジャーリリースがあり、そのリリースに何が入るのかを、バックログの課題を数えて確認しています。リリース時期ごとにリリースブランチを切っているので、マージ先を間違えると、入るはずのものが漏れたり、まだ完成していないものが出ていったりします。数えているのは、それを防ぐためです。ある日、2つの作業スレッドが、同じリリースについて別の件数を報告しました。片方が478件、片方が497件。同じ課題管理ツールから、同じ日に、同じリリースの課題を数えたはずのものです。どちらもエ...

はじめまして！勤怠管理・給与計算ユニットでQAE（QAエンジニア）をしているjuniです。2026年5月にSmartHRへ入社し、給与計算プロダクトの品質保証を担当しています。 入社から3ヶ月が経ち、気づけば4ヶ月目に入っています。この記事では、最初の3ヶ月でやってきたことと、これから注力していくことを紹介します。立ち上がり方は担当プロダクトや状況によってさまざまだと思いますが、一つの例として、SmartHRの品質保証に興味がある方に、入社後にどう立ち上がり、その先で何に取り組もうとしているのかを知ってもらえたら嬉しいです。 これまでの経歴 前職までの経歴を簡単にご紹介します。 1社目：SIe…

最近やっていることといえば、いま世界中のQAエンジニアが取り組んでいるであろうところの「AIにテスト活動をやらせるためのSkills開発」である。この作業、内実は品質保証プロセスの管理そのものであり、QAエンジニアとしてこれまでやってきたことと何一つ変わっていない。しかし、そのプロセスを実施する主体が人からAIに変わると、こうも見え方が違うのか、と強く思う。つまり、AIに読ませる自然言語で書かれた指示書──Agent Skillsという概念──が、めちゃめちゃに面白いのだ。より正確に言うなら、Skillsを複数組み合わせてシステムを作るというこの作業が、本当に面白い……。続きをみる

QAエンジニアのつーつーです😁まだまだ暑い日が続きますね。この夏はサウナと開発でだいたい終わりました🧖‍♂️前回、「知見は、なぜ共有されにくいのか」という話を書きました。知識を持っていることと、その知識が世の中で活きることの間には溝がある。その溝を埋めたくてWeProcessを作っている、という話です。書き終えてから、ずっと引っかかっていたことがあります。「知見を流通させたい」と言っておきながら、自分のサービスは、中身を見るのに会員登録が必要な状態でした。これはさすがに、筋が通らないよな…と😥なので、全部開けることにしました。続きをみる

最近、開発の現場では 「まずAIに任せてみよう」という空気 がかなり強くなってきました。コードを書く。既存のコードを調べる。テストを書く。レビューする。障害の原因を調べる。ドキュメントを書く。少し前まで人が時間をかけていた作業のかなりの部分を、AIが手伝え...

「だいたい○○ケースくらいですかね」の正体テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。これで困るのは3つの場面。初めての領域。 過去実績がないから「だいたい」が通用しない説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない精度のばらつき。 見積もる人によって2〜3倍の差が出る結局、見積もりの「勘と経験」の中身を分解してみたら、ちゃんと数式...

はじめに 前回の記事では、分類学という一見するとソフトウェア開発やQAとは遠い学問を手がかりに、「抽象化とは、複数の具体から共通する本質を抜き出し、名前を与えることだ」という話を書きました。 クジラとカバが近縁であること...The post 【第3回】『具体と抽象』から見る、デザインと直感 first appeared on Sqripts.