テストを使って透明性を獲得しよう

テストを使って 透明性を獲得しよう Scrum Fest Mikawa 2025 2025.9.6 Short Session(20min) やまずん Dirty Tester バキバキQA

ひと昔前に よく言われた 2

スクラムに （アジャイルに） テスターは不要 3

4

5

確かにそうかもしれん 6 ※スクフェス大阪2024 私が大切にしている「テスターとしての批判精神」

じゃあテスターが不要になるように みんなにテストのことを知ってもらおう 7 ※スクフェス大阪2024 私が大切にしている「テスターとしての批判精神」

その第一歩としてテストを通してスクラムチームが 透明性を獲得するための提案をします これが当初のプロポーザルの タイトル 8 ※スクフェス大阪2024 私が大切にしている「テスターとしての批判精神」

この発表の注意 ⚫ 所属する団体や世の中のQA・テスターの見解を代表するものではありません ⚫ やまずんは自分のことしか代表しません ⚫ やまずんの発言だけを見て「やっぱりテスターは...」って言うのもやめてね ⚫ やまずんよりすごい人は山ほどいます ⚫ JSTQBや国際規格やアジャイルテスティング、その他プラクティスを忠実に 紹介するものではありません ⚫ やまずんの個人的な体験に基づいた活用法を話します ⚫ テスト技術のすべてを話すわけではありません ⚫ やまずんにはその実力はありません。一介のテスターです。 ⚫ （資料を後で見る人向け）スライドに記載された内容が全てではなく、口頭 で補足した内容もあります 9

この発表の注意２（三河ということもあり） ⚫ 第三者検証(Third party verification)を批判する意図はあ りません ⚫ 第三者検証という仕組みが我々の命や財産を守っていることは もちろん理解してます ⚫ ここでの第三者検証とはテスト会社のことではなく、IV&Vなど の組織や取り組みのことです ⚫ そもそも「テストはコンテキスト次第」です。 ⚫ 当てはまる現場もそうでない現場もあります 10

やまずんとは ⚫ バキバキQA/Dirty Tester ⚫ 外資系SaaSのQAエンジニア ⚫ 大阪のテスター ⚫ テスト設計コンテスト予選敗退 ⚫ 所属（コミュニティ） ⚫ testingOsaka ⚫ スクラム祭り 実行委員 ⚫ JaSST nanoお世話係軍団 ⚫ バキバキQAチャンネル 11

この発表のゴール ⚫ 単なるタスクではなく、テストって 技術があるんだと知っている ⚫ テストの技術を使ってスクラムに貢 献する側面もあると知っている ⚫ 上記を踏まえた上で、「スクラムに テスターが必要かどうか」について 考えるヒントを持ち帰っている 12

スクラムにおけるテスト 13

こんなことないですか？ ⚫ 「テストの計画書・設計書見たことないです」 ⚫ 「テスターさんがいるから安心です^^」 ⚫ 作ったらテスト担当者に丸投げ ⚫ 開発スプリントとテストスプリントが分離している こういう現場は アジャイルに 限った話でもな いね！ ⚫ 一概にだめというわけでもない ⚫ スプリントの中でDONEにならない ⚫ 少し違和感を感じることがある ⚫ 「テスト実行してる頃にはプログラマーは別のことを考えてる」 14

スクラムの三本柱 どこかで見たこ とある半魚人だ 透明性 検査 適応 15

スクラムにおける透明性の重要さ 透明性は検査の前提であり 検査によって適応ができる 言わなくてもわ かるだろうけど おさらいだよ！ 透明性 創発的なプロセスや作業は、作業を実行する人とその作業 を受け取る人に見える必要がある。 （略）透明性によって 検査が可能になる。透明性のない検査は、誤解を招き、ム ダなものである。 スクラムガイド p5 16

テストって検査じゃないの？ 検査 スクラムの作成物と合意されたゴールに向けた進捗状況は、 頻繁かつ熱心に検査されなければならない。（略）スクラ ムでは、 検査を⽀援するために、5 つのイベントでリズム 検査ってなんだ かテストっぽい よね！ を提供している。 スクラムガイド p5 テストは検査の一手段ではあるけど テストだけが検査ではなさそう 17

“テスト“という言葉の二面性 開発手法としてのテスト：コードとの対話 ⚫ 作り手が書いたコードを確かめる活動 ⚫ 設計としてのテストって言われることもあります ⚫ コードとの対話であり、二者間のやりとり ⚫ TDDなどはその代表例 ごまにはランプ の精とともだち という二面性が あるんだ！ 品質保証としてのテスト：他者への情報提供 ⚫ 作り手以外のステークホルダ（顧客・プロダクトオーナーほか）へ、品質 に対する説明責任を果たすための活動 ⚫ 第三者が介在する ⚫ 必ずしも第三者がやる必要はない（諸説あり） 参考：ソフトウェアテストの開発の側面と品質保証の側面（zenn）(私です) 18

