「カバレッジ100%は手段の目的化」という批判は昔からあります。それでも私たちのWebサービスリポジトリ（イベント予約・LINE連携・決済まわり）は、**stmt / branch / func / line の4指標100%**を開発初期から一度も緩めずに運用しています。開発の主体はAIエージェント（Claude Code / Codex）です。この記事は「100%にすべきか」の議論ではなく、100%を敷いた状態でAIに開発させると何が起き、どういう運用ノウハウが溜まったかの記録です。カバレッジゲートそのものがバグっていた事故も含めて書きます。 なぜAI開発と100%ゲートは相性...

はじめにAIにコードをたくさん書かせると、何をしているかを表すWhatコメントをたくさん書く。Whatコメントはコードの修正時にコメントのメンテナンスが発生するので保守性がよくない。ちなみにWhatコメントはこういうの// 商品の価格をorderItemのpriceにセットするconst orderItem = { productId: product.id, price: product.price, quantity,};一方Whyコメントはこういうの// 商品マスタの価格は後から改定されるため、注文時点の価格をorderItemへ複製して保持するco...

はじめにAIにコードをたくさん書かせると、何をしているかを表すWhatコメントをたくさん書く。Whatコメントはコードの修正時にコメントのメンテナンスが発生するので保守性がよくない。ちなみにWhatコメントはこういうの// 商品の価格をorderItemのpriceにセットするconst orderItem = { productId: product.id, price: product.price, quantity,};一方Whyコメントはこういうの// 商品マスタの価格は後から改定されるため、注文時点の価格をorderItemへ複製して保持するco...

普段は IVYXON というサイトで、SEC の開示データなどの一次情報を使った米国株の実測記事や自作ツールを公開しています。今回のUS Stock Time（米国株の取引時間を表示するツール）もその自作ツールの一つで、これはiOS版をAndroidへ移植したときに踏んだ話です。 背景iOS版（Swift）で作っていた「米国株の取引時間を表示するアプリ」をAndroid（Kotlin）に移植しました。祝日判定・サマータイム判定・市況ステータス（プリマーケット/レギュラー/アフターマーケット/休場など）・カウントダウン計算——このあたりのコアロジックを、Swiftで書かれたものを読み...

AI にコードレビューを頼むと、もっともらしい指摘が並びます。しかし、確認せずに上から順に直すと、壊れていないコードまで変えてしまうことがあります。 反対に、指摘の結論が間違っていたために、その中に含まれていた正しい観察まで捨ててしまうこともあります。手元に、AI の指摘のうち「これは誤りだ」と判断したものだけを集めた記録があります。今日数えたら 142件ありました。1件ずつ、どこがどう違うのかと、その根拠（実行したコマンドと結果、該当するファイルと行番号）が書いてあります。以下、この記録を「誤指摘台帳」と呼びます。これは誤りと判断した指摘だけを集めた記録なので、AI レビュー全体...

前回、自作のリンタを他人のリポジトリ230本に当てたら8割が誤検知だった、という話を書きました。最後に、人に配るものを作っているなら告知の前に30分だけ実データに当ててみてください、と書きました。その記事を出した日に、聞かれました。今公開してるやつのテストはしなくていいの、ちゃんと動くの、と。何も言い返せませんでした。私が公開しているのは全部で7本で、実データに当てたのは carrylint 1本だけです。残りは、自分で書いたテストが緑になっているだけでした。というわけで、まだやっていなかった4本に同じことをやりました。tracklint（フォームの計測配線）、tokenlint（...

はじめに皆さんテストコードをどのように関していますでしょうか？まとめて管理していて、テストの責務が曖昧になったテストコードが実装されたり、テストの実行を分けられなくてCIが遅くなったりしたことはないでしょうか？そんなときは物理的に境界を分けてしまえばいいのです。本記事では、各テスト種別の定義や実行コスト・メンテナンスコストを改めて整理し、その観点からテストコードを物理的に分割するメリットについて解説します。 テスト種別について皆さんは単体テスト、結合テストと聞いてその役割を的確に答えられますか？正直結構怪しかったり、人によって定義が違うなんてこと結構あるのではないでし...

何が起きたか6日前に公開した記事に、年ごとの集計を載せていた。「同じ手順で誰でも再現できる」と書いて、ツールが出した表をそのまま貼った。今日、まったく別の目的でそのツールを回したら、同じデータから違う表が出た。年 公開時(7/25) 現在(7/31)2021年 ¥ 143,580 19件 ¥ 130,640 18件2022年 ¥ 923,930 196件 ¥ 932,270 196件2023年 ¥1,059,450 250件 ¥1,064,050 251件 ← 現在のピーク2024年 ¥1,078,...

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

