ソフトウェアテストを検査しよう

ソフトウェアテストを 検査しよう やまずん Scrum Fest Mikawa 2026 2026.9.12 11:00＠Room C Short Session(20min)

2

3

“いいテスト”ってなんでしょうか？ 4

テストや品質に対する謙虚な姿勢 テストって 難しい 品質 なんもわからん 5

よくある嬉しい言葉 QAさん最高！ 安心して開発が できます！ 6

うれしい 7

それでいいのか？私 “私たち” 8

9

みなさんはテストを“検査“していますか？ 10

やまずんとは ⚫ System Fixer/バキバキQA/Dirty Tester ⚫ フリーランスのSystem Fixer ⚫ 大阪のテスター ⚫ 去年から10キロくらい痩せた ⚫ テストプロセス改善を飯の種にしている ⚫ 大腸内視鏡検査で一命を取り留めたことがある ⚫ testingOsaka/テストの街葛飾/WARAI ⚫ 今週から詩を書くことにハマってる 11

この発表の注意 ⚫ やまずんは自分のことしか代表しません ⚫ 所属する団体や世の中のQAエンジニア・テスターの見解を代表 するものではありません ⚫ （資料を後で見る人向け）スライドに記載された内容が全 てではなく、口頭で補足した内容もあります 12

この発表のゴール ⚫ 「テストのあり方」を検査する ための問いの立てることができ る ⚫ 自分自身のテストについて批判 的に捉えるきっかけにして、一 段高い適応を呼び込むことがで きる 13

検査ってなんなの？ 14

検査とは 検査とは、現実を見ることである。 プロダクトの方向性（プロダクトゴール）と スクラムチーム・ステークホルダーの有効性 検査ってなんだ かテストっぽい よね！ を確認する。検査によって適応が可能になる。 スクラムガイド拡張パック p.8 15

みんながやってるスクラムの検査 スクラムにおける検査 •不確実な現実に対する妥当性の確認 •仮説と事実のギャップを学習し、適応に繋げる •現実の背後にある「構造やシステム」を認知する やまずんは できてるのか な？ スクラムじゃなさそうな検査 •プロセスや標準への準拠の形式的な確認 •単なる結果の確認と報告 •起こってる現実を個別に認知する 16

17

みなさんはテストを“検査“していますか？ 18

我々はテストを検査できているのか？ ⚫ 「テストなんもわからん」「品質難しい」 ⚫ 聖域扱いとなっていないか？ ⚫ 逆も然り やまずんがいる からそんな悲し いことが起きる んじゃない？ ⚫ Dev・PO・SM「テストエンジニアありがたい^^」 ⚫ 「嬉しい！自尊心が満たされる」 ⚫ 「いい雰囲気だ！最高のチーム！」 19

20

我々はテストを検査できているのか？ ポジ 無批判にテスターや QAを受け入れる ニュートラル テストを「専門家の知 識」として外部化する ネガ テスターを 「素人」と見下す ※現代ではテス ター自身の声で あることが多い 気がする ⚫ むしろチームが現実と向き合う力が失われていないか ⚫ 本来の意味での「心理的安全性」がないチームが よりにもよって”テスト”や”品質保証”に投影され、現れてしまう 21

アジャイルチームやテストの専門家として やまずんが陥った 検査のアンチパターン 22

標準への準拠だけで満足する ⚫ JSTQBに従っているか？ ⚫ 国際規格に従っているか？ ⚫ ソフトウェアテストのアセスメントモデルの単純適用 それってテスト 界隈への冒涜 じゃない？ 「教科書ではこうだから現実がおかしい」（スクラムでもあるよね） 教科書を元に現実を認知し、有効性を評価している状態 “正しい”プラクティスでも、 “正しく”文脈を理解し、”正しく”文脈を設定しないと適応に繋がらない ※もちろん教科書が間違ってることもある 23