テストの３つのスタンス スタンス1:テストとは行動である スタンス2:テストとは説明である スタンス3:テストとは納得してもらうことである ごまを精霊だと 納得してもらう ことである てすとづくり〜質の高いテスト設計の原理〜 p7 19

テストの制約 ソフトウェアテストはサンプリングで一部の品質しか見れ ないし、それが妥当かの判断が難しい上に成果を出すのが 遅い。そしてテストのリソースや情報に余裕がない ソフトウェアテスト徹底指南書 p10 （書影: 『ソフトウェアテスト徹底指南書』井芹洋輝 著） いま、一番売れ ているテストの 本だね！ 20

「テスト」を捉え直すこともできないか 「テストはやらないといけないからやるんだ！」 「やりたくないけど、とにかくやる！」 小難しい話に なってきたね〜 限られたリソースと膨大なパターンという 制約の中で「これならリリースできる」という 納得感の醸成を目指すのがテスト →それを⽀える技術がある 21

みなさんはどうでしょうか？ ⚫ どのようなテストがされているかイメージできます か？ ⚫ どのような制約の中で意思決定されていますか？ ランプの精に聞 いても答えは出 ないよ！ ⚫ 「これならリリースできる」と納得できています か？ ⚫ そのテストにはどんな技術が使われているでしょう か？ 22

さらにテストを難しくしている事情 ⚫ 自分が作ったものを批判的に見るのは難しい ⚫ （できる人もいる） ⚫ テストはテストでプログラミングとは別の頭の使い方や技術 が必要になる 全部できる人も もちろんいるよ ね！ ⚫ （両方できる人もいる） ⚫ 開発は作るものを考える必要があるが、テストは作ってはい けないものも考える ⚫ 作ってはいけないもののほうが世の中は多い ⚫ （両方考えて作ってる人もいる） 23

基本的なテスト技術 24

テストプロセスという考え方 ※プロセス定義には諸説あるがJSTQBを参照した テスト計画 テスト分析 テスト設計 テスト実装 テスト実行 テスト完了 検査を担える 一方通行とは限 らないから、概 念として捉えて ね！ 透明性を担える モニタリングとコントロール 検査・適応を担える（今回は一旦対象外） 25

テスト計画ってなんなの？ テスト計画とはリソース・コスト・手段などを答える ⚫ 「限られたリソースの中でどんなテストができればリリースできるか」に ついて答えるもの（やまずん解釈） ⚫ 計画しないスクラムチームは「機能性しか検討できていない」場合がある ⚫ これはちょっとだけ注意したほうがいい この右上のやつ はなんなの？ ⚫ 「テストアプローチ」などのテストのパターンもあったりする ⚫ 「テスト計画をする」が大事 ⚫ 「テンプレートに沿ったテスト計画書を書く」ではない ⚫ スコープで使い分けて計画するのがおすすめ ⚫ マスターテスト計画、スプリントテスト計画、レベルテスト計画など ⚫ 書く場合は形式に縛られる必要はないが、必要性に応じてこだわる ⚫ 好きな書き方でいいから、必要な情報や検討しておくことをちゃんと書く 26

テスト計画をやってほしいの たまに言う人がいる「アジャイルでテスト計画はできない」 ⚫ 事業単位・リリース単位・スプリント単位でもテスト計画はできます ⚫ むしろ同じ課題であればスプリントによらない一貫したテスト計画が必要な場合 もある ⚫ 例えば自動テストや非機能テストがこれらに含まれる場合もある 計画的に願い事 を叶えてね〜 ⚫ これを「テスト戦略」と言う人もいる。呼び方はなんでもOK。 ⚫ テスト計画という活動を認知することによって、話したり考えたりできる ⚫ 「われわれはなにをテストすると納得してリリースできるか」 ⚫ 「そのためのどんなリソースが必要か」 ⚫ 「スプリント計画でできてる」ならそれでOK ⚫ ちなみに探索的テストは「無計画にテストする」ではない ⚫ 探索的テストというスタイルに適したテスト計画をするべき 27

