はじめに続きをみる

今回はまずよしたけのXP祭り現地参加レポート。ずっとオンライン参加だっ …

多くのエンジニアが経験する「なぜか本番環境でだけ発生するバグ」や「テストでは見つけられなかったエッジケース」に、頭を抱えたことはありませんか？ 従来の例ベースのテストだけでは、開発者が想定しうるシナリオしかカバーできず、思わぬ入力パターンによって潜在的なバグが露呈することが...

!この記事のサンプルコードは以下のリポジトリにあります。https://github.com/st-man-hori/laravel-multiple-databases はじめにマルチテナントや外部システム連携などで、1つのLaravelアプリケーションが複数のDB接続を持つ構成になることがあると思います。こうした構成では、DB接続ごとに独立したmigrationディレクトリを持たせる方法がありますが、php artisan migrateはデフォルトでは接続を1つずつ順番にマイグレーションします。接続数が増えたり、1つ1つのマイグレーションが重かったりすると、この「直列...

最近、テストを開発するプロセスの一連の流れを再確認する必要があり、2026年の5月に自分が話した、テスト設計チュートリアルの動画を聞き直しました。（AIエージェントのナレッジにこういうプロセスの定義をちゃんと追加した方が良いと思ったのでやってます） 続きをみる

自分用のメモですAPI のテストフォルダを開くと、conftest.py と test_*.py が並んでいます。フィーチャーテストという言葉は聞いたことがあっても、いま見ているファイルが何のスタックの上で、何を書いて、何を通しているのかが先に揃っていないと、後半の fixture や yield が浮きます。この記事では、よくある API プロジェクトを架空の構成で置いたあと、フィーチャーテストの位置づけを整理し、pytest がそれをどう実行するかを人に渡せる粒度まで落とします。コードはすべて架空です。想定読了時間は 10〜15 分です。 前提：スタック、構成、書いている...

アンチパターンと本番障害は表裏一体結論から言うと、コードレビューで指摘される項目のほとんどは「可読性」や「お作法」の話ではありません。「これを放置すると本番でオンコールが鳴る」という話です。レビューを受ける側になると、指摘が細かく感じる瞬間がある。「動いてるのに何がダメなんだ」と。その感覚は、指摘の先にある障害シナリオが見えていないだけ、というケースがほとんど。逆に言えば、シナリオが見えていれば指摘は納得できるし、次からは自分で気づけるようになる。ここで挙げる5つは、私がこれまで中規模（数百ユーザー）環境で実際にオンコール対応やデバッグで踏み抜いたものに絞っています。一般的なア...

はじめにJestは、JavaScript向けのテストフレームワークです。テストの実行、結果の比較、モック、カバレッジ計測など、単体テストに必要な機能がまとまっています。この記事では、Jestを初めて使う人に向けて、次の内容を順番に解説します。Jestの導入と最初のテストよく使うマッチャーテストの整理と前後処理例外、非同期処理のテストモック関数の使い方カバレッジの確認方法テストを書くときの考え方サンプルはNode.jsとnpmがインストール済みの環境を前提とし、設定の少ないCommonJS形式で記述します。 JestとはJestでは、テストコードを次のよう...

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

一覧でAを選び、すぐにBへ切り替える。Bの情報が表示されたあと、遅れて届いたAの応答が画面を上書きする。通信そのものは成功していても、利用者は間違った対象の情報を見ることになります。残高や履歴を見せるWeb3のUIでも、一般的な検索画面でも起こり得る問題です。本稿ではネットワークを使わず、応答順序を手動で逆転させるテストで、対策の中心となる考え方を確かめます。 「最後に開始した操作」だけに表示を許可する表示の権利を応答の到着順に渡さず、リクエストを開始するときに番号を付けます。結果を反映する直前に、まだ最新の番号かを確認します。次のコードをlatest.mjsへ保存してください...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。bug Issueについて素敵な内容が書かれていたため、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3自分のためではなく、チームのためのbug Issueだったのでまとめます。また、自分の経験も併せて記載します。 🌱 結論bug Issueには、下記の要素があると良いと思います。!事象再現率再現手順実際の結果期待する結果環境情報ユーザー影響添付資料タイ...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。bug Issueについて素敵な内容が書かれていたため、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3自分のためではなく、チームのためのbug Issueだったのでまとめます。また、自分の経験も併せて記載します。 🌱 結論bug Issueには、下記の要素があると良いと思います。!事象再現率再現手順実際の結果期待する結果環境情報ユーザー影響添付資料タイ...