設計書に渡す情報を増やすと、LLMのテスト仕様書は良くなるのか？ A〜D条件で比較してみた※本記事はAIを利用して推敲しています。※検証に使用したLLMはChatGPT Work(5.6 Sol)はじめに「画面設計書だけLLMに渡せば、そこそこ使えるテスト仕様書...

はじめに 「言語化」の定義とフェーズ フェーズ1：状況の整理 フェーズ2：気づきの深化 フェーズ3：他者への伝達 言語化は感覚と論理の橋渡し 言語化を鍛える 言語化の制限 おわりに はじめに システム開発の現場では、自身の意見を伝えたり、出会った現象を伝えるために「言語化」が求められます。とくにソフトウェアテストにおいて、違和感に出会ったときの感覚を他者に伝えるために「言語化」が必要だと考えています。 ただし、「言語化」はよく使われる言葉ではありますが、その使われ方は多岐にわたるため、同じ「言語化」という言葉が、異なる範囲を指して使われることで、認識ずれが発生する場合があります。 本記事では、…

Androidアプリにレビュー促進ポップアップ（In-App Review）を実装したものの、「テストで一向にダイアログが表示されない」という壁にぶつかりました。当初は内部テストトラックで表示テストを試みていましたが、うまく表示されず。そこで内部アプリ共有（Internal App Sharing）を試したところ、無事に表示させることができました。この記事では、内部アプリ共有を使ったIn-App Reviewのテスト方法を手順として残しておきます。 なぜ内部テストトラックではうまくいかないのかIn-App Reviewのダイアログは、Google Play側のクォータ（表示回数...

序 プロダクト開発においては、もうAIエージェントを用いるのは当たり前になりましたね〜。私ももうコードは書いてません。 一般化に伴い「AIめっちゃすごいじゃん」みたいな論調は落ち着いてきた印象ですが、まだ各々の印象のばらつきは大きいように思います。 ということで、QAエンジニアとしての個人の感覚を書きます。お分かりの通り、タイトルは反語です。 「ゲームチェンジャー」 考え方を根本から変える、大変革をもたらす何か*1、と捉えています。インターネットとかスマホとか？そういうレベルですかね。 序 「ゲームチェンジャー」 AIが変えたもの/変えなかったもの 開発プロセス全体 実装 テスト 自動テスト …

外部サービスへ投稿するスクリプトを、いつもと違う仮想環境で動かしました。結果は「投稿は成立したのに、スクリプトは落ちた」。落ちた原因は通信でもサービス側でもなく、手元のライブラリの版が違ったことでした。同じことをやりそうな人向けに、何が起きたか・なぜ既存のガードで防げなかったか・どう塞いだかを残します。 起きたことスクリプトの流れはこうなっています。投稿するレスポンスから投稿 ID を取り出すその ID にぶら下げて、続きの投稿（自己リプライ）を足す2 で落ちました。AttributeError、つまりレスポンスにあるはずの属性が無い。問題は落ちた位置です。1 はす...

以前、テストはどこまで書けばいいのか、個人開発で見つけた3つの線引きという記事を書きました。エラーケースは理論上いくらでも増やせるので、どこで止めるかを決めた話です。その線引きで書いたテストが21本すべて通っている状態で、機能が壊れていました。線引きの問題ではなく、単体テストという道具では見えない種類のバグでした。その構造が面白かったので書きます。 症状バーベルのプレート計算アプリで、目標重量を増減する ± ボタンがあります。在庫設定（どのプレートを持っているか）によって、挙動が3種類に分かれていました。刻み＋を1回押す−を1回押す判定1kg3k...

Claude CodeやCodexに、同じ注意を何度も書いていないでしょうか。「変更後はテストして」「このディレクトリは触らないで」「前と同じ形式で実装して」その場では直っても、別のセッションではまた同じミスが起きる。モデルを高性能なものへ替えると頻度は下がりますが、ゼロにはなりません。結論から言うと、必要なのはプロンプトの追加ではなく、AIが間違えにくく、間違えても自分で検知できる開発環境です。ここでは、その環境を「ハーネス」と呼び、次の5層へ分けて設計します。希望を観測できる受け入れ条件へ変え、どの試験層で守るかまで決めるプロジェクト知識をリポジトリへ置く守る条件...