テスト分析って大事だよ ⚫ テスト分析は「テストすべきことは何か」について答える（やまずん解釈） ⚫ 最も粗い粒度でテスト条件が識別されるはず ⚫ 決して理解できない便利な表を作ることでも自分本位な箇条書きをすることではない ⚫ (個人的＆過激な意見)チームが見て理解できない成果物は受け入れなくていい ⚫ テスト分析については共同で行うか、チーム内でレビューすることがおすすめ ランプも大事だ よ！ ⚫ テスト分析の成果物で目指す粒度はチームによって異なるので、チームで合意で きるものを考える ⚫ これも「テンプレートを埋めるだけ」になってたらまずい兆候 ⚫ 個人的なおすすめ：「テスト設計が可能」＝「テスト技法の適用によりテストケースの 導出が可能」まで記述する ⚫ そのためにテストの技法は知っておいた方がいいし、テストケースについて理解してお いた方がいい 28

テスト設計は適当にやってるわけじゃない ⚫ テストケースを作るのがテスト設計 ⚫ テストケースとは、「テストを一意に定義するもの」（やまずん解釈） ⚫ テストケースは少なくとも入力値と期待結果が一意に定まるというメリットがある ⚫ 一方、テスト設計の技術が未熟だったり、組織の標準化技術が未熟だと、コストのかかる作業に なることもある ⚫ やまずんも場合によっては省略することがあります ⚫ まじめに願い事 考えてるよ！ 「テストケースが必要かどうか」の時点から、技術的に、文脈的に、妥当な選択が迫ら れる場合もあります ⚫ テスト設計で扱われる「テスト技法」は定められたスコープを適切にカバー（カ バレッジ）するテストケースを生成する技術（やまずん解釈） ⚫ なので、「適切にテスト技法が適用」されているかどうかを見るのがポイントのひとつ ⚫ カバレッジ意味ない論 29

テスト設計技法こんなのあるよ 状態遷移テスト ⚫ 状態遷移モデルや状態遷移図から「状態」や「遷移」をカバレッジするテストケースを生成する 技術 ⚫ だから「モデルが適切か」「選択したカバレッジが適切か」が大切なの デシジョンテーブルテスト ⚫ デシジョンテーブルで導出したルールをカバレッジするテストケースを生成する技術 ⚫ だから「デシジョンテーブルが適切か」が大切なの いろいろあるん だねえ 同値分割法 ⚫ 同値分割で識別した同値パーティションをカバレッジするテストケースを生成する技術 ⚫ だから「同値分割が適切か」「選択したカバレッジが適切か」が大事なの モデルの書き方や選択したカバレッジによってテストケースの内容と数は変わります 「モデルが適切か」「カバレッジが適切か」はテスト設計技法（とか）を理解してないと 正しいテストケースかは判断できないかもしれない 30

テスト完了（報告）も聞いてやってよ ⚫ 主にテスト実行を通して得られた情報をまとめるのがテスト 完了のうちのテスト報告（やまずん解釈） ⚫ テスト実行をしておいて、「ステータスが変わった」「テストチ ケットが完了した」で終わるのは超もったいない！！ 僕の話も聞いて ね！ ⚫ 以下のような情報はあるはず。これもまた透明性。 ⚫ テストで低減したプロダクトリスク ⚫ テストケース外のバグはあったか ⚫ みんなでテスト分析したからな ⚫ 第一のユーザーとしてどのように感じたか ⚫ その結果、どんな意思決定が必要なのか 31

結局テストは必要なのか 32

33

でもテストは価値 を生まないし、リ リースのボトル ネックだよね！ 34

確かにそうかもしれん 35

顧客が満足 よく売れる 誰も損しない 社会が良くなる これが永遠に続く （テストなしで）実現できるなら テストは不要 36

そんな「不確実性がないソフトウェア開発」は多分ない 顧客が満足 よく売れる 誰も損しない 社会が良くなる これが永遠に続く ここにいる人は言わなくても身に染みてわかっているはず そんな人に「うまくテストを使って欲しい」 テストなしでこれらが実現できるなら （もちろん、テストで全てが解決できるわけではない） テストは不要 37

みんなで考えてみてほしい ⚫ 「なぜ我々はテストが必要なのか」 ⚫ 「どれくらいテストしたら十分かを自信を持って検討できているか」 ⚫ 「状況に合わせて合理的なテストプロセスや手法が選択できているか」 右上のボクのこ となんだと思っ ていましたか？ これらがあんまりイメージ湧かない場合は透明性が不足しているかも？ 完了の定義（DoD）にはテストについてなんて書いてあるだろう？ それについてどんなふうに思ってましたか？ （完了の定義に書いてあることを否定しているわけじゃないよ） 38

テストが担える透明性とは ⚫ 「私たちはこれだけのこと考えて確認したからリ リースできる」という意思決定を促すための「透明 性」だと捉える ランプのしくみ も透明性高めた いねえ ⚫ テスト技術は、単にひとつひとつの動作を確認するだけ でなく、合理的にテストの必要性を考える方法やプロセ スも提供している ⚫ テスト技術を正しく理解することで、チームは透明性を 増やせる（かもしれない） 39

やまずんのスクラムにおけるテスト観 ⚫ スクラムはインクリメントや活動を検査と適応によって健全に保つ ⚫ インクリメントの検査は主に「テスト実行」によってなされる ⚫ 「テスト活動」自体の妥当性は「チーム自身」で判断、自己管理すべき ⚫ 第三者に委ねるべきではない(アドバイスもらうとかはもちろんOK) ふうん ⚫ スクラムチームでの自己管理を下支えするのが「テストの透明性」である ⚫ 「テストの透明性」は他にもいろいろな手段はあると思う ⚫ 技術としてはシフトレフト（ライト）、探索的テスト、メトリクス、非機能要件、自動 テスト、レビューなど、他にもいろんな論点があります ⚫ チームの人々が基本的なテストの技術を学ぶことでも透明性は得られる ⚫ （いわゆる「ゴッドハンド」みたいな凄腕テスターも世の中にはいるが、 すごすぎてこれはやまずんの頭では理解できなかった） 40

これでみなさんの現場では不要になりましたか？ 41

確かにそうかもしれん 42

テスターやQAの存在意義を疑ってみるのもいい ぜひそうしてほしい 自分ごとで考え、自分の手で、 品質保証やテストのことを 使おうと思える時がくるかもしれない その中でもし手助けが必要だと考えたとき、 テスターやQAエンジニアのことを 思い出してもいい 43

「重要なのは QAやテストという技術 だと聞きました！」 44

「重要なのは QAやテストという技術 だと聞きました！」 でも、それって本当に 心から理解できている？ 45

「重要なのは 「テスターってすごい！ QAやテストという技術 いてくれて最高です！ だと聞きました！」 尊敬しています！」 でも、それって本当に 心から理解できている？ 46

「重要なのは 「テスターってすごい！ QAやテストという技術 いてくれて最高です！ だと聞きました！」 尊敬しています！」 でも、それって本当に でも、それって本当に 心から理解できている？ 何してるかわかってる？ 47

本当に必要なものはなんなのでしょうか 48

それは組織それぞれが答えを探し・持つべきものだと考えます ただ、テストがもたらす「透明性」について考えてみると なにかのヒントになるのではないでしょうか？ テストを使って 透明性を獲得しよう 49

参考文献 • てすとづくり〜質の高いテスト設計の原理〜、2012/11/3、西康晴、 https://www.aster.or.jp/business/contest/contest2013/pdf/kansai_201 2_keynote.pdf#page=7 （2025/8/15参照） • スクラムガイド、 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-GuideJapanese.pdf（2025/8/15参照） • テスト技術者資格制度 Foundation Level シラバス Version 2023V4.0.J02、https://jstqb.jp/dl/JSTQBSyllabusFoundation_VersionV40.J02.pdf、（2025/8/15参照） • ソフトウェアテスト徹底指南書〜開発の高品質と高スピードを両立させる 実践アプローチ、井芹洋輝、2025年、技術評論社 イラスト：タスマニアデビ男 50

• https://www.aster.or.jp/business/contest/contest2013/pdf/kansai_201
• https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-
• https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf、（2025/8/15

「スクラムにテスターは必要ない」に対するアンサー 発表しないスライド 肯定する側面 ⚫ 完璧なスクラムチームにテスターやQAは必要ありません ⚫ ⚫ 「開発者完全性仮説」を調べてください 仮に完璧でないスクラムチームであっても、テスターやQAがいることで成長を妨げることもあります ⚫ ⚫ 品質保証やテストに対するオーナーシップ・技術を習得する機会を奪ってしまう場合もある←これはかなりまずい そもそも透明性がない働きをするQA・テスターがスクラムチームにいる場合、あまりいい働きをしていないかもしれな い 否定する側面 ⚫ テスターが以下のような貢献をすることはある ⚫ テスト技術の専門家として透明性の担保や、より高度な検査・適応を推進する ⚫ 製品を批判的に見る ⚫ ⚫ プログラマー自身が自分のプロダクトを批判的に見るのは難しい（できる人はいます） チーム外に対して説明責任を持つ手助けをする スクラムチームに所属するテストのプロとして 「テスト」という複雑な活動を解釈し・チームに伝えることによる透明性により 検査と適応を推進することで貢献してきたという個人的な経験からこの話をしました 51