はじめにCodens では Purple という orchestrator が「develop step」を回して実装させ、その出力を Blue が受けて E2E テストを書く、という多段の agent 構成にしている。これがそこそこ動いてはいたのだが、ずっと違和感があった。Blue が生成してくる E2E が「Purple がさっき変えた箇所」にぴったり寄ってこなくて、機能ベース、画面ベースで広く撒いてしまう。Blue が「何を変えたか」を知らないから、当然と言えば当然だった。最初は Blue 側の prompt を強めればいいかと思って色々試したのだが、根本解決にはならなくて...

はじめにユニットテストも結合テストも書き、境界値分析や同値分割の基本も押さえている。それでも本番ではバグが出る ── そういう経験は自分も繰り返してきました。後から見るとバグは偏っていて、「特定機種でだけ落ちる」「特定の地域で文字化け」「ピーク時に遅延」「AIが想定...

QAエンジニアのつーつーです😁思い立ってから実現させるまでに気が付けば3年が経ちました。（長いような短いような…）今回は、私が今まで感じていたモヤモヤ、「世の中の不合理で不条理な仕組み」に対して、手を打つことができないか？という思いを実現させるために作ったサービスの話をします。皆さんも感じていると思いますので、読んでいただけると嬉しいです😊続きをみる

はじめにこの記事では、テストデータを効率良く作る方法として、SQL で管理するやり方を整理します。結論を先に書くと、手動検証やバッチ検証では、テストデータ作成を SQL に寄せた方が扱いやすいことが多いです。特に次のような場面を対象にしています。バッチの手動検証をしたい既存データを消して毎回同じ状態を作りたい複数テーブルにまたがる前提データをまとめて用意したい新規テーブルの検証なので、テーブル作成から入れたいテストデータ作成の方法はいくつかあります。管理画面から手で登録するアプリの Seeder を使うテストコード内でデータを作るSQL を直接流すど...

はじめにQAエンジニアとして、毎日こんな作業に時間を取られていませんか？要件書を読んでテストケースを一から手動で書くカバレッジが足りているか手動でレビューするバグレポートの書き直しが何度も発生するChatGPT / Claude を正しいプロンプトで使えば、...

はじめに「テストはたくさん書いている。カバレッジも80%を超えている。なのにリリースしたらバグが出る」——そんな経験はありませんか？自分も最初は、ケースを増やせば品質が上がると思っていました。けれど、ひたすらケースを足しても欠陥が漏れ続ける。原因はシンプルで、テ...

はじめにこんにちは。ビジネス映像メディア「PIVOT」で、QAエンジニア兼PMをしている ケイスケ です。PIVOTのモバイルアプリ（iOS / Android）では、以前はノーコード型のSaaS自動テストツールを使ってE2Eテストを運用していました。しかし2025年後半、そのツールから Maestro というオープンソースのE2Eテストフレームワークに全面移行しました。この記事では、なぜ移行を決めたのか、ローカル実行のツールの中でなぜMaestroを選んだのか、そして移行してみてどうだったかを紹介します。!Maestroでの具体的なテスト基盤の構築方法（メール認証の自動化...

WACATE 2026 夏の開催概要を公開しました！https://wacate.jp/workshops/2026summer/今回は「テスト千本ノック！」です。みなさんにはテスト技法を駆使する問題をたくさん解いてもら続きを読む投稿 WACATE 2026 夏 開催概要・招待講演者を公開し、募集を開始しました！ は WACATE に最初に表示されました。

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

はじめにAI agent(うちでは Claude Code)に「このチケットを実装しろ」と渡すと、たまに「動いた、commit した、push した」までは進むのに チケットの半分しか触ってない ことがある。テストファイルだけ書いて実装ファイルがない、とか、実装はしたがマイグレーションが抜けてる、とか。exit_code は 0、commit もある、PR も開ける。下流から見ると成功にしか見えない。この「形式上は完了、内容は未達」をどう検出するかという問題に、自分は半年かけて 2 回設計を変えた。最初は agent が出した diff の形を見て、チケット本文に書かれてるファイ...

Traditional approaches to test case generation often involve manual effort and incur significant computational overhead. Additionally, these approaches are not scalable, and hence, unsuitable for complex software systems. Recently, Large Language Models (LLMs) have been applied to software testing. However, single-shot prompt engineering-based approaches tend to hallucinate and generate redundant test cases, resulting in fewer branches. To handle the above-mentioned limitations, in this paper, w