「私たちは対話できているし仲がいい」 ⚫ 信頼できる、心地のよいテストの時間 ⚫ そこに気づきはあるんか？ ⚫ “人間性を尊重する優しい対話” ⚫ “心地よい空間” やまずんがいる からせいでみん な仲悪くなるん だよ ⚫ テストに対する批判的検討がない ⚫ 居心地はいい、進捗は進む、でも、チームとして前には進まない ⚫ ※仲がいいことはダメではないよ そこにあるのは「事実」なのか？ 安心のために現実が歪められてはいないか？ 24

自分の現場を見失っている ⚫ 「他の会社はこうしているからそうしよう」 ⚫ 「有名人がこういっているからそうしよう」 ⚫ 「一般的に、高い（または低い）品質水準を求められ るから」 やまずんは自分 の仕事を見失っ たけどね 「テストはコンテキスト次第」 過度な一般化により、個別に向き合うべき現実を 見失っていないか？ 25

参考：主なテストプロセス改善モデル ⚫ ISO ⚫ TMMi やまずんは登壇 ごっこしてな い？ ⚫ TPI 出典：ASTER これらは強力なツールなので学ぶのはおすすめ でも、単純適用をしてしまうと、自律改善する力を失う そうなってしまうと「テストプロセス改善ごっこ」になっちゃうかも （気をつけてな） 26

検査の前提となる透明性 ⚫ そもそも透明性がないと検査ができない ⚫ 「テスター（QAエンジニア）」への依存が不透明性を増長していないか？ ⚫ という旨の発表を去年した ⚫ 他方、検査の気持ちがないと透明性もできないかもね この発表に人に 理解してもらお うという透明性 はあるんか？ 27

ソフトウェアテストの 検査をしよう 28

検査のための視点 ⚫ スクラムの文脈で考える ⚫ 「適応が可能かどうか」 ⚫ 「その適応の質は高いものか」 適応ができる検 査に意味があ るって話もある もんね 「テストの目的」を考えてから考えてもいいけど、 「ソフトウェアテスト」の目的やその言葉に込められた願い（先入観）は個別、かつ自覚できないことが多い この発表は別のアプローチを考えてみる 29

検査するためのキーワード 仮説検証 構造 絶対適当に考え たやろ コンテキスト 違和感 ※本セッションでのバグの定義：なんか都合の悪い事実 30

どのような仮説検証ができているか？ 伸び代 「なぜこのテストが必要なのかよくわからない」 「そのテスト結果がどんな意思決定に役に立っているかわからない」 「バグゼロだけど売れなかった」（バグゼロの落とし穴：亜種） 問い 狙ったバグは出ているか？ 本番環境でのバグはどのようなものか？ きちんと売れているか？ 検査 N=1問題にの可 能性を見落とし てない？ 文系なんだから ちゃんと科学の 勉強しろよ （やまずんが） 当初計画していたバグの量・質（この表現は好まないが）は達成できているか？ テスト(事実を見ること)によって何が得られたか？ 31

構造の問題として捉えられているか？ 伸び代 「すみません、ミスでした。すぐ直します」 「ネクストアクション：チェックリストに追加する」 「プロセスが悪いので見直します」 問い 個別のバグやテストの成果物から、構造的な問題についての気づきがあるか なんでもかんで も構造の問題に しようとするの にやまずんの浅 はかさがあるね 何かのバグに対して、根本的な対策が可能なだけの情報があるか？ バグがないことも構造の問題として捉えることも大事 検査 そのバグは防げたものなのか？（向き合ってみて！） そうだとしたら、それが再発しない、かつ持続可能な対策はできるか？ 32

コンテキストに対する適合があるか？ 伸び代 「この品質特性がどんなユーザーのニーズと紐づいてるかわからない」 「バグが見つかったけど、これは仕方ない。どうにもできない」 問い ”いまここ”において必要(不必要)な情報が吟味されているか？ コンテキストに 迎合しすぎて都 合のいい報告し かしない人いる んじゃない？ いまの延長線上に過去や未来もあるけどな！ 検査 テストの報告に関して、「誰」が「何」を見ているか把握できているか？ そのテスト、ほんまに「今」「ここで」必要(or不必要)なんか？ 33