AIに頼めば、コードは出てくる。しかも速い。人間がコーヒーを一口飲んでいる間に、AIはいくつもファイルと関数を増やし、頼んでいない抽象化まで済ませている。問題は、そのコードが正しいかどうかである。画面が表示された。エラーが出ない。AIも「実装が完了しました」と言っている。しかし、「動いた」は「正しい」と同じではない。何をもって正しいとするのか。その基準がなければ、AIはゴールの位置を知らないまま、ものすごい勢いでシュートを打ち続ける。入ったかどうかを判定する人はいない。得点板もない。それでもAIは爽やかに報告する。「正常に実装できました」何を見て言ったんだい...？...

このプロジェクトで一番長く戦ったのは、機能追加ではなく 「同じテンプレートから、ブラウザのプレビューとサーバの PDF が別のものを出す」 という問題でした。対応した Issue は 40 件を超え、7 月 16 日から 7 月 23 日まで断続的に続いています。今回はその 8 日間の記録です。 1. 24 要素中 18 種が、無警告で空だったこの Epic は、7 月 16 日の朝 5 時に打った 1 行から始まっています。この配下のコードをレビューし、レポートをデザインし、帳票を出力するエンジンを作るための Issue を作成してください。返ってきたのが Epi...

はじめに一件の不正payloadでconsumerが毎回停止すると、その後ろにある正常な仕事まで処理できません。例外を握りつぶしてskipすると、今度は失敗した一件が消えます。Dead Letter Queue（DLQ）はこの二択を避け、処理不能なitemを証拠付きで隔離する仕組みです。ただし、DLQへ移しただけでは復旧していません。なぜ失敗したか、再投入できる条件は何か、元の順序を守る必要があるか、重複をどう防ぐか、成功を何で確認するかまで契約化する必要があります。この記事ではPythonのqueue worker、dead letter schema、dependenc...

はじめに以前、テスト用のダミーファイルをブラウザだけで生成できるツールを作った話を書きましたが、今回はそこに新しく「住所」タブを追加しました。フォームやDBのテストをしていると、住所欄に何を入れるか地味に悩みませんか？ 実在の住所を使うのは気が引けるし、かといって適当な文字列だとバリデーションに引っかかることもある。「それっぽい形式だけど、絶対に実在しない住所」を、まとめて欲しい時に使えるツールを作りました。https://www.testfilemaker.com/ できること都道府県は実在のものを使用します(フォームの都道府県プルダウンのテストなどにも対応できるよ...

AIに書かせたコードは、たいてい一度は動きます。問題は、その一度が「たまたま」だったときに気づけないことです。読んで探そうとすると時間がかかるうえ、短くて素直なコードほど問題が見えません。この記事では、コードを読まずに、動かすだけで済む6項目を出します。実際に集計ツールを1本作らせて当ててみたところ、6項目のうち4項目で問題が出ました。その出力もそのまま載せます。所要は15分です。 6項目#確かめることやり方1普通に動くか想定どおりの入力で動かし、出てきた数字を目で見る22回目同じコマンドをもう一度動かす3空0件・空のファイルを渡...

TL;DRCursor Projects の「数千の subagent」を、並列数ではなくジョブ整合性の問題として読みました。idempotency key、lease token、attempt budget の 3 つで、二重取得と古い結果の上書きを防ぎます。Node.js v24.19.0 で異常系を 5 件実行し、すべて pass しました。 はじめに数千のエージェントを動かせても、一つの古い結果が後から戻れば、リポジトリは壊れます。2026 年 9 月 10 日に発表された Cursor Projects の coordinator と subagent...

