業務システムのリリース前リグレッションテストを、Playwright（ブラウザ自動操作ツール）で自動化した個人的な取り組みの記録です。ポイントは 「Playwrightも自動テストも未経験の状態から、生成AI（Claude）と日本語で対話しながら作った」 こと。※特定の社名・システム名・業務内容は伏せ、一般化して書いています。 概要申請業務系のWebアプリで、毎週のリリース前に手動リグレッションテストをしていた1つの申請が複数の役割（申請者 → 中間承認 → 最終承認）を渡り歩く承認フローで、組み合わせが多く手間だったPlaywrightで ログイン〜申請〜各役割で...

はじめに市場不具合が出たとき、振り返り（ポストモーテム）はしていますか？弊社では、一定の市場不具合に対してポストモーテムを実施しています。原因を深掘りして再発防止策を立てれば、その不具合への対応としては一区切りです。ただ、ふと思いました。個々の不具合は振り返っているのに、不具合の全体像を見る場はないな、と。1件1件のポストモーテムは「点」の振り返りです。でも、点を集めて「線」や「面」で見たら、個別の振り返りでは見えない傾向が見えるんじゃないか？そう思って、QAチームで1年分の市場不具合の収集・分析・レポーティングをやってみました。この記事では、その過程でやったことと、得られ...

E2Eテストにおいて、テストデータの準備はおまけではありません。どんなデータが揃っていればその振る舞いを検証できるのか、というのはテスト設計そのものだし、きちんと管理すべき対象です。ややこしくなるのは、そのデータ準備のコードが、振る舞いを検証するコードと同じspecファイルに同居しているときです。ユニークな名前を生成して、APIでプロジェクトやらマスタやらを用意して、テスト後に afterEach で消す。この準備と後始末が、「何を検証するか」という本題と一つのファイルに混ざる。読むときに性質の違う2つが一度に目に入ってきて、specの見通しが悪くなるんですよね。ひっかかるのはデータ...

バイブコーディングによって、アプリ開発のハードルは一気に下がりました。プロンプトを投げる。画面ができる。ボタンが動く。データが保存される。それっぽいアプリが形になる。すごい時代です。しかし動くものを作れることと、エンジニアとして扱えることは別です。エンジニアの仕事は「動いた」と喜ぶことではありません。作ったものが、期待した条件で、期待した通りに、壊れずに動くかを確かめること。つまり必要なのはテストです。ただ、この「テスト」という言葉は少し誤解されやすい。ソフトウェア開発におけるテストは、学校の試験のように誰かを採点するものとは違います。もっと近い言い方をするなら...

理想のQAは、ずっと「虚構」だった品質保証(QA)と品質管理(QC)の教科書には、昔から「理想形」が書かれていた。全コードの網羅的レビュー、全モジュールへの高密度なレビュー・解析・テスト基準、常に最新で完全なトレーサビリティ、独立した多重検証。だが、それはほぼ常に 実現できなかった。理由は一つ、コストだ。人間の検査は時間も費用も高い。だから現場は妥協してきた——サンプリング、リスクベースの優先順位づけ、「許容できるカバレッジ」、監査の直前に再構築されるトレーサビリティ。つまり私たちが「QA」と呼んで実践してきたものは、理想そのものではなく、理想を労働予算に射影した近似 だった。...

こんにちは、QAエンジニアのAyakaです。製造業向けSaaS（Blazor＋Radzen / SQL Server で開発）のテスト設計・品質管理を担当しつつ、最近はコーポレートIT寄りの仕事も兼務しています。テストケースをAIに「書かせる」こと自体は、もう誰でもできます。難しいのは、毎回同じ観点で、同じ品質で書かせることでした。テストケースを作る作業は、わりと早い段階からAIに手伝ってもらっていました。課題（PBI）の説明を渡して「テストケースを出して」と頼めば、それらしいものは返ってきます。最初のうちはそれで足りていました。ただ、しばらく使っていると、AIで作れてはいるの...

こんにちは、スタディストで QA エンジニアをしている髙津（@mototakatsu）です。先日、スタートアップで働く QA エンジニアのためのコミュニティ「QA engineer at a Startup」（通称 QaaS）のオンラインイベントで、「エンジニアと一緒にテストコードの設計と実装を改善した話」というテーマで登壇しました。この記事では、登壇内容を再現できる形で整理します。QA としてエンジニアのテストコード改善にどう関わったのかを、発表を聴いていない方にも持ち帰っていただけるようにまとめました。QA は、意識していないと「依頼を待つ存在」になりがちです。開発チームとの...