違和感に向き合えているか？ 伸び代 「“開発者さん”は何も悪くない」 「“開発者”がちゃんとやってないから悪い」 問い 事実に対して違和感が立ち現れても、冷静に受け止められているか？ この発表自体に 違和感があるん ですが、、 「テスト」や「品質」という言葉でそれらの違和感を外部化していないか？ 検査 「バグ報告を見るのが辛い」という声 「テストはテスターがやること、開発は開発者がやること」という気持ち 34

テストに全ての人が主体的に関わる 35

Real testing is always learning. Taking Testing Seriously: The Rapid Software Testing Approach p18 書影:RAPID SOFTWARE TESTING 36

テストを検査するためのガイドとしての“探索“ テスト完了＝チェックした＋探索した Explore It! p32 テストの本ですが、プロダクトマネージャーやプロダクトオーナー、つまり要件を定義する人 にこそ読んでほしい一冊です。AIがコードを書く時代に求められているのは、コーディング技 術ではなく、プロダクトのふるまいを探索し、驚きを発見する探検家。 Yasunobu Kawaguchi 書影：KADOKAWA ⚫ テクニックとしての探索的テスト ⚫ これをあり方としたのが『Rapid Software Testing』 37

「テストを検査する」とは、テスト結果だけでなく 「我々のテストのあり方・向き合い方そのもの」 を評価し、適応させることだ やまずん 38

テストはすべての人が主体的にかかわるべきものだ ⚫ 「テスト」は現実や事実を見るためのレンズであると捉える ⚫ 同時に「テスト」というレンズ自体も 正しく役に立っているかを知る必要がある 「私はテストの専門家じゃないんで、、」 「我々のテストはどうなっているかなあ？」 ⚫ 「我々はどんな現実を見ればいいのだろうか？」 ⚫ これを見直す手段のひとつが「テストを検査する」ということ 39

テストへの検査を通して Whole Team Approachを実現しよう！ ソフトウェアテストを 検査しよう 40

参考文献と感謝 いつもありがと ね〜 イラスト：タスマニアデビ男 【引用文献】 • James Bach, Michael Bolton (2025). 『Taking Testing Seriously: The Rapid Software Testing Approach』 Wiley. • エリザベス・ヘンドリクソン (著), スクラムフェス新潟 (翻訳) (2026). 『Explore It! プロダクトの価値と自信を高める探 索的テスト実践ガイド』 KADOKAWA. • Ralph Jocham, John Coleman, Jeff Sutherland (2025). 『スクラムガイド拡張パック：オリジナルのスクラムガイドの 適応版』 • ASTER テストプロセス改善技術研究会 (2020). 『テストプロセス改善技術 入門ガイド』 NPO法人ソフトウェアテスト 技術振興協会. https://www.aster.or.jp/business/testprocess_sg.html • kawaguti (2026). 「『Explore It!』——プロダクトのふるまいを探索し、驚きを発見する探検家のために」 kawaguti’s diary. https://kawaguti.hateblo.jp/entry/2026/08/27/113737 【参考文献】 • 私たちはなんでテストするんだっけ? Ver.東北IT物産展2026 in 会津若松、https://speakerdeck.com/camel_404/haveyou-lot-ever-actually-stopped-to-think-about-why-we-test-in-product-development、おおひらゆうすけ 【謝辞】 • テストプロセス改善技術を教えてくれたテスト会社 • 現場に向き合わせてくれたクライアントの皆様 • 一緒に頑張ってくれたチームのみんな • 生きることの辛さ • ペイン • R.I.P. Kyoko Kitano 41

• https://speakerdeck.com/camel_404/have-you-lot-ever-actually-stopped-to-think-about-why-we-test-in-product-development