Go Conference 2026 自己紹介金子達哉 / catatsuy株式会社PR TIMES CTO『達人が教えるWebパフォーマンスチューニング』共著者Podcast「八百万のOSS」のホスト色々なOSSの設計・実装・運用を深掘りしているhttps://yaoyorozu-oss.henteko07.com/ notify_slackhttps://github.com/catatsuy/notify_slackcommandの出力を標準入力から受け取るCLIterminalにはそのまま出力Slackには一定時間ごとにまとめ...

対象読者は、TypeScript／JavaScriptのWebアプリ・Node.js APIでCIを運用し、テストの合否やカバレッジに加えて、改善対象を判断する指標が欲しい開発者である。GitHub ActionsとVitestを使う構成を実測の前提にする。2026年9月時点のツールについて、文・分岐網羅率、テストの検出力、変更が集中するコードの分析を扱う。API仕様の検証にはOpenAPIを前提とするSchemathesis、結果の可視化にはJUnitを入力とするAllureなどを取り上げる。API検証と結果集約は、対象アプリの実装言語とは別の軸である。 TDDが決めること、決め...

どうも、iinonです。株式会社ナレッジワークでQAエンジニアをしています。今回は、私が担当しているプロダクト『AI営業ロープレ』でLLMを使った機能のテストをした際にまとめた社内向けDevelopers Notesを元に記事を書いてみました。 要約LLMによる発音ガイドの抽出処理をどうテストするか悩んだので、Claude Code にテストデータの設計を依頼したClaude Code から Must / Should / Must Not の3分類による評価アプローチを提案されたので、採用した結果として、LLMの分類・抽出・フィルタ系の処理をテストするなら、Must No...

こんにちは！株式会社 Aldagramで業務委託QAをしている宮下です！前回は、Claude Code 上で QA プロセスを回す AI エージェント「qa-orchestrator」を作った話を書きました。https://zenn.dev/aldagram_tech/articles/4aea4b13671ae3今回はその続きになります。qa-orchestrator を運用してみて、いちばん気になっていたのが「仕様書に書かれていない振る舞いの観点が抜ける」ことでした。これに対して、テスト観点カタログという仕組みを考え少しずつ運用を始めているので、何を考えてどう作ったか、そして...

こんにちは！株式会社 Aldagramで業務委託QAをしている宮下です！前回は、Claude Code 上で QA プロセスを回す AI エージェント「qa-orchestrator」を作った話を書きました。https://zenn.dev/aldagram_tech/articles/4aea4b13671ae3今回はその続きになります。qa-orchestrator を運用してみて、いちばん気になっていたのが「仕様書に書かれていない振る舞いの観点が抜ける」ことでした。これに対して、テスト観点カタログという仕組みを考え少しずつ運用を始めているので、何を考えてどう作ったか、そして...

この記事でわかること「わざと壊して確かめた」検知でも、その後で静かに死ぬこと。同じ日に4件見つかった実例壊れ方は4つの型に分かれる: 正規表現の置き去り / 判定の複製 / 固定文字列の状態 / 本番環境の依存欠如それぞれ「症状 → なぜ気づけなかったか → 検知できる設計」個別に直すのではなく、各検査が「最後に成功データを返した日時」を横断で見る監査に落とすまで 前提個人ブログの運用を Claude Code と Codex を組み合わせた自作パイプラインで半自動化しています。launchd の定期ジョブと Python スクリプトの集まりで、大した技術は使ってい...