はじめに ― カバレッジ95%、テストは緑、なのに脆弱性が2件出てきたあるWebアプリケーションのセキュリティ監査を行ったときの話です。テストは通っていました。CIも緑でした。負債台帳(脆弱性や既知の課題を書き溜めておくドキュメント)にも、項目は一応列挙されていました。それでも、台帳の「テストが足りていない」という項目を1つずつ潰していく過程で、本物の脆弱性が2件見つかりました。テストカバレッジの問題ではなく、防御そのものが存在していなかったのです。なぜこんなことが起きるのか。それを説明するのが、この記事で紹介する Assurance Audit という考え方です。以前、AI...

要約著名な規約:PEP257: 命令形numpy: 命令形 (または戻り値を名詞で)Google: 命令形でも説明形 (三単現) でも OK筆者は命令形にしていますPEP257 と互換があるためRuff で確認できるためAI のドキュメント品質を Linter で容易に管理できるため余計なことを考える必要がなくなるため docstring 原則: 関数 docstring 最初の 1 行は「命令形から始めピリオドで終わる要約」にします関数 docstring 最初の 1 行は「命令形から始めピリオドで終わる要約」にします例:def f...

こんにちは！satto workspace で QA エンジニアをしている中井知子です。今回は、AI エージェントを活用してテスト実装を加速させるための取り組みについて紹介します。テスト設計からシナリオ作成・テスト実装までを AI エージェントと一緒に進めることで、どこまで効率化できるのか、実際に試してみました。!この記事で伝えたいこと✅ AI エージェントに目的を持ったテストを作らせるには、テスト戦略が起点になる✅ リグレッションテスト → 機能テストの順に、段階的に AI 活用を広げた✅ 人間がやるべきことを絞り込むことで、数日でテスト実装まで完了できる ...

テスト観点を軸にした品質サイクルのすすめ「テストが終わらない」——ソフトウェア開発に携わる人なら、一度はこの言葉を口にしたことがあるのではないでしょうか。リリース直前に湧き出るバグ、収束しない不具合、膨れ上がるテストケース。なぜ、テストはいつも終わらないのか。結論から言います。テストを「する」ことを目的にしているからです。テストケースを消化すること、カバレッジを上げること、全項目を網羅すること。これらは手段であって、目的ではありません。本当に問われるべきは、「そのテストは品質を上げているのか？」という問いです。この記事では、テストそのものではなく、テスト観点を軸にした品質サイク...

Androidのセキュリティ機能は、疑わしい通話、危険な操作、アプリや端末状態に関する警告を強化しています。これはユーザー保護として重要です。ただし、サポート、QA、EC運用、社内トレーニングの現場では、別の問題があります。1台のスマホが安全になるだけでは、チーム作業の記録、再現、引き継ぎ、複数端末の比較までは整理できません。この記事では、Androidの保護機能と、PC/Macから実機Androidを扱うワークフローを分けて考えます。 Android側の保護機能が担当することAndroid側の保護機能は、主に端末ユーザーを守るためのものです。不審な通話や詐欺的な状況に気づ...

1. はじめに — 「めっちゃ仕様が多いときは、強いモデルでいいんでしょ？」どーもりょうさんです。自分はQAエンジニアで、普段のテスト設計に生成AI（Claude）を使っています。前回の記事では、同じ仕様への観点出しを4つのモデル（Claude Sonnet・Opus 4.8・Fable 5・Codex）で10回ずつ回して、「モデルを強くすれば見落としは消えるのか」を測りました。結論は「強さは『届く合成距離の上限』を押し広げる。最深部が浮くのは最上位の Fable だけ」。すると、自然にこう思うはずです。「じゃあ、めっちゃ仕様が多い案件は Fable 一択では？」理屈は通ってい...

