はじめてのZenn投稿これはGitHub連携のテストです。

生成AIによって、時間がかかる箇所に変化が起きています。コーディングもドキュメントも分析もいろいろなことをお願いできます。その中で、「それを本当に毎回頼む必要があるのか？」というのもあります。続きをみる

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

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

What is this?3/30(月)夜に開催された「JaSST'26 ファンミーティング」に現地参加させていただきましたので、そのレポートになります📝続きをみる

React Flow のノード接続を Playwright でテストする はじめに業務で React Flow を使っているアプリのテストを書いていてちょっと詰まったため、その備忘録も兼ねております。 この記事で扱うことReact Flow のノード接続操作を Playwright でテストする方法なぜ dragAndDrop() では動作しないのかdragTo() を使ったシンプルな解決方法 対象読者Playwright の基本的な操作は知っているReact Flow を使ったアプリのテストを書きたい サンプルアプリについて以下の構成のサンプ...

はじめにE2Eテストの要素特定では、よく data-testid やアクセシビリティラベルが使われます。正しく運用できれば、とても安定した方法だと思います。実際、アクセシビリティラベルを丁寧に整備して、Playwright の getByRole / getByLabel で安定運用しているチームもあります。ただ、自分の経験では、すべての現場でそれができるわけではありません。既存プロダクトが大きく、テスト用属性を後から付けるのが重いフロントエンドチームに依頼しても、優先度が上がりにくいコンポーネントの再利用やネストで、命名規則の運用が難しいリファクタリング後に、IDや...

はじめにJSTQB Foundation Levelに合格しました。この記事では、これからJSTQB Foundation Levelを勉強しようとしている方向けに、私が実際に行った勉強方法や、試験を受けて感じたことをまとめます。私はテスト専門の業務に深く関わっているわけではないため、最初は知らない用語も多くありました。ただ、問題を解きながら少しずつ用語や考え方に触れていくことで、テストに関する基礎知識を体系的に学ぶことができました。これから受験する方の参考になればうれしいです。 JSTQB Foundation LevelとはJSTQB Foundation Lev...

はじめにQAエンジニアの仕事は「テストケースを手で起こし、手で回し、結果を Excel に貼る」だった時代から、ここ1〜2年で大きく形を変えつつあります。Playwright のような自動化基盤、Claude Code のようなAIエージェント、そして MCP（Model Context Protocol）を通じてブラウザを操作するAI──これらが揃ったことで、テストは「人が書いて回すもの」から「AIに生成・実行させ、人が解釈・判断するもの」へシフトしてきました。本記事は、弊社で実際に運用している Claude スキル群（spec / generate-page-spec / g...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第5回です。 1. なぜファイル定義を独立観点としたのかCOBOLにおけるFD句は、単なる構造宣言ではありません。RECORDING MODEBLOCK CONTAINSレコード長固定長／可変長ラベルレコードこれらは、実行環境と密接に結びついています。言語仕様は同じでも、I/Oの前提が変われば動作が変わります。 2. 検証観点以下の観点で確認しました。OPEN時の挙動READ時のレコード解釈レコード長の扱いEOF検知のタイミング固定長／可変長の差...

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の第4回です。 1. なぜデータ例外を独立観点としたのかデータ例外は単なる異常系ではありません。移行時に問題となるのは、例外が発生するかどうかどの命令で発生するか発生後の処理が継続するか停止するか戻りコードやメッセージの違いです。つまり、例外の“存在”ではなく、“構造”が問題になります。 2. 検証設計 2.1 検証軸 ステートメント軸MOVEADDSUBTRACTCOMPUTEDIVIDEIF（比較）DISPLAY データパタ...

Attention Driven Test というアイデアの話最近「テストケースって、コードの複雑さからは結構議論されてるけど、ユーザーの認知負荷からはあんまり議論されてなくない？」って思って、ぼんやり考えていたことを書き出しておく。呼び方を Attention Driven Test (ADT) と勝手に名付けた。実装の話というよりは、テスト設計の方法論として育てたいアイデアのメモ。 出発点: 既存のテスト戦略はだいたいコード側を見ているリスクベーステスト、変更頻度ベース、Cyclomatic Complexity、ミューテーションテスト、PR複雑度スコアリング (これは...

最近、テスト設計をAIに頼むこともだいぶ増えてきました。ただ、最初の頃にやってみて気づいたんですけど、なんとなく「このシステムのテストケース出して」と頼むだけだと、返ってくるのはハッピーパス中心の、なんとも当たり障りのない一覧なんですよね。それが「JSTQB準拠で、同値分割と境界値分析を使って」と一言添えるだけで、ぐっと網羅性が立ち上がる。境界の漏れが減って、デシジョンテーブルでお願いすれば条件の組み合わせが整理された形で返ってくる。状態遷移ならそれっぽく状態とイベントを分けて出してくれる。最初は「やっぱりAIって賢いんだな〜」と素直に感心していたんです。でも最近、ちょっと違う気...

プロダクトを動かしながら試すことを動的に変化させ違和感を見つける行為をAIに指示できればAIエージェントmiwaができるとして、指示を言語化するにはプロダクトを試さなきゃならなくて言語化できたときには人間miwaは違和感に気づいてしまうので、次に見つけたいのはもうそれじゃないんだよなってなる — miwa (@miwa719) 2026年3月20日 仕事中の「プロダクトを動かしながら試すことを動的に変化させ違和感を見つける行為」をオンライン（社内）で流しながら、ゆるーくやってみようと思っています。このブログを読んでくださっている多くの方はその様子を見ることはできず、たいへん心苦しいのですが、も…

はじめにAIを使ってテスト設計を進めることが、かなり現実的になってきました。仕様やコード差分をもとにテスト観点を出してもらう。テストケースのたたきを作ってもらう。不足している異常系や境界値を洗い出してもらう。場合によっては、そのままテストコードまで生成してもらう。ここまでできるようになると、テスト設計にかかる初速はかなり上がります。一方で、実際に運用してみると、別の感覚も出てきます。それは、AIにテスト設計を任せても、最後に品質を決めるのはやはり人間のレビューだ、ということです。AIはそれっぽい観点をたくさん出してくれます。でも、その中に本当に重要な観点が含まれて...

はじめにテストの話になると、よく出てくるのが「テストカバレッジ」という言葉です。カバレッジはどのくらいですか80%を目標にしましょうカバレッジが低いので不安ですとりあえずカバレッジを上げたいですこうした会話は、開発現場でかなりよくあります。一方で、実際には「カバレッジという言葉は知っているけれど、何を表しているのかをちゃんと説明するのは少し難しい」という人も多いのではないかと思います。さらにややこしいのは、カバレッジは数字として見やすい反面、その数値だけで品質を判断すると危ないということです。特にAI駆動開発では、この問題がより目立ちやすくなっています。AIを...

はじめにAIを使って実装することが、かなり当たり前になってきました。画面実装、API実装、リファクタリング、テストコードの追加まで、以前よりずっと速く進められるようになっています。少し前ならそれなりに時間がかかっていた作業も、AIを使えば短時間である程度形になります。一方で、AI駆動開発には別の難しさもあります。それは、実装スピードが上がることと、品質を安定して守れることは別だということです。AIはコードを書いてくれます。テストコードもそれっぽく作ってくれます。ただ、こちらが観点を渡さない限り、どうしても正常系中心の薄いテストになりやすいです。ぱっと見では十分そうに見えて...

Software testing is a fundamental process of software development, and prior work has shown that visualizations of test results support testers' decision-making. However, Human-Computer Interaction research on software testing has yet to explore and understand the shared interface elements and patterns in visualization of testing outputs. To address this, we conducted a visual comparative analysis of the output of 50 software testing tools and harnesses (44 with CLI output, 6 with GUI output) ac

With the accelerating development of quantum technologies and their growing computational potential, quantum systems are being adapted for simulations and other critical tasks across diverse domains, making the reliability of the corresponding quantum software an essential concern. Although recent efforts have started to incorporate quantum-specific properties such as magnitude, phase, and entanglement under the form of input-coverage criteria into software testing, the unique structure of the q

@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 Shahar Roth Classes require various objects and parameters to function. The "Construct with Collaborators, Call with Work" guideline can help you construct effective inputs

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

はじめに今回取り上げたいのはQAメンバーとの観点共有についてです。新機能をどんな観点でテストするか、テストデータや環境をどう揃えるか、探索的テストで見つかった観点をどう活かすか。こうした問いは開発チームとQAチームが言葉を交わす中で答えが立ち上がってくるものです。本記事ではその観点共有が、私の現場ではどこで起きていたかを振り返って書きます。結論を先に書くと、観点共有の主要な場は会議や打ち合わせではなくSlackでのやりとりでした。それも一方向の通知ではなく、何度も言葉を交わす往復の中で観点が彫り上がっていく形で。想定読者はQAメンバーと一緒に開発しているエンジニア、特に「観点共有...

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