DBにURLは残っているのに、先週生成したファイルだけ開けない。生成AI APIをバックエンドに組み込むと、このような時間差のトラブルが発生します。原因は、生成結果として返されたURLを、そのまま永続ファイルとして保存していることです。タスクがcompletedになっていても、そのURLが将来も利用できるとは限りません。この記事では、生成AI APIから返されるoutputsをPythonで安全に回収し、不正URLの拒否ファイルサイズ制限MIME type確認atomic保存hashによる完全性確認まで含めたartifact管理の考え方を整理します。 想定読者...

TL;DR統一APIでも、モデルごとの入力schemaは同じではありません。業務コードは共通のImageRequestだけを扱い、差分はAdapterに閉じ込めます。モデル追加時は、実行schemaの確認とpayloadの完全一致testをセットにします。 想定読者と検証環境想定しているのは、画像生成APIで複数モデルを切り替えるbackend開発者です。特に、model IDを環境変数にしたものの、切り替えるたびにcontrollerのifが増える場合を対象にします。Python 3.12.13標準ライブラリのみschema確認日: 2026-08-07...

「テストは全部パスです」「0件でした」「直しました」エージェントの報告は、たいてい正しいです。正しくないのは、それをこちらが読んだ意味のほうです。30の場面ごとに「そのとき何と訊くか」を1つずつ置いていきます。「通りましたか」ではなく「壊したとき、何が落ちましたか」と訊きます。それだけで、報告の中身が変わります。AIを仕事や開発で使う人が、実際に読み違えた30の記録です。モデルの名前は1度も出てきません。扱うのは、報告を受け取る側の読み方だけです。

最新のWindowsおよびVisual Studioのアップデートにより、Ranorex Studioと互換性のないMicrosoft MSBuildのバージョンがインストールされる場合があります。このMicrosoft […]The post Microsoft MSBuildのアップデートによるRanorex Studio エラーの対応方法 first appeared on テスト自動化ツール 『Ranorex』.

この記事の要点を3行で。初日に決めたのは「テストを触るな」ではなく、「どういう時なら触っていいか」の分類だったテストが109件すべて通っている状態で、実機では敵の攻撃が当たらないということが起きた最終的に「テストはゲームの仕様そのもの。ただし仕様が変わったときだけ書き換える」に落ち着いた。そのために、どのテストが何を守っているのかをコードにラベルで書いている前回書いたUE5のC++に自動テストを入れた記録の続きです。前回は「どう入れたか」、今回は「入れた後どう運用しているか」の話になります。この記事も「こうすべき」ではなく、私がこう考えてこう運用しているという記録です。...

こんにちは、tekuteku です。今回は Go の単体テストで使う fake を、interface から自動生成する仕組みと、生成物ならではの落とし穴を整理します。 fake とモックの違いテストで本物の代わりに差し込むものは、まとめてテストダブルと呼ばれます。よく使われるのは 2 種類です。モックは「呼ばれ方」を検証します。どのメソッドが何回、どんな引数で呼ばれたかを期待値として先に宣言します。期待どおりに呼ばれなければ失敗します。fakeは「動くけれど本物ではない実装」です。たとえばデータベースの代わりに、メモリ上のスライスへ保存する実装を用意します...

今月の8月28日に、執筆した「ソフトウェア品質保証ガイド チームで顧客満足を実現するためのアプローチ・手法・技術」が発売されます。https://www.kadokawa.co.jp/product/302607002896/ この本は、顧客満足を実現する活動を品質保証とし、ソフトウェアプロダクトの開発から運用までライフサイクル全体に求められる品質保証活動について解説しています。 読者はQAエンジニアに限定せず、開発チームに関わるエンジニアやマネージャ全般に広く読んでいただくことを想定して執筆しました。 トピックとして次のような内容を扱っています。 シフトレフトや品質の積み上げの実践 開発と運…

美容系勤務独学初心者マリー・アントワネット系エンジニア目指してます！今回は AIの実力差が公開ベンチマークで分からない なら 一生使える自分専用のベンチマークを作ればいいじゃない 👸🍰です。読了時間の目安：約 18〜22分（結果だけ見たい方は第8章に飛んでOKです📊）!3行まとめ前回「Gemini 3.6 Flash が Opus 5 と互角だった」と書いたのは、課題が易しすぎただけでは？ という疑いを晴らすため、天井の高い課題を自作しました🧪落ちものパズルで4段の課題を出したところ、レベル1〜3は3体とも満点。壁蹴り（SRS）も7-bagもT-Spin判定も、全員が...