第 4 回（末尾に連載の一覧があります）前回、証明が空洞でないことを確かめる手段としてミューテーションを置きました。実装だけを壊して、証明が落ちるかを見る。落ちれば、その証明は何かを守っています。今回は、そのミューテーション自体が空虚になった話です。しかも同じ形で複数回踏みました。 発端: 自己検証したつもりだった既存 DB を壊さずに列を追加してよいかを判定する述語を書いたときのことです。実装役は、自分の証明が空洞でないことを示すために 3 つの変異を当てて、3 つとも CAUGHT であることを確認しました。off-by-one を入れる矛盾チェックを外すオーバ...

「まだ確認できていません」と「確認したら動きませんでした」。どちらも完了ではありませんが、次に頼む仕事は違います。前者に必要なのは確認です。後者には、失敗した箇所の修正を頼みます。この二つを同じ「確認待ち」に入れると、直す必要があるものに、もう一度確認だけを頼んでしまいます。AIに開発を任せるときも、ここを分けておくと依頼が短くなるはずです。大きな管理システムの話ではありません。完了報告に、結果を一行足すところから始められます。 作業が終わったことと、要求を満たしたことたとえば、CSVを読み込んで集計する小さなツールを頼んだとします。以下は説明用の架空の例です。担当から「実装...

はじめに「TDD って、全部ユニットテストを先に書くやつでしょ」そう覚えている人、多いです。半分だけ合っています。TDD（テスト駆動開発）の核はこれです。失敗する例を先に書く。通す。整える。ここは今も生きています。古くなったのは「それを全部ユニットテストで回す」ほうです。形のチェックは、型と LSP が持っていきました。 TDD が本当にやりたかったことRed-Green-Refactor は3手です。Red: 欲しい振る舞いの、失敗する例を書くGreen: それを通す最小の実装を書くRefactor: 例が通ったまま、形を整えるテストの山を積むのが目的じゃ...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。AIのQA（品質保証）に関する記述もあったため、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3最近は、AIを組み込んだシステムも多くなりました。AIの品質をどのような観点で担保すればよいかを、重点的にまとめます。説明が具体的になるよう社内ヘルプデスクAI（社内規程や手続きの問い合わせに回答する社内向けチャット）を題材にします。!各観点の引用は、すべて本書からの抜粋です...

🌱 はじめに2026年8月27日に発売された『QAエンジニア入門 〜チームで品質を高める連携のしかた』（岩崎 駿 著）を読みました。AIのQA（品質保証）に関する記述もあったため、備忘録として残します。https://gihyo.jp/book/2026/978-4-297-15832-3最近は、AIを組み込んだシステムも多くなりました。AIの品質をどのような観点で担保すればよいかを、重点的にまとめます。説明が具体的になるよう社内ヘルプデスクAI（社内規程や手続きの問い合わせに回答する社内向けチャット）を題材にします。!各観点の引用は、すべて本書からの抜粋です...

AIに仕事を奪われかねない Webフロントエンドエンジニアです。最近、QAに協力を仰がなくなる傾向が強くなってきました。理由は、AIに任せた方が速いから です。XCode Simulator や、Android Visual Device、そしてそれらをCLI的に操作できるインタフェース(WebDriverIO) を利用した「QAのAI化」によって、開発体験が強烈に圧縮しましたので、何が起こったか・ツールをどう使っているか・アウトカムがどうなったかを残そうと思います。 QAのしんどさと限界1つのWebフロントエンドのソフトウェアが、複数のOS及びブラウザで動くことを保証するのは...

※本記事は、RanoreXPathに関する基礎知識をお持ちの方向けの内容となります。※Ranorex ハンズオンセミナーを受講することで、RanoreXPathについて学習いただけます。 ブラウザー/Window OS/ […]The post 変更に強いRanoreXPathの設計方法 first appeared on テスト自動化ツール 『Ranorex』.

