最近は、AIと壁打ちして実装計画を立てた後、実際の実行プランを立てて中を見ると、見慣れない言葉があったりして、それを質問して学ぶ、みたいなことが多い。今回個人開発サービスのテストのリファクタリングに取り組んでいて、AIが聞きなれない単語をプランに記述していた。narrow テストと broad テストを混ぜてはいけない。これはガイドラインではなく 契約(contract) である。結論から言うと、これは「テストの種類」の話というより、テストの責務をどう分けるかという設計の話だったのだが、ここにそれを簡単にまとめてみます。 責務を分けるのはテストコードにも言える「責務を分け...

AIエージェントを使うと、自然言語からテスト手順の下書きを作ったり、実行後のスクリーンショット、OCR、ログを要約したりできます。これはモバイルQAでも便利です。ただし、AndroidのUIテストでは「エージェントが成功と言ったか」だけでは不十分です。ユーザー体験は画面上で起きます。ボタンが別のUIに隠れていないか権限ダイアログが途中で出ていないかローカライズ文字列がはみ出していないかwebviewや画像が遅れて表示されていないか実機でエミュレータより遅くなっていないかこうした問題は、画面、スクリーンショット、ログがないとレビューしにくいです。 AIエージェントが得...

今日はSpring BootのControllerテストを書きながら、HTTPステータスやValidationについてかなり理解が深まりました。今まで「なんとなく動けばOK」で終わっていた部分が、「なぜそのステータスになるのか」を考えられるようになった一日でした。 201 Createdを返すにはController側も変更が必要だった最初はPOSTのテストを書きました。.andExpect(status().isCreated());しかし、実際にはStatus expected:<201> but was:<200>となりました。原因はCo...

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

出発点は「手を抜きたい」だった最初の動機は、まったく高尚じゃない。手を抜きたかった。AIにできる限りやらせたい。自分はできるだけ動きたくない。でも、出てくるものの品質は落としたくない。この3つを同時に満たしたい、というだけだった。そこから、ほしい開発プロセスの形はすぐ決まった。SPECとユースケースくらいまでは、自分が面倒を見る。何を作るかは、さすがに自分で書く。でも、その先——実装、テスト、レビュー、仕様と実装の突き合わせ——は、全部AIにやってほしい。要するに「上流だけ握って、下流は丸投げ」。怠け者の理想形だ。じゃあ、その開発プロセスを作るか。そう思って手を動かし始めた...

Claude CodeやCursorを使えば、動くものはすぐ作れる時代になりました。でも──「これ、納品して大丈夫」と、自信を持って言えていますか？作るスピードは爆上がりしたのに、QA（品質チェック）だけが置いてけぼり。フリーランスや少人数開発だと"あるある"だと思います。 こんな状態になってないか専任のQA担当なんていないかといって、全機能を毎回手でテストする時間もない結果「動いてるっぽいから納品」→ 本番でバグ → 信頼が一気に崩れる 解決策：全部テストしない。「Tier仕分け」するコツは1つ。変更を"重さ"で仕分けるだけです。変更の種類Tier...

Claude CodeやCursorを使えば、動くものはすぐ作れる時代になりました。でも──「これ、納品して大丈夫」と、自信を持って言えていますか？作るスピードは爆上がりしたのに、QA（品質チェック）だけが置いてけぼり。フリーランスや少人数開発だと"あるある"だと思います。 こんな状態になってないか専任のQA担当なんていないかといって、全機能を毎回手でテストする時間もない結果「動いてるっぽいから納品」→ 本番でバグ → 信頼が一気に崩れる 解決策：全部テストしない。「Tier仕分け」するコツは1つ。変更を"重さ"で仕分けるだけです。変更の種類Tier...

ご覧いただきありがとうございます。製造業でシステム設計エンジニアをしている新入社員です。毎週日曜投稿を目標にしてきましたが、今週は1週遅れてしまいました。お待ちいただいていた方、すみません。さて今回は pytest です。「テストって何?」からスタートして、書けるようにはなったものの、正直まだよく分かってないというのが本音。ありのままの状態を書きます。同じ立場の方に共感してもらえたら嬉しいですし、詳しい方には教えてもらえると助かります。 そもそも「テスト」って何のため？自分でコードを書き始めてからも、動作確認は print() で出力して目視、というスタイルで過ごしてきまし...

導入ソフトウェア開発では、「機能テスト」と「回帰テスト」という用語がよく使われる。しかし、この二つの境界は必ずしも明確ではない。例えば「ログインできる」という同じテストケースでも、新規実装時は機能テストログイン画面修正後は回帰テストと呼ばれることがある。...