AI（Claude Code）に自動売買システムの設計・実装・運用・改善を丸ごと任せた実験の記録です。最初のシステムはバックテストで年率+360%を出し、実運用でマイナスになりました。原因はデータリークでした。そこから作り直す過程で確立した「AIに任せても壊れないための手続き」を、実際のコードと失敗事例つきでまとめます。宣言ゲート、ガードテスト、ルックアヘッドを構造で防ぐ設計、そして「改善したと見えたときに疑う方法」まで。

「仕様書を書くくらいなら、テストを書いて渡せばいい」という言い方があります。動く形で条件を渡すのだから、文章より確実だろう、という話です。今回はそれを Claude Code の claude -p(対話せずに1回だけ指示を投げて結果を受け取る使い方)で実際に試しました。結果、テストだけを渡しても、テストの答えを丸写しするような場当たりの実装にはなりませんでした。生成側に一度も見せていない「隠しテスト」8件を、15本の生成物すべてが全通過しています。ここは正直、拍子抜けでした。崩れたのは別の場所です。テストでは実質的に固定できていなかった1か所、「幅を指定しなかったときの既定値」が、...

これはパイプラインのテスト記事です。Print("ここで追記のテストをしておきます。")

テスト観点は「出す」より「削る」ほうが難しい。前回の記事で「テスト観点の書き方」を紹介しました。画面要素を列挙する、仕様書から名詞と動詞を抜き出す、AIに壁打ちする。これで「出す」はできるようになります。でも、出した観点を全部テストできますか？!この記事を読んでほしい人テスト観点の出し方は覚えた。次に「絞り方」を知りたい人AIでテスト観点を出してみたけど、量が多すぎて困った人「何をテストしないか」の判断に自信がない人試しにClaudeに「ECサイトの決済機能のテスト観点を出して」と投げてみてください。100個くらい、平気で出てきます。正常系、異常系、境界値、セキュリ...

Hardcoded secrets in source code pose critical security vulnerabilities which can be easily exploited by malicious adversaries. Existing regex-based detection approaches suffer from fundamental limitations, as secrets often lack identifiable patterns, resulting in poor precision and recall. Recent studies have explored context-aware detection methods, as surrounding code can reveal the purpose of candidate strings. However, these methods confront three key challenges: (1) obfuscation robustness

1. はじめに — 生成は一瞬、レビューが重いどーもりょうさんです。自分はQAエンジニアで、普段のテスト設計に生成AI (Claude) を使っています。AIにテスト設計をやらせ始めた人が、だいたい最初にぶつかる壁があります。生成は一瞬なのに、出てきた成果物のレビューが重い。観点も、テストケースも、期待結果も、待っていればいくらでも出てきます。体裁は整っている。仕様の条項もちゃんと引いている。ただ、その一件ずつが本当に妥当かどうかは、見なければ分かりません。そして見る側は一人で、時間は有限です。生成の速度が上がった分だけ、レビュー待ちの山が高くなる。このとき、選択肢は二つに...

こんにちは。SmartHR品質保証本部、人事マスタユニットのkanna、kaomiです。 2026年3月に公開した「SmartHRの人事マスタを守る —— QAエンジニアとして挑む、品質保証の現場」では、人事マスタユニットが抱える品質保証の課題と、それに向き合うために始めた取り組みを紹介しました。 前回の記事から数か月が経ち、私たちは開発チームとともに、品質リスクを開発の早い段階で見つけ、継続的に改善する仕組みづくりを進めています。この記事では、前回お伝えした取り組みの続編として、人事マスタエリアで求められる品質保証と、QAエンジニアが現在どのように「信頼性」を支えているかを紹介します。 人事…

[特定非営利活動法人ソフトウェアテスト技術振興協会][画像: https://prtimes.jp/i/54604/57/resize/d54604-57-af7533fbb1b175e81342-0.png ]JSTQB（ソフトウェアテスト技術者資格認定組織）は、2026 年 10 月 16 日 （金） に「JSTQB カンファレンス in 2026 Autum...

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。 こんにちは。QA外部コネクトチームのmassanです。QA外部コネクトチームは2025年8月に発足した後、前身の主なタスクだったカンファレンス協賛以外にも様々な試行錯誤をしてきました。今回はそれらをエネルギー効率の観点から振り返ってみようと思います。 発信も応援もエネルギーがいる 私たちはサイボウズのQAメンバーと社外との繋がりを作る活動をしていますが、その一環として外部発信の応援をしています。そして外部発信は想像に難くない通り、発信者のモチベーションに大きく依存します。つまり、「発信したくない」負荷と「発信したい」…

今回は、よしたけが参加してきたJaSST’26 Hokka …