こんにちは、MagicPodメンバーのIkariです。目次 -->目次パネルディスカッションパネリストSammy さん｜株式会社Voicy EM/QAリーダモデレーター伊藤 由貴 ｜ 株式会社MagicPod エバンジェリスト 1. VoicyにおけるQA体制とMagicPod活用背景まずは、VoicyにおけるQA体制やMagicPod導入の背景についてお聞きしました。音声プラットフォーム「Voicy」は、発信者向けの「収録アプリ」とリスナー向けの「再生アプリ」を展開しており、開発組織約10名に対してQAはSammyさんを含む社員2名＋外部パートナーという体制で臨んでいるそうです。Sammyさんご自身も、企画（PRD）レビューからテスト計画・実行、EM業務まで幅広く担当されています。2. 再生アプリでの挑戦：3軸評価と「フレーキー化」の壁成功率38%からのスタート続いて、最初に自動化に着手された「再生アプリ」での試行錯誤について伺いました。当初評価軸としたのは「ビジネスインパクト大」「手動コスト高」「自動化コスト低〜中」の3軸。まずはクレジットカード決済を含む重要シナリオから、自...

こんにちは。SmartHRでプロダクトエンジニアをしているdelhi09です。私が所属するチームは「基本機能」と呼ばれるSmartHR最大のRailsアプリケーションの開発に携わっています。 私たちのチームでは2026年前期の約半年間にわたり、本業のフィーチャー開発の傍らで結合テストへのAI活用の検証を進めてきました。本記事はその試行錯誤の総括と知見の共有です。 前置きしておくと、AIを活用したことで結合テストが速く楽になりましたというような成功談ではありません。むしろうまくいかなかった話のほうが多いです。しかし、うまくいかなかった話を共有することで、読んでいただいた皆さんにとって、結合テスト…

前回はLocatorの話でした。ほぼPlaywrightの規約に基づいた説明でしたが、「変更に強い落ちにくいテスト」の準備でした、言ってみれば「入口の安定化」です。今回はそれに続いて「出口の安定化」を書きます。AIに書かせていると不都合な実装を度々編み出してきます。FailしているのにPassと判定する（通称偽陰性・偽陽性）などはよく見る事例で、Playwrightの仕様の都合だけでなく、AIの行う抜け穴回避や、その結果生まれてくる「有効ではないテストの発生」をどう減らしていくかはテストの安定性信頼性確保に重要な課題となってきます。Structured Playwrightでは、S...

こんにちは！satto workspace で E2E テストを担当している坂本友哉です。前回、中井が書いた Maestro 記事 の最後で、「QA を開発サイクルに組み込む話、テストを自動更新し続ける仕組み（ループエンジニアリング）、AI テスターの育成、Claude in Chrome での手動テスト実行など、E2E チームから順次発信予定です」とお伝えしました。今回はその中の**「AI テスターの育成」に関わる話で、実際に使ってみた結果は別メンバーが書く予定なので、今回は「土台をどう作ったか」**に絞ってお伝えします。 ✅ 今回お伝えしたいことE2E テストが全部 Pas...

こんにちは、MagicPodメンバーのIkariです。目次 -->目次セッション1：バグ削減と開発時間短縮を実現するAIコードレビュー（CodeRabbit 中津川篤司さん）トップバッターは、CodeRabbitでデベロッパーアドボケイトを務める中津川篤司さんです（一般社団法人DevRel代表理事も務めていらっしゃるそうです）。CodeRabbitはシート単位の定額課金でAIコードレビューを提供するサービスで、OSSやパブリックリポジトリであれば無料で利用できるとのこと。従業員は270名ほど、うちエンジニアが約100名、日本法人はなくほぼフルリモートという組織体制も紹介いただきました。レビュー開始までの待ち時間：レビュアーの空き時間までPRが確認されない、特定のレビュアーへ依頼が集中する、開発者が前の作業内容を忘れた頃に指摘が返ってくるレビュー内容のばらつき：レビュアーの経験や得意分野によって指摘が変わる、忙しさによって確認の深さが変わるレビュー作業の負担：変更内容の理解自体に時間がかかる、命名や例外処理など反復的な確認に時間を取られ、設計や業務仕様の確認に時間を割けなくなる開発...