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

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

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

はじめに本記事は3部構成の最終回、第3部です。第1部では、フロントエンドにテストを導入した経緯とVitestの選定、そして「テストを入れる、とはどういうことか」への暫定的な答え(観点を持つこと、コードの外側の情報を内側に畳み込むこと)を書きました。第2部では、AIエージェントに任せた結果の抜け漏れを記録し、原因を観点設計の不足とドメイン理解の薄さに求めたうえで、カバレッジ計測をチームに導入した経緯を書きました。そこで合意した「C1カバレッジ70%を下限に置く」という数字は、第2部の終わりではまだ手に入れたばかりの武器として置かれたままです。第3部では、この武器をどう扱うかに向...

はじめに本記事は3部構成の最終回、第3部です。第1部では、フロントエンドにテストを導入した経緯とVitestの選定、そして「テストを入れる、とはどういうことか」への暫定的な答え(観点を持つこと、コードの外側の情報を内側に畳み込むこと)を書きました。第2部では、AIエージェントに任せた結果の抜け漏れを記録し、原因を観点設計の不足とドメイン理解の薄さに求めたうえで、カバレッジ計測をチームに導入した経緯を書きました。そこで合意した「C1カバレッジ70%を下限に置く」という数字は、第2部の終わりではまだ手に入れたばかりの武器として置かれたままです。第3部では、この武器をどう扱うかに向...

はじめに本記事は3部構成の第2部です。第1部では、フロントエンドにテストを導入することになった経緯、Vitestの選定とスコープ定義、そして「テストを入れる、とはどういうことか」への暫定的な答えとして、観点を持つこととコードの外側の情報を内側に畳み込むことという二つの側面を書きました。第2部では、ここから実装に踏み込んでいきます。AIエージェント(Cursor、Claude Code)に全力で頼ってテストを書き進めた結果、何が起きたか。なぜ抜け漏れが目立ったのか。原因は誰にあったのか。AIに任せたフロントエンドのテストで、抜け漏れは誰が拾うのか、という問いへの、私なりの応答を書い...

はじめに本記事は、バックエンドエンジニアとして9年目を迎えた私が、フロントエンドのテスト導入をチームでリードすることになってからの1ヶ月間を振り返る実践記です。VitestとAIエージェント(Cursor、Claude Code)を組み合わせてテストを書き進めるなかで、何がうまくいき、何がうまくいかず、どこで方向転換をしたか。その途中経過を、3部構成で記録していきます。先に断っておきますが、私はフロントエンドエンジニアではありません。バックエンドを主軸にキャリアを積んできた身で、フロントエンドのコードとの接点はバックエンドAPIとの接続部分を一緒に確認する程度でした。フロントエン...

本記事は、2024年入社のQAエンジニア 3人による振り返りブログの3本目です。 まだ読んでいない方は、ぜひ1本目・2本目もあわせてご覧ください！ blog.cybozu.io はじめに こんにちは、GaroonというプロダクトでQAエンジニアをしている reo（@i_moqa）です⛄️ Garoonの開発チームは複数のチームで構成されているのですが、私はその中のYukimiチームに所属しています。 YukimiチームはGaroonで使用しているOSS（オープンソースソフトウェア）の更新や、セキュリティの維持・向上に向けた開発・保守を担当しています。 Yukimiチームの詳細については以下の記…

はじめに「ファジングってランダムに変なデータを投げるやつでしょ？」概念としては正しいのですが、実務で使おうとすると「どのツールを使えばいいか」「クラッシュが出たらどうするか」という壁にぶつかります。この記事は、ファジングの仕組みを学んだあとの 「実際にどう使うか」 に焦点を当てた実践編です。ツールの選び方・FuzzingとDoSテストの違い・クラッシュ結果の解析手順を整理します。ファジングの基本から知りたい方はこちら👇https://zenn.dev/mapellion/articles/684090dd024ea7 ファジングツールの2つの流派ファジングツールは大...

設計なし・テストなし・仕様書なしのプロジェクトで5ヶ月やったこと 1. 概要 執筆の意図解決したい課題設計・テスト・仕様書がない状態で途中参加したとき、何から手をつければ良いかわからないという状況この記事のゴール短期間・限られたリソースの中で、優先順位をつけながら品質プロセスを整備していくアプローチを共有すること 要約設計なし・テストなし・仕様書なしという状態から、5ヶ月で基本的な品質プロセスを整備しました。「いきなり完璧を目指す」のではなく、手順化からツール化へという段階的なアプローチで確実に積み上げました。短期間だからこそ今いちばん痛い...

設計なし・テストなし・仕様書なしのプロジェクトで5ヶ月やったこと 1. 概要 執筆の意図解決したい課題設計・テスト・仕様書がない状態で途中参加したとき、何から手をつければ良いかわからないという状況この記事のゴール短期間・限られたリソースの中で、優先順位をつけながら品質プロセスを整備していくアプローチを共有すること 要約設計なし・テストなし・仕様書なしという状態から、5ヶ月で基本的な品質プロセスを整備しました。「いきなり完璧を目指す」のではなく、手順化からツール化へという段階的なアプローチで確実に積み上げました。短期間だからこそ今いちばん痛い...

ぱんだツールズ のツール数が 80 を超えた。AI と一緒に開発するようになってから、ツールを作る速度が自分で動作確認できる速度を完全に追い越した。共通コンポーネントを 1 行触ると 80 ツールが影響範囲に入るので、リファクタが怖くて手が止まる。自動回帰テストを入れるしかなくなった。問題は どう自動化するか だった。AI で開発しているんだから、テストも AI に任せるのが筋なんじゃないか。ちょうど Anthropic から Claude in Chrome がリリースされたタイミングで、最初はこれを本命に検討した。が、結論から言うと、Claude in Chrome は E2E ...

「カバレッジ80%を達成してください」——PRレビューでこの一言を見るたびに、違和感を覚えるエンジニアは少なくないだろう。数字を追えば追うほど、テストの本来の目的から遠ざかっている気がする。この記事は、その違和感に根拠を与えるために書いた。!この記事の結論を先に言うと：カバレッジは「コードが実行された」ことを示すだけで、「正しく動く」ことは保証しないカバレッジ目標を設定した瞬間、グッドハートの法則により指標としての価値が下がる本当にテストの質を測りたいなら、Mutation Testing（変異テスト）という選択肢がある カバレッジが保証しているもの、していないもの...

TL;DRE2Eテストの auto-heal を AI に任せていると、ナレッジ側の腐敗が事故の引き金になる.github/instructions/ Markdown だけでも gh issue だけでも腐る。両方が必要「Issue で起票 → ラベル分類 → instructions/ に昇格」というループを回す方向にシフトしませんか、という話試作として qa-knowledge-platform を出していますが、これはあくまで方向性の一例AI4QA で勝負を分けるのは "ストレージ選定" ではなく "ナレッジ運用のリズム" だ、というのが今回の持論 AIに...

はじめにこんにちは、uchiです。株式会社ビズリーチのAI Product Studio（以下、APS）でエンジニアをしています。APSは2026年2月に新設された組織で、「AIでプロダクト創出を常態化する」をミッションに、現在はAIを前提とした開発プロセスの構築と新規プロダクト開発に取り組んでいます。この記事では、APSでAI前提の開発フローを構築するなかで生まれた「Agentic UATスキル」を紹介します。AIエージェントに仕様を一切教えずエンドユーザーを演じさせ、業務を遂行できるかを自律的にテストする手法です。ソースコードを読ませず、UIだけを頼りに業務を進めさせることで...

ソフトウェアテストの種類：正常系・準正常系・異常系テストケースを設計するとき、「異常系」としてひとまとめにされがちだが、正確には 正常系・準正常系・異常系 の3種類に分類できる。この区別を意識するとテストの抜け漏れを防ぎやすくなる。 正常系テスト正常な入力に対して、システムが正しい出力を返すことを確認する。ユーザーが想定どおりの操作をしたときに、期待した結果が得られるかを検証する。例：ログイン機能正しいメールアドレスとパスワードを入力 → ログイン成功・ホーム画面に遷移する 準正常系テスト予期されるエラーや異常な入力に対して、システムが適切に反応するかを検...

ソフトウェアテストの種類：正常系・準正常系・異常系テストケースを設計するとき、「異常系」としてひとまとめにされがちだが、正確には 正常系・準正常系・異常系 の3種類に分類できる。この区別を意識するとテストの抜け漏れを防ぎやすくなる。 正常系テスト正常な入力に対して、システムが正しい出力を返すことを確認する。ユーザーが想定どおりの操作をしたときに、期待した結果が得られるかを検証する。例：ログイン機能正しいメールアドレスとパスワードを入力 → ログイン成功・ホーム画面に遷移する 準正常系テスト予期されるエラーや異常な入力に対して、システムが適切に反応するかを検...

はじめに本記事は前後編の後編です。前編では、開発者が知っているとテスト設計の思考が変わる5つのQA技法を紹介しました。同値分割と境界値分析、状態遷移テスト、デシジョンテーブル、ペアワイズ法、そして探索的テスト。それぞれが「そのテスト、どう設計した?」という問いに具体的な答え方を与えてくれる道具でした。後編では、それらの技法を踏まえたうえで、記事冒頭(前編)で触れた「カバレッジ100%をめぐる問い」に今の自分ならどう答えるかを、4段構成で掘り下げていきます。先に正直に書いておくと、私はQA技法の専門家ではありません。学習者として試行錯誤してきた立場です。後編で展開するカバレッジ...

はじめにテストコードは書けるけれど、「そのテスト、どう設計したの?」と問われると言葉に詰まる。「なんとなく網羅しました」以上の答えが出てこない。そんなもどかしさを感じたことはないでしょうか。本記事は、そのもどかしさに向き合うためのQA技法を、開発者の視点から5つ取り上げて紹介するものです。同値分割、境界値分析、状態遷移テスト、デシジョンテーブル、ペアワイズ法、そして探索的テスト。開発者が知っていると、テスト設計の思考が変わる5つの武器です。先に正直に書いておくと、私はQA技法の専門家ではありません。体系的に学んだ経験はなく、チームのQAメンバーから聞き齧って試行錯誤してきた立場...

はじめにテストコードは書けるけれど、「そのテスト、どう設計したの?」と問われると言葉に詰まる。「なんとなく網羅しました」以上の答えが出てこない。そんなもどかしさを感じたことはないでしょうか。本記事は、そのもどかしさに向き合うためのQA技法を、開発者の視点から5つ取り上げて紹介するものです。同値分割、境界値分析、状態遷移テスト、デシジョンテーブル、ペアワイズ法、そして探索的テスト。開発者が知っていると、テスト設計の思考が変わる5つの武器です。先に正直に書いておくと、私はQA技法の専門家ではありません。体系的に学んだ経験はなく、チームのQAメンバーから聞き齧って試行錯誤してきた立場...

テスト時間が取れないチームで品質を上げるためにやり続けたこと 1. 概要 執筆の意図解決したい課題テスト時間が確保できない・バグが頻発する・仕様が誰もわからない、といった課題を抱えたチームで、どこから手をつければ良いかわからないという状況この記事のゴールQAの視点から課題を構造的に捉え、設計・プロセス改善まで踏み込んで品質を上げていくアプローチを共有すること 要約テスト時間が取れない原因はテストの問題ではなく開発サイクルの問題として捉え、上流から解決するアプローチを取りました。仕様が残らない・使われないものができるという課題に対しては、個人の...

テスト時間が取れないチームで品質を上げるためにやり続けたこと 1. 概要 執筆の意図解決したい課題テスト時間が確保できない・バグが頻発する・仕様が誰もわからない、といった課題を抱えたチームで、どこから手をつければ良いかわからないという状況この記事のゴールQAの視点から課題を構造的に捉え、設計・プロセス改善まで踏み込んで品質を上げていくアプローチを共有すること 要約テスト時間が取れない原因はテストの問題ではなく開発サイクルの問題として捉え、上流から解決するアプローチを取りました。仕様が残らない・使われないものができるという課題に対しては、個人の...

はじめにモバイルアプリ開発において「テスト」という言葉は幅広い意味を持ちます。「どんなテストを書けばいいか分からない」「テストの種類が多くて混乱する」という声をよく聞きます。この記事では、モバイルアプリ開発で登場するテストの種類を、テストの粒度（スコープ） と テストシナリオの性質 の2軸で整理します。 1. テストの粒度による分類 単体テスト（Unit Test）対象： 関数・メソッド・クラスなど、最小単位のコード単体テストはアプリの最も小さな部品が正しく動くかを検証します。外部依存（DB、API、UIなど）はモック・スタブで置き換え、テスト対象のロジックのみを純...

こんにちは！サイボウズ Office で QA エンジニアをしている、水谷（@dog_dog_3dog）です！ 今回は、新卒3年目を迎える3人のQA同期メンバーのリレーブログの2本目として、「仕事の変化はあるけれど、やってきたことはちゃんと力になっている」というテーマで書いてみようと思います。 1年前には想像していなかった今の仕事 3年目を迎えた今、私はグループウェア製品の中のLLM アプリの開発チームで、QA のリードとして働いています。 その中で、LLM アプリのバックエンドで使っている gRPC API のテストを、2か月で 500〜600 シナリオほど実装しました。 今の自分だけを見る…

こんにちは！atama plusでQAエンジニアをしている池上です。「AIを使った機能のテスト、どこから手をつければいいんだろう？」生成AIをプロダクトに組み込む機会が増えたいま、そう感じているエンジニアは多いのではないでしょうか。2026年3月、atama plusは従業員教育プログラムの一環として、AIロープレ機能をリリースしました（プレスリリース）。さまざまな職種のコミュニケーション練習を想定したこの機能では、AIが対話相手役を演じ、ユーザーがコミュニケーションスキルを繰り返し練習できます。この機能のQAを進めるなかで、何度も立ち止まって考えたのが、「AIプロダクトでは何...

はじめにこんにちは！TOKIUMでQAチームのリーダーをしている西田です。「シフトレフト」「ATDD（受け入れテスト駆動開発）」「BDD（振る舞い駆動開発）」 — テストを上流に持っていこうという考え方は、ソフトウェア開発の世界で10年以上前から提唱されてきました。概念としては広く知られているのに、実際に徹底できている現場は少ない。「理想はわかるけど、やるのが大変」というのが正直なところだったと思います。ところが今、生成AIの急速な進化によって前提が変わりつつあります。Claude CodeやGitHub Copilotによるコーディング自動化、Playwright Agent...

はじめにどんなプロダクトにも、社内でQAとは謳っていなかったとしても、大なり小なりQA活動は存在する。続きをみる

Playwright未経験のQAエンジニアが、Page Object Model + Fixtures PatternでメンテナブルなE2E回帰テスト基盤を作り、Claude Codeで「書ける/直せる」を仕組み化し、最終的に夜間auto-healで失敗テストの修正PRを自動生成するところまで届くハンズオン書。`docker compose run`で動くテンプレートリポジトリをクローンしながら章ごとに進められる。

はじめに開発者です。中小企業でバックエンドとフロントエンドの両方を担当しています。去年、QAチームの手動回帰テストが限界に達していました。リリースのたびに2〜3日かけて手動で全画面を確認する。人も足りない、時間もない。「自動化すれば解決する」と思って、Playwrightで E2E テストを書き始めました。半年後、200件のテストができました。これで楽になる——はずでした。 セレクタ地獄の始まりスプリントのたびに10〜15件のテストが壊れます。原因を調べると、アプリのバグではない。デザイナーがCSSクラス名を btn-primary から button-main ...

Android開発に関しては、仕様に準拠しているか、互換性を満たしているか、セキュリティといった特定の品質を実現しているか確認するためのテストスイートが複数提示されています。これらはAndroid xTSとも呼称されます。今回はその主要なxTSをまとめます。 CTS(Compatibility Test Suite) CTSは、対象のデバイスのAndroidのAPIが標準仕様を実現しており、デバイスでサードパーティのAndroidアプリーケーションが動作するか確認するテストスイートです。 CTSでは、端末メーカーのカスタマイズで標準のAndroid APIが壊れていないか、妥当な性能を確保して…

「最近バグが多いんです。QAをもう一人増やしたほうがいいですよね？」他のエンジニアリングマネージャーや開発リードから、こんな相談を受けることがあります。私もかつては、「そうですね、まずは採用要件を整理しましょう」と返していました。続きをみる

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