今こそソフトウェアテストの失敗について語ろう_公開用

今こそソフトウェアテストの 失敗について語ろう WARAI 2024冬 2024.12.14(土) やました Dirty Tester バキバキQA

自己紹介 ⚫ Dirty Tester/バキバキQA ⚫ バキバキQAチャンネル ⚫ パーフェクトQAパーフェクトスタイル ⚫ SaaS企業のQA ⚫ 職業歴 ⚫ 営業←3年くらい ⚫ テストベンダー←6年くらい ⚫ 自社QA←Now ⚫ IVEC Level2/ITパスポート/RSM ⚫ In大阪 2

本発表のゴール ⚫ 失敗しないことの大切さを知る ⚫ 失敗話を聞く重要さを理解する ⚫ 失敗について話せる勇気を持つ 3

本発表の注意 ⚫ 大学などの専門機関で学んだ話ではなく、やましたが調べ たり、理解した内容を述べたものです ⚫ 気になったことは自分でも調べてください ⚫ 「SNS禁止」と記載している内容は、SNSのほか、ブログ 等への記載もご遠慮ください 4

みなさんは ソフトウェア開発で 失敗したことありますか？ 5

みなさんは ソフトウェアテストで 失敗したことありますか？ 6

？ そもそも「失敗」って何？ 7

失敗を考える前に 失敗について 学んでみよう ももトイレ 8

「失敗学」を学ぼう よろしくね！ 9

本発表における失敗の定義 失敗とは 「人間か関わって一つの行為を行ったとき、望まし くない、予期せぬ結果が生じること」 自然災害はボク たちのせいじゃ ないもんね〜 失敗学のすすめ p.26 失敗じゃない 失敗 • 地震が起こった • 地震が起こって建物が倒壊した • 大雨が降った • 大雨が降って堤防が決壊した 10

「失敗から学ぶ」ということ 失敗話には普遍性がある ⚫ 「失敗は成功の母」ということわざがあるように、 成功話には飽き ちゃった人もい るんじゃないか なあ？ 失敗から学ぶことは有意義であるという経験則 ⚫ 成功話は個別の状況に左右される ⚫ 一方、失敗の原因は共通していることが多い 11

「よい失敗」と「悪い失敗」 ⚫ 「よい失敗」 ⚫ 学びに繋がり、新たな経験や知識になるもの ⚫ なにかを達成する過程で、必ず必要になる失敗 ⚫ 「悪い失敗」 ボクはよくエサ 食べるの忘れる んだけど、これ は「悪い失敗」 だね！ ⚫ それ以外 ⚫ 学びに繋がらなかったり、デメリットが大きすぎるもの 本来的によい失敗は少ない 学ぶためにいたずらに失敗を重ねることもまた違う 12

失敗原因の階層性 未知への遭遇 社会性 行政・政治だけ 「怠慢」なのが おもしろいよね 〜 社会システムの不適合 行政・政治の怠慢 企業経営不良 全ての失敗を個人に帰さないように、 組織運営不良 社会的な要因について考えることが必要。 「未知への遭遇」のみは階層から引き離されている。 個人に責任のある問題 個人性 失敗学のすすめ p.63 13

失敗原因の分類 低レベルの判断 ミスはしないよ うにしたいよ ね！ 誰の責 条件に 起因す 個人に起因する原因 組織に起因する原因 る原因 1.無知 2.不注 意 3.手順 の不遵 守 5.調 4.誤判 査・検 断 討の不 6.制約 条件の 足 変化 任でも ない原 因 7.企画 8.価値 不良 観不良 9.組織 運営不 10.未知 良 高度な判断ミス 失敗学のすすめ 14 p.70

失敗の原因分類を一部解説 1.無知 失敗の予防や解決策があるにもかかわらず、不勉強によって起こす失敗。ただし、無 知を恐れるあまり、行動することなく調査や勉強ばかりに力を注いでいると、失敗に よって失うよりもさらに大事なやる気や時間や機会を失う。 いろんな原因が あるんだねえ〜 3.手順の不遵守 これを防止するためにはマニュアル化が有効。ただし「マニュアルさえ守りさえすれ ば十分」という錯覚に陥ることがある。 8.価値観不良 本来優先すべき価値観を優先できなかった問題。公害問題など。 10.未知 世の中の誰もがそれにいたる原因を知らないために起こる失敗。消毒の有用性など？ 失敗学のすすめ p.71-75 15

失敗を記述しよう 失敗情報は単純化、神話化、ローカル化、変化しやすい。 だから、今後の学びのために失敗の記述が大切である 一方、記述するために注意が必要 失敗を文書化す るのって大事な んだねえ ⚫ 失敗情報から学ぼうとしている人にとって、「客観的な情報」 は役に立たない。 ⚫ 当事者自身がどう考え、感じ、どんなプロセスでミスを起こし てしまったかという主観的な情報が学びにつながる。 16

失敗を記述するためのフォーマット 1.事象 失敗にいたった状況を正確に記録する 2.経過 失敗に至るまでの過程を詳細に記録する 3.原因 失敗の原因はどこにあったのか自分の見解を書く 4.対処 失敗に対して、当事者がどのような行動を取ったのか書く 5.総括 全体的に記述する 6.知識化 総括から要点を抜き出す フォーマットが あるのはわかる がトラウマを呼 び起こす 失敗学のすすめ p.118 17

ソフトウェアテストの失敗について 考えよう 18

ソフトウェアテストとは ふうん 「ソフトウェアテストとは、欠陥を発見し、 ソフトウェアアーティファクトの品質を評価するための 一連の活動である」 JSTQBFLシラバスV4.0 p16 19

ソフトウェアテストの役割 ソフトウェアテストの役割 ⚫ 製品が提供できなくなるような欠陥を発見する ⚫ 製品が提供できる状態であることを確認する 欠陥はソフト ウェア開発の 「失敗」とし ちゃうんだね 製品を提供するまでに「失敗」するための活動 とも言える（かもしれない） 20

ソフトウェアのテストの難しさ ソフトウェアテストはそれはそれで難しい ⚫ 「なにをもってテスト完了か」が決めきれない ⚫ ハードウェアにあるような物理的制約を受けないので、 設計解や統計的な品質管理手法が単純適用できない ソフトウェアの 品質管理はハー ドウェアのそれ をそのままとは いかないよね ⚫ 生産工程がないので、設計工程での品質管理/保証す る必要がある ⚫ 納期を初めとした厳しい戦いが強いられる 21

ソフトウェアテストは難しい ソフトウェアテストは難しい だから我々は失敗を共有して学ぶ もう二度と失敗しないように そして誰かが失敗しないようにする必要がある 22

テストの失敗、影響、原因 〜について本気出して考えてみた〜 23

テストにおける「失敗」の影響 プロジェクト面での影響 ⚫ テストを効率的に進められないことにつながる ⚫ 影響を受ける四天王：時間・予算 プロダクト面での影響 ⚫ テストを効果的に進められないことにつながる 四天王はお人形 みたいでかわい いよねえ ⚫ 影響を受ける四天王：品質・スコープ 荒ぶる四天王 24 JonathanRasmusson: 西村直人; 角谷信太郎. アジャイルサムライ――達人開発者への道 . オーム社. Kindle 版.

テストの失敗で影響が出るところ プロジェクト面 ⚫ テストのフェーズはボトルネックになりやすく、手戻りも発生しや すい ⚫ 安易に人海戦術に走ってしまう場合がある（コストの増大） ⚫ そして解決ができなかったりする プロジェクトに もプロダクトに も影響があるん だ プロダクト面 ⚫ お金を払っている人がいる ⚫ 金銭的な被害につながる ⚫ 行動が変化した顧客や社会がある ⚫ 機会や行動のロス、もしかしたら財産や生命にも影響があるかもしれない 25

失敗による影響（プロジェクト） 納期への影響 ⚫ テストが遅れるためにリリースが遅れる ⚫ 下手すればそもそもリリースしていいのかどうかもわからなくなる コストへの影響 ⚫ 資源・人員等の調達が必要になり、コストが想定よりもかかってし プロジェクトが カオスになって 意思決定が機能 しないことある よね まう ⚫ テストフェーズになってしまうと予算を超過しても歯止めが効かなくな ることもしばしば テストの工程の失敗が手遅れになることもよくあるし、 開発中の「失敗」がテストの工程に集中してしまうこともよくある 26

失敗による影響（プロダクト） スコープへの影響 ⚫ 「テストしていない機能はリリースをしない」という選択肢 ⚫ これができればいい方。それができなければ品質の影響へ、、 品質への影響 ⚫ 顧客への危害 ⚫ 顧客から預かった財産・生命・情報が危険にさらされる 低品質の製品を リリースするこ とが会社の終わ りにつながるこ とがあるよねえ ⚫ 信頼の失墜 ⚫ 会社やブランドの評価が下がり、製品が買われなくなる ⚫ 売上の低下 ⚫ 製品が売れなくなる。会社も続かなくなる ビジネスや顧客への影響がモロに出る「失敗」 場合によっては取り返しがつかないことも、、 27

失敗の原因 プロジェクト面 テストはいろん なリスクが現実 になるタイミン グなんだ ⚫ システムテストなどの完成品のテストにスケジュールの皺寄せが集中しやすい ⚫ テストケースの消化を目的とした場合、コストがかかる プロダクト面 ⚫ 全数テストは不可能なので普通にテストが抜ける ⚫ そもそも「なにをテストしたいか」「テストの存在意義」がよくわかってなかっ たり ⚫ あるいは「顧客にどんな価値を届けたいか」あるいは「プロダクトによってどんな仮説検 証を行いたいか」が明確でない場合も、、 28

失敗の原因の例（プロジェクト面） ⚫ 計画段階 ⚫ テスト計画が合意できない ⚫ テスト実行工数を過小/過大に評価してしまう ⚫ テストマネジメントの手法が確立されていない（報告/レポート） ⚫ 実行段階 こんなことがあ ると慌てちゃう よねえ ⚫ テストの開始基準が満たせない ⚫ テストの準備が終了しない ⚫ システムテスト工程でのバグが多すぎ問題 ⚫ 終了段階 ⚫ テストが終わらない ⚫ リリース判定ができない 29

失敗の原因（プロダクト面） ⚫ 計画・設計段階 ⚫ テストタイプやテスト条件の抜け ⚫ テストベースなどの情報の抜け ⚫ テスト実行の段階 ⚫ バグを見逃し プロダクトの全 ての問題を「テ スト抜け」で片 付けられたこと があります ⚫ テスト実行環境・手順の間違い ⚫ テスト終了 ⚫ バグの修正間に合いません ⚫ 残存バグが怖いのでリリースできません 30

「失敗」を「学び」に繋げるために 31

PDCAという考え方 いわゆるデミングサイクル PLAN ACTION デミングサイク ルって著作権あ るのかなあ？ DO CHECK 「品質管理」という考え自体が 学びを前提としている 32

失敗から学ぶ品質保証のプラクティス ⚫ 失敗から学ぶためのプラクティスはたくさんある ⚫ テストそのもの ⚫ シフトレフト もっとあるやろ ⚫ バグ分析 ⚫ ポストモーテム ⚫ なぜなぜ分析 ⚫ カオスエンジニアリング ⚫ 振り返り ⚫ ふりかえり（諸説ある） 33

ハンガーフライトをしよう かつて、天候が悪くて飛行機を飛ばせないとき、天候が良くなるまでパイロットたちは、格納庫の片隅で経験談など の雑談をしました。 まだ電子制御や航空機の技術が進歩していない時代です。 直接身の安全に関わる危険を経験していた彼らにとって、この雑談が貴重な情報源となっていたらしいのです。 34 カイゼンジャーニー p255

ハンガーフライトをしよう 一人で経験できることには限界がある だから、自分の経験を共有して、他者の経験も自分のものにする 知恵と経験をつなげて、自分の現場をよくしていく それぞれの現場でがんばる 35

失敗できないからこそ失敗から学ぶ ソフトウェアテスト失敗による影響は大きい だからこそ、簡単に失敗はできない 我々は仲間の失敗を血肉に変えて、学び 「悪い失敗をしないようにする」必要がある 36

イベントにおけるさまざまな学習手段 ⚫ Dialogue ⚫ お互いが語り、語りを聞き合う ⚫ Lightning Talk みんなで学ぼう ね〜 ⚫ ５分間話しまくる ⚫ Lean Coffee ⚫ テーマに沿って即興でカンファレンスする 37

参考文献 いつもありが とね〜 ⚫ 畑村洋太郎,「失敗学のすすめ」,講談社文庫,2005 ⚫ 畑村洋太郎,「失敗から知識を吸収し120%の力を出す！失敗 学見るだけノート」,宝島社,2022 ⚫ 市谷 聡啓.新井 剛,「カイゼン・ジャーニー たった1人から はじめて、「越境」するチームをつくるまで」,翔泳社,2018 ⚫ JonathanRasmusson: 西村直人; 角谷信太郎,「アジャイル サムライ――達人開発者への道」,オーム社,2011 ⚫ ISTQB:JSTQB,ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2023V4.0.J02, https://jstqb.jp/dl/JSTQBSyllabusFoundation_VersionV40.J02.pdf,2024/11/27 38

• https://jstqb.jp/dl/JSTQB-