始めたばかりなのでテスト的な投稿です。ご容赦ください 🙇

ブラウザ上で動く VS Code、code-server（78k スター）のテストをデバッグしていた誰かが、私たちの誰もがやることをやりました。反復を速くするために、テストを 1 件だけにフォーカスしたのです。it.only("should change to expired when not active", async () => {そしてそれがコミットされました。およそ 7 か月のあいだ、その 1 つの .only が同じファイルの残り 8 件のテストを黙って無効化していました。その間ずっと CI はグリーンのままでした。CI から見れば何も問題はなかったからです。フォー...

Nobody schedules a regression testing failure. The failure schedules itself, quietly, on a Tuesday afternoon when a team three floors up deploys a patch to their authentication service. The patch is correct. It passes every test in that service's suite. The team marks the deployment successful an...

!この記事は「Claude Code で AI 駆動開発を仕組みにする」シリーズの応用編です。シリーズ全体は シリーズ目次 を、前提となる Issue 起点の自動実装フローは #5 Issue 駆動開発を Claude Code で完全自動化する と ラベル・ステートマシン化 を参照してください。 例え話: 「工場のラインだけ自動化して、検品が手作業のまま」問題AI 駆動開発のパイプライン（Issue → 自動実装 → AI レビュー → PR）を回し始めると、実装のスループットは確実に上がります。私の環境では、無人で実装からレビューまで進む Issue が1日に数本、常時流...

Software tests and code evolve together: a code change should be followed by new or updated tests that record the new software behavior. Yet existing test generation and update benchmarks often isolate the test from the code change, and rely on static metadata that does not verify whether a test is executable or semantically tied to the code change. This makes it difficult to evaluate whether a test automation agent understands how a code change should propagate into the test suite. We introduce

Quantum software testing (QST) checks whether quantum programs behave according to their intended specifications. A key requirement for QST research is a benchmark that supports rigorous empirical evaluation on programs that are testable and better reflect current software development practices. However, existing studies heavily rely on small hard-coded or circuit-level benchmarks, while available quantum programs are scattered across repositories without clear selection criteria, which limits f

20年目のQAエンジニアが振り返る「学び直しリスト」3ヶ月ぶりの記事です！ここ最近仕事が忙しく（ありがたいことに）、記事が全く書けていませんでした。これからまた活動を再開していきたいと思います。初志貫徹！QAエンジニアとして20年間、なんとなく続けてきた仕事のなかで、「あのとき流したことを、今こそ学び直したい」と感じる分野がいくつかあります。きっかけは何か特別な出来事があったわけではなく、日々の業務でふと引っかかる瞬間の積み重ねでした。生成 AI にテスト観点を出させて「意外と自分の頭ではこの観点が出てこなかった」と気づいたとき。若手に JSTQB の用語を説明していて、自分の...

20年目のQAエンジニアが振り返る「学び直しリスト」3ヶ月ぶりの記事です！ここ最近仕事が忙しく（ありがたいことに）、記事が全く書けていませんでした。これからまた活動を再開していきたいと思います。初志貫徹！QAエンジニアとして20年間、なんとなく続けてきた仕事のなかで、「あのとき流したことを、今こそ学び直したい」と感じる分野がいくつかあります。きっかけは何か特別な出来事があったわけではなく、日々の業務でふと引っかかる瞬間の積み重ねでした。生成 AI にテスト観点を出させて「意外と自分の頭ではこの観点が出てこなかった」と気づいたとき。若手に JSTQB の用語を説明していて、自分の...

Android自動化は、いきなり大きな仕組みとして考えるよりも、まず画面上で繰り返される操作から考えるほうが現実的です。多くのQA、サポート、アプリ検証、運用作業では、APIだけではなく、実際の画面状態を確認する必要があります。たとえば、アプリを開く、画面の読み込みを待つ、ボタンやテキストが表示されているか確認する、タップする、入力する、スクリーンショットを保存する、同じ流れを別のAndroid端末やエミュレータで繰り返す、といった作業です。このため、最初のレイヤーは AndroidスマホをPCにミラーリング することです。PC上でAndroid画面を見て、マウスやキーボードで操作で...

こんにちは！アルダグラムでQAエンジニアをしているshige_sです。私たちQAユニットでは、ノンデスクワーカー向けアプリ「KANNA」の品質保証を担っています。これまでアルダグラムのQAユニットは、各開発チームに固定のQAエンジニアが所属する「インプロセスQA」という体制を採用していました。しかし、プロダクトの成長と開発組織の拡大に伴い、この体制では対応しきれない課題が生まれてきました。この記事では、固定制からプール制への移行という大きな体制転換を、どのように設計・運用しているかをご紹介します。 1. これまでの体制：固定制インプロセスQA従来のQA体制では、各開発チー...

音声Botの「声が出たか」を人間なしで確認する方法を探していた。テキストBotの自動検証は前の記事で解決した。Claude専用のDev Botを作り、REST APIでPrefix commandを送信して応答を確認する方式だ。!前編の記事はこちら。Dev Bot作成・ALLOWED_BOT_IDS・discord-testスキルの基本構成を解説している。ClaudeがBotの動作を自力で確認する — Discord検証環境の作り方音声Botは違う。Botがボイスチャンネルで再生した音声を、REST APIで「受け取る」手段がない。人間がボイスchに入って耳で確認するしかない...

おっさんQAトーク第1回「AI時代のQAのキャリア」 唐突ですが「おっさんQAトーク」という、おっさんQA2人がテーマについて10分程度、やいのやいのと好き勝手トークするという動画企画をはじめました(笑) 聞き流し用にいかがでしょうか？ www.youtube.com 出演者 さかたさん まつや 第1回は「AI時代のQAのキャリア」について、2人で好き勝手なことを話しています。QA現場のAI活用の温度感(我々2人の)が出ている話になっています(笑) 今のところ、隔週でやっていこうと思っています。 ご興味ありましたら是非是非チャンネル登録を(笑) コメントもお待ちしております―！

COBOL現新移行検証シリーズ まとめ本シリーズは、ホスト系COBOL処理系からオープン系COBOL処理系への移行に携わる実務者を対象に、差異の構造と実機検証の設計思想を体系的に整理したものです。コンパイルエラーの有無ではなく、「動作が一致しているか」という観点から移行品質を捉え直すことを目的としました。 各回一覧 第1回【COBOL現新移行検証①】マニュアルに書いていない非互換とどう向き合うかhttps://zenn.dev/nttdata_tech/articles/f0610fa39d5bb8 第2回【COBOL現新移行検証②】実機検証の設計思想と検...

こんにちは！e-dashでQAエンジニアをしている10mo8です。AIエージェントにテスト設計をさせると、同じ仕様書を渡しているのに、出力されるテストスコープやテスト観点が毎回ぶれる——そんな経験はないでしょうか。AIは非決定的なので、ある程度のばらつきが出るのは仕方ありません。とはいえ、「どこを・何の観点で見るか」というテストの勘所まで毎回ずれるのは避けたい。このばらつきを最小限にしたくて、モデルベースドテストの考え方を取り入れてみたので、その内容について書きたいと思います。!本記事で紹介する検証結果は、あくまで弊社の環境における結果です。テスト対象の特性やモデルの生成方法、プロ...

こんにちは！e-dashでQAエンジニアをしている10mo8です。AIエージェントにテスト設計をさせると、同じ仕様書を渡しているのに、出力されるテストスコープやテスト観点が毎回ぶれる——そんな経験はないでしょうか。AIは非決定的なので、ある程度のばらつきが出るのは仕方ありません。とはいえ、「どこを・何の観点で見るか」というテストの勘所まで毎回ずれるのは避けたい。このばらつきを最小限にしたくて、モデルベースドテストの考え方を取り入れてみたので、その内容について書きたいと思います。!本記事で紹介する検証結果は、あくまで弊社の環境における結果です。テスト対象の特性やモデルの生成方法、プロ...

テスターの信頼構築——再現性のあるパターンバグを報告した。正確に書いた。でも開発者の反応は「ふーん」の一言で終わった——テスターなら、一度はこの経験があるんじゃないでしょうか。問題は、報告の質ではありません。あなたの話を、開発者は聞いていますか？戦略的思考の前提には、「この人の意見は聞く価値がある」と開発者に思われている状態が必要です。これがなければ、どんなに鋭い分析も、どんなに正確なリスク予測も、チームには届きません。この記事では、テスターが開発者からの信頼を獲得するための、再現性の高いパターンを整理します。「コミュニケーション力を上げよう」「仲良くなろう」といった属人的なアド...

テスターの信頼構築——再現性のあるパターンバグを報告した。正確に書いた。でも開発者の反応は「ふーん」の一言で終わった——テスターなら、一度はこの経験があるんじゃないでしょうか。問題は、報告の質ではありません。あなたの話を、開発者は聞いていますか？戦略的思考の前提には、「この人の意見は聞く価値がある」と開発者に思われている状態が必要です。これがなければ、どんなに鋭い分析も、どんなに正確なリスク予測も、チームには届きません。この記事では、テスターが開発者からの信頼を獲得するための、再現性の高いパターンを整理します。「コミュニケーション力を上げよう」「仲良くなろう」といった属人的なアド...

!個人で本番の SaaS を運用していて、決済も DR も法令対応も、自分ひとりと AI で回しています。その中で「これをやらないといつか事故る」という型がたまってきたので、実際に起きた事故をベースに全 6 回で書いてきました。①ガードレール / ②立ち上げ / ③文書=実装 / ④実行管理 / ⑤継続性 / ⑥検証（本記事・最終回）。「これで大丈夫?」と AI に聞いて、「大丈夫です、問題ありません」と返ってくる。それで安心していた時期がありました——少し前まで、自分はそれを確認だと思っていたんです。でもそれは検証じゃなくて、祈りでした。AI の「大丈夫です」は、第 1 回のお...

「動いているのに正しくない」Python コードを生む定番の落とし穴を、再現コードと修正コードの両方で解説する実践書。可変デフォルト引数、ループとクロージャの遅延束縛、例外設計、浮動小数点、文字列とエンコーディング、コピーとエイリアス、並行処理の罠まで。すべてのコード例はビルド時に実行検証している。

The commissioning of the NSF-DOE Vera C. Rubin Observatory required coordinating the planning, design, and execution of hundreds of integration and on-sky tests involving different subsystems and geographically distributed teams. To support this task, we adopted a Jira-native test management tool, Zephyr Scale. The initial use of Zephyr Scale focused solely on system verification and validation. Its use was rescoped to coordinate higher-level tests, and it is still in use in early operations. Ze

生成AIで実装を進める機会が増えてきました。簡単なCRUDだけでなく、管理画面やフロント画面までAIに作らせることも珍しくありません。そんな中、実際に遭遇した「AIらしい」不具合を紹介します。今回の構成今回のシステムはシンプルです。バックオフィスで記事を作成...

はじめに：なぜリグレッションベーススプリントを重ねる毎に積み上がる既存要件、どんどん増えるリグレッションテストの管理に悩んだ経験のある方は多いと思います。実施の時間が取れない、なら自動化だ。と言っても管理まで手が回らず、新規で動かしたテストをそのままリグレッションテストで回す事もあるかも知れません。そこで、5-6年前から展開している「リグレッションベース」という考え方をざっくりご紹介しようと思います。そんな考え方もあるんだ、位で読んで頂けると幸いです。 スプリントを重ねるほどQAが苦しくなる理由現象： スプリントの積み重ねによる「影響範囲」の拡大。課題：スプリントでリリ...

Tabiji というテストラッパーを作りました。Vitest等の既存のテストランナーを薄くラップしてHonoライクなメソッドチェーンで書けるようにするライブラリです。https://www.npmjs.com/package/tabiji試してみたい方はStackBlitzへhttps://stackblitz.com/edit/vitejs-vite-glgltcmf?file=sample.test.ts&terminal=test&view=editorこんな書き方が出来るようになります。sample.test.tsimport { Tabiji }...

はじめにこんにちは！e-dashでQAエンジニアをしているpulasQです！QAをやっていると、リグレッションテストなどのテスト資産の管理が大変だと感じたことはありませんか？弊社QAチームではQaseというテスト管理プラットフォームを使っているのですが、様々な作業をAIに任せることで、かなり楽になりました。この記事では、弊社でやっている仕組みに加え、私が普段行っている作業のTipsをお伝えできれば良いなと思います！ 前提：弊社のテスト成果物が作られる流れ本題に入る前に弊社QAではどのようなテスト活動のフローによってテスト資産（テストケース）が生まれていくのかについて触れ...

こんにちは、エクスプラザの@_mkazutakaです。ここ1〜2ヶ月ほど、AIエージェントに細かく指示せずにどこまでちゃんと動くアプリが作れるかに向き合っていました。試した仮説はシンプルで、「ユーザーストーリーを可能な限り書いておけば、エッジケースを除いてきちんと動くアプリケーションができるのではないか」というものです。ユーザーストーリーを書いて、テストを書かせて、テストが通るように実装させる。これでいけるだろう、と。結果、テストは全部通った、コードも良さそう。が、しかし、実際に触ってみるとなぜかうまく動かない。よくよく調べてみた結果、ユーザストーリーじゃだめやないかという。この記...

こんにちは。ナレッジワークの torii です。Playwright で実施している E2E テストに新しいカバレッジ指標「ページ網羅率」と「RPC 網羅率」を導入したので紹介します！ 背景: 手動によるカバレッジ管理の信頼性低下ナレッジワークでは、プロダクトの継続的な品質保証のために E2E テストがどこにどれだけ書かれているかを管理しています。また、カバレッジを次のように定義して追ってきました。E2E テストのカバレッジ = 書かれているテストケースの数 / 書くべきテストケースの数この定義自体は妥当なものでしたが、運用する中で次のような問題が出てきました。「書くべき...

この回は、テスト計画やリリースの可否に関わり始めた人向けです。「これで十分か？」「もうリリースしていいか？」を問われる立場になってきた、そんな段階の人を想定しています。 前回のおさらい前回、確認はいくらでも設計できるという話をしました。高さ（単体・結合・システム）ごとに、継ぎ目ごとに、確認はいくらでも増やせます。そして、最後にこう言いました。何を確認できるかは、設計すれば分かる。でも、どこで止めていいかは、設計しても分からない。今回は、その止めどきの話です。 「十分」に、唯一の正解はない新人のころは、「全部テストすべきだ」と思いがちです。でも、全部は確...

「動作を変えずに作り替えたい」から始まる1ファイル数千行が珍しくない——そんな規模のプロジェクトに出会うことがあります。数年前に作られ、運用されつづけ、今ではdeprecatedな古い関数も多く残っている。いずれ大きくリファクタしたい。条件は一つ、振る舞いを一切変えないこと。だから先に「現状動作を保証するテスト」を用意したい。ここまでは、たいてい全員が合意します。立ち止まったのはその次でした。巨大なファイルの中では、ロジックがしばしば外に出ていない（未exportの）まま埋め込まれています。これを単体テストするには、まず関数として切り出さなければならない。けれど、切り出すことそ...

!現時点での研究・事例をもとに、2027〜2028年の開発体系を考察します。先日、シニアエンジニアがコードをほぼ書かなくなった理由という記事を投稿した。人間は仕様を書き、AIに実装を任せる。——現在ではほぼ1パーセントしかコードを書いていない。という話だ。https://zenn.dev/acntechjp/articles/22f7b6f9258008ありがたいことに多くの反応をいただいたが、まだ課題があると考えている。AIはコードを書けるようになった。では、テストは誰が保証するのか。現在はテスト設計を人間が行い、テストコードをAIが書いている。しかしこの分業にはすで...

QAエンジニアとして、自分のロールがどこに向かうかについての仮説を持ってこのカンファレンスに参加しました。テストを実行する要員から始まり、品質のエバンジェリストとして組織に語りかける段階を経て、次に来るのは「作りすぎない」という規律などAI-Nativeなプラットフォーム整備だという感覚があります。続きをみる

This is the test page.

はじめに本記事はWACATE2026夏のワークの中で行った、「テスト技法の練習問題を作問する」というワークの成果物を一部調整したものです。想定解答をつけていますが、あくまでそういう回答もあるよねくらいのお気持ちで見て頂ければと思います。[共通仕様]ポイントを付...

人の一生には、土台が据えられる時期があります。新卒社員として迎える最初の季節、とりわけ入社して間もない研修のひとときは、その人がこれから歩む数十年、すなわち職業人としての道のりも、一人の人間としての生き方も、その根を静 […]

こんにちは。e-dashでQAをしています、rinです。チームの作業量が見えないと、困ることって意外と多いんですよね。特定の人に負荷が偏っていても気づきにくいし、状況を共有する手段がない。誰も全体像を把握していないまま、なんとなくで回っている状態が続いていく。見えないことの怖さというのは、問題が起きるまで問題だと認識されないところにあると思います。まずは、どこに問題がありそうか、問題になりそうかを見えるようにする必要があると考えました。この記事は、QAチームの作業量や負荷の偏りをデータで見えるようにしてみた話です。 肌感はあるのに、根拠がないe-dashのQAチームで...

こんにちは。e-dashでQAをしています、rinです。チームの作業量が見えないと、困ることって意外と多いんですよね。特定の人に負荷が偏っていても気づきにくいし、状況を共有する手段がない。誰も全体像を把握していないまま、なんとなくで回っている状態が続いていく。見えないことの怖さというのは、問題が起きるまで問題だと認識されないところにあると思います。まずは、どこに問題がありそうか、問題になりそうかを見えるようにする必要があると考えました。この記事は、QAチームの作業量や負荷の偏りをデータで見えるようにしてみた話です。 肌感はあるのに、根拠がないe-dashのQAチームで...

今週のテストラジオは、夏の扇風機トークから始まりつつ、メインはイベント …