はじめに本記事は、テストコードとAIをめぐるシリーズの9本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはテストピラミッド。Mike Cohn が提唱したことで知られる「ユニットを多く、統合を中ぐらい、E2Eを少なく」という階層構造の話です。本記事ではこの古典的な議論に、近年のフロントエンド系で言及されている派生(アイスクリームコーン型、テスティングトロフィー)を重ねながら、自分の現場のテスト戦略を見直すための視座を整理してみます。書き手の現場ではいま、ユニットテストはそれなりに書かれていますが、E2Eは未整備のまま、QAメンバーが手動の...

はじめにこんにちは！りゅうです！2026年4月22日~24日に行われたRubyKaigi2026に参加させていただきました！その内容を簡単にまとめようと思います！別途一番刺さったセッションについては別記事でより深掘りする予定です。本記事では、以下の内容を書かせていただきます。私が聴講させていただいたセッション・ひとことメモセッションの中で印象に残ったものをいくつか紹介Drink UpやAfter Eventの様子購入した本知らなかった・学んだことここが初参加の人には参考になるかも！今年のRubyKaigiの雰囲気をお伝えして、次に参加しようと考えている...

最近、Zenn で AI を使った E2E テスト自動化に関する記事をいくつか読みました。Playwright の Test Agents の進化を整理した記事、生成 AI で E2E テストを自動化しようとして理想と現実のギャップに苦しんだ体験談——どれも非常にリアルで、自分も同じ壁にぶつかってきたので深く共感しました。読みながらずっと頭にあったのが、「コスト」と「確定性」という2つの軸です。今日はこのフレームワークで AI × E2E テストの現状を整理してみたいと思います。 どのアプローチも、コストと確定性のどちらかを犠牲にしているE2E テスト自動化のアプローチを振り返る...

Ensuring the reliability of the Rust compiler is of paramount importance, given increasing adoption of Rust for critical systems development, due to its emphasis on memory and thread safety. However, generating valid test programs for the Rust compiler poses significant challenges, given Rust's complex syntax and strict requirements. With the growing popularity of large language models (LLMs), much research in software testing has explored using LLMs to generate test cases. Still, directly using

はじめに本記事は、テストコードとAIをめぐるシリーズの8本目です。前作までと同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはミューテーションテスト。過去記事「AI時代にバックエンドエンジニアが磨くべきテスト設計力」の第4章で、私は次のように書きました。Mutation Testingは、コードを機械的に改変し、テストが落ちるかを検証する手法です。(中略)これらは、私が業務で本格的に運用しているわけではないので、ここでは名前と射程だけを記しておきます。本記事は、そのとき名前と射程だけで終わらせた話を、改めて掘り下げる学習記録です。私自身、まだ業務で運用...

こんにちは！納得できるテストをするための「モデリング入門」、第6回です。この回が最終回です！ここまでの連載では、モデルとは何か、モデリングにはどのような目的があるのか、ソフトウェア開発とテスト開発の中でモデリングがどう使われるのか、そしてテスト分析、テスト設計でモデリングをどう活用するのかについて解説してきました。続きをみる

こんにちは！納得できるテストをするための「モデリング入門」、第5回です。前回（第4回）は、モデルをスケッチから具体的なモデルにしていくステップと、テスト分析（理解）とテスト設計（工夫）の違いについて解説しました。 今回は、複雑な対象をより多面的に捉えるための「3種類のモデル」について解説します。このブログのベースとなっている「納得できるテストをするためのモデリング講座」では、3種類のモデルについていつも重点的に話しています。なぜなら、3種類のモデルを理解し、現場で使いこなせるようになることが、モデリングをテストに活かすうえで本質的に重要だからです。これまでの連載で説明してきた内容は、そのための前段だったとも言えます。その意味で、今回解説する部分は、このモデリング入門の中でも一番持ち帰ってもらいたい内容です。続きをみる

LayerX QAエンジニアの小山です。 昨今、AIコーディングアシスタント（特にClaude Code等）の進化により、コードの実装やテスト追加のスピードが飛躍的に向上しています。しかし、AIにコードを書かせる際に「どこまで厳密なエラーハンドリングが必要か」「テストはどの程度書くべきか」といったことに迷われた経験はないでしょうか？ 今回は、バクラク事業部の品質の定義やテスト戦略などを言語化し、Claude Codeが動く際にリスクの高い箇所を守るように動いてもらい、テストも同時に生成してもらう、早期テストで時間とコストを節約する試みについてご紹介します。 ソフトウェアテストの原則「早期テスト…

Zennで書いた記事がかなり伸びてるので、、、noteにも持ってきました😅 人間が寝ている間にClaude CodeがPlaywrightのE2Eテストを直してPRを出すzenn.dev 続きをみる

多くのSaaS企業がカスタマーサクセスに取り組むようになった現在、その役割は大きな転換点を迎えています。従来のオンボーディングや活用支援にとどまるのではなく、「いかにユーザーが自律的に成果を出し続ける状態をつくるか」が、次なる焦点となりつつあります。その背景にあるのは、顧客獲得コスト（CAC）の上昇や、収益性を左右するLTV（顧客生涯価値）への関心の高まりです。ユーザーの継続利用と成果創出をいかに実現するかは、もはや一部門の課題ではなく、事業成長そのものに直結する重要なテーマとなっています。こうした課題に対して、古謝が率いるポールトゥウィン カスタマーエクスペリエンス事業部は、どのようなアプローチをとっているのでしょうか。続きをみる

はじめに本記事は、テストコードとAIをめぐるシリーズの7本目です。前作「テスト名は仕様の1行 — AIに命名を任せられる環境を作るまで」と同じく、シリーズ本編から少し離れた単発記事として書いています。テーマはフレーキーテスト(flaky test)です。同じコードに対して、CIで落ちたり通ったりする不安定なテストのことです。私自身、過去に何度も格闘してきて、結局根本対処できずに「ReRunで凌ぐ」というやり方で逃げ続けた経験があります。本記事は、その苦い体験を一つ深掘りしながら、いまならどう向き合うかを構想として書き残す試みです。想定読者として念頭に置いているのは、2〜7年...

入社5年、同期3人の振り返り こんにちは！2021年にサイボウズへ新卒入社した massan、taguchi、taku3n です。気がつけば入社から5年。同期3人がそろって在籍しているこの機会に、それぞれの5年間を振り返ってみました。 massan kintone拡張基盤チームのQAエンジニアです。着物の勉強をしています。 taguchi PSIRTのプロダクトセキュリティエンジニアです。ラーメンが好きです。 taku3n Garoon開発チームのQAエンジニアです。最近ボードゲームにハマってます。 この記事は、QA として入社して１年経った話のリバイバル記事です。 ※元記事では柔軟な働き方に…

【QAチーム ブログリレー7日目】の記事です。 はじめに 前提：なぜPlaywrightへ移行したか 「まずコードを書けるようになろう」は諦めた 5つのステップで開発フローへ Step 1: Claude Codeに慣れる Step 2: シナリオを「読む」 Step 3: VS Code Codegenを使う Step 4: mablシナリオの移行ができる Step 5: 積み重ねで改良・省力化へ 現在地 AIだけでは足りなかった：地道な活動 レビューでテストの意図を確認する リファクタリングで品質の均一化を図る AI導入と同時に向き合っている3つの負債 1. 理解負債：AIが書いたコードを…

こんにちは！納得できるテストをするための「モデリング入門」、第4回です。前回（第3回）は、開発全体の中でテストがどう位置づけられるか、そして開発者とテストエンジニアの視点の違いについて書きました。 今回は、実際のテスト開発プロセスにおいて「テスト分析」と「テスト設計」でモデリングをどう使い分けるのか、そして具体的にどうテストケースに落とし込んでいくのかをデシジョンテーブルを使った例で解説します。続きをみる

Anthropic社のARR（年間経常収益）が14か月で10億ドルから190億ドルへこの急速な変化は、すでに想定されており、数年後のプロダクトの価値は飛躍的にあがることを想定なので、あまり細かいことに力を注ぐべきではなく、方向性を確認できる点に集中していたみたい。自分も前から言っているが、AI基盤や基盤エージェントを使う側の開発者も変化が速いことは相当考えておかないと、やっても意味ない、低いことになる。最近、今の基本スキルとしてモデリングだとのスピーチを拝聴した時も、最適化の最適化とくにターゲットを未来に置くことが重要な意図でコメントさせてもらいました。 Corpus2S...

ポートフォリオサイトを作り終えたとき、「見た目はそれっぽくなったけど、品質的にはどうなんだろう？」と気になりました。調べてみると、ChromeのデベロッパーツールにはLighthouseというパフォーマンステストツールが標準で搭載されており、特別なセットアップなしに手軽に使えることがわかりました。この記事では、Lighthouseの基本的な使い方と結果の読み方を、実際の画面キャプチャとともに紹介します。 1. 本番ビルドでテストする開発中によく使う pnpm dev（開発モード）のままLighthouseを実行すると、コードが最適化されていない状態のためスコアが実態よりも大きく...

@media only screen and (max-width: 600px) { .body { overflow-x: auto; } .post-content table, .post-content td { width: auto !important; white-space: nowrap; }}This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.By Roman GovsheevCan you spot the wasted CPU cycles in the map usage?if employee_id in employees: mail_to(employees[employee_id].email_address)The redundant lookup caused the

はじめに本記事は、テストコードとAIをめぐるシリーズの6本目です。1〜5本目では「AI時代に、エンジニアの設計判断はどこに残るか」という問いを軸に、テスト設計力、ドキュメントとしてのテスト、人間が先に仕様を設計する作法、QA技法、フロントエンドテスト実践記まで扱ってきました。ここから先はシリーズ本編から少し離れた単発記事を続けていきます。本記事のテーマはテスト名のリファクタリングです。前作「テストを"仕様の実行可能なドキュメント"として読み直す」で書いた「ドキュメントとしてのテスト」を、自分の現場で実践に移そうとしたとき、何を考え何を変えたかの記録です。本記事の想定読者は、テス...

はじめに「このコードのテストを書いて」とAIに頼むと、それなりに動くテストコードが返ってくる。カバレッジは上がる。CIも通る。しかし動作確認でバグが出たとき、振り返って気づくことがある。テストすべきことをテストしていなかった、と。私が観察する範囲で、AI生成テストには次のような傾向がある。実装の現状の挙動をそのままアサーションに固定してしまう正常系に偏り、業務的な異常状態への想像力が乏しい「このテストが落ちたら何がわかるか」を問いにくい、情報量の薄いテストが混じるこれらは個別には人間も犯すミスだが、AIに丸投げするとスケールして発生するところに固有の問題がある。...

はじめに最近、Zenn でも「Claude Code で E2E テストを自動修復」「Playwright MCP でテストを楽に書く」といった記事をよく見かけます。実際に試した方も多いのではないでしょうか。私も試しました。結論から言うと、AI にテストを「書かせる」のは簡単だが、AI に テストを「維持させる」のは危険だと感じています。この記事では、AI テスト自動化に期待しすぎて痛い目を見た経験を共有します。 AI テストの2つのパターン現在の AI テスト自動化には大きく分けて2つのアプローチがあります。パターン A：AI がテストコードを生成するClaude...

こんにちは！納得できるテストをするための「モデリング入門」、第3回です。前回（第2回）は、モデリングの2つの目的（「〜からモデルを作る」と「〜の前にモデルを作る」）や、抽象化と具象化のプロセス、そして「構造化」と「図と地」というモデリングの基本について解説しました。続きをみる

TL;DRAI に E2E の auto-heal を任せていると、ナレッジ側の腐敗が事故の引き金になる解は「GitHub Issue で失敗を起票 → AI が triage → 週次 cron で .github/instructions/ に昇格」のループを回すことMarkdown PR で直接更新する運用は、起票コスト・非エンジニア参加・昇格基準暗黙化の3つの壁で止まる。Issue ベースに変えるとここが抜けるtriage も昇格も GitHub Models（gpt-4o-mini、無料）と Claude Code Action の二段構えにすると現実的試作: ...

新しいプロジェクトで品質を上げるときにやること・目指すゴールライン 1. 概要 執筆の意図解決したい課題品質改善を任されたとき・途中参加したプロジェクトで、何を確認しどの順番で動けばよいかわからないという状況この記事のゴール品質改善における自分の考え方と進め方を言語化することで、同じ課題を持つ人の参考になること 要約まず何を確認するか、どの順番で整備するかという思考の型は、プロジェクトが変わっても再現できます。品質改善はフェーズを線形に完了させるものではなく、振り返りを回しながら改善し続けるサイクルです。完璧な品質ではなく運用として安全に回...

新しいプロジェクトで品質を上げるときにやること・目指すゴールライン 1. 概要 執筆の意図解決したい課題品質改善を任されたとき・途中参加したプロジェクトで、何を確認しどの順番で動けばよいかわからないという状況この記事のゴール品質改善における自分の考え方と進め方を言語化することで、同じ課題を持つ人の参考になること 要約まず何を確認するか、どの順番で整備するかという思考の型は、プロジェクトが変わっても再現できます。品質改善はフェーズを線形に完了させるものではなく、振り返りを回しながら改善し続けるサイクルです。完璧な品質ではなく運用として安全に回...