LLM品質テスト・監査プロセス——スプレッドシートから自動化までこんにちは、ケイだよ。Part 1で「5つの品質軸」を学んだね。でも「実際にどう測定するのか」「毎月何をするのか」という疑問が残るんじゃないかな？つまりね、「品質軸の定義」と「実装プロセス」は別物。診療報酬改定・金融庁ガイドラインで「継続的監視」が義務化された今、月次の測定・レポート・改善ワークフローを構築しないといけない。今回は、月次テストプロセス・自動化・継続監査ワークフロー を解説していく。スプレッドシートから自動化まで、段階的な進め方を示すよ。 月次テストプロセス：全5ステップLLM品質測定は、毎...

こんにちは、株式会社ダイニーでQAエンジニアをしているかわさきです。ダイニーのQA teamでいま試していることについて書こうと思います。「Claude Codeで開発の生産性が上がっている」という話は最近よく聞きます。同じことが、いまダイニーのQA teamでも起きています。テスト設計して実行する（仕事はこれだけではないですが）、という従来QAの仕事のやり方そのものが、Claude Codeでガラッと変わりつつあります。今回はその記録です。 ダイニーのQA teamが見ている景色最初に、私たちが何を相手にしているのかを少しだけ。ダイニーは「飲食をもっと楽しく、おもしろく。」...

こんにちは。株式会社ZENKIGEN QAエンジニアの横田です。普段はQAエンジニアとして、Webアプリケーションのテスト設計・実施・改善に取り組んでいます。2月に、Claude Codeでバグ起票を自動化した話を書きました。https://zenn.dev/zenkigen_tech/articles/58759228ca421a当時自動化したのは、テスト実行で見つけたバグをGitHub Issueに起票する作業です。型が決まった繰り返しでありつつ、少しだけ文脈の判断が要る作業は、AIに向いていると感じていました。あれから数ヶ月。気づけば、バグ起票だけだった自動化の範囲が、Q...

1. はじめにどーもりょうさんです。自分はQAエンジニアで、普段のテスト設計に生成AI (Claude)を使っています。昨日、ClaudeとCodexでどちらが仕様書のレビューに向いているのか — どっちもあんま変わらんかったオチという記事を出しました。あちらは異種モデル間 (Claude vs Codex) の比較で、結論は「モデルそのものより、何を指摘させるかを決めるプロンプトの方が効く」でした。本記事はその続きです。今度は同じClaude内の強度差 — Fable 5とOpus 4.8 — を、プロンプト・入力・thinking設定を完全に固定して測ってみました。結果は...

はじめに少し前に AIへの丸投げと細部の業務設計 — サブセッション自走化で見えた明暗の分岐 という記事を書きました。Laravel 8→12 / PHP 8.1→8.3 / alpine 化という MW（ミドルウェア）アップグレードを 9 リポジトリ横断で進める中で、サブセッションの自走運用に踏み込むときに浮上したリスク 7 類型と、親側に組み込んだ監視ガードレールについてまとめたものです。あれから 2 週間ほど、同じ 9 リポジトリで次のフェーズ — ステートレス化（Cache / Logs / Queue / File upload を ECS Fargate 想定で外出し...

「どっちのモデルがレビューに向くか」を測ろうとしたテスト設計の前に、仕様書の盲点を AI にレビューさせる。Claude と Codex、どちらが向いているのか——それを測ろうとして、同じ仕様を両方に投げました。題材は公開素材のテスト設計コンテスト'14の自動販売機仕様（ハードウェア仕様＋ユースケース仕様）。結論を先に言うと、答えは「どっちが優れているか」ではありませんでした。出てきたのは 「差は、プロンプトで埋まる分と、埋まらない芯に分かれる」——そして測っているうちに、自分の測り方まで疑うことになった、という話です。以下、実際に投げた3つのプロンプトと、返ってきた結果を順に並...

損保ジャパンDX推進部の藤井です。この記事は、現在私が携わっているPJにおける IT / ST / E2E の役割分担と、AI（MCP/CLI）前提で再設計した開発〜テストフローを、実運用として再現できる形にまとめたものです。 TL;DRこのPJでは、従来よりも E2E（Playwright）を厚めに整備し、品質担保の主軸に置きます背景は AIの台頭により、テストの作成・メンテナンスコストが下がったこと（＝「E2Eは最小化」が必ずしも最適解ではなくなった）ですただし「全部E2E」ではありません。外部依存・運用/データ検証・探索的な気づきは IT/ST/アドホックに寄せ、役割...