Explore It! ワークショップをやってみた

探索的テストの本Explore It をベースにワークショップのネタを考えてみました

Transcript

1. Explore It! 勉強会 探索テストのワークショップ ON TESTING AND EXPLORATION 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 1
2. 学習の目的、狙い 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 2 • 探索的テストとは何かを理解する • 探索的テストのプロセスと技術を学ぶ • まず、体験してみる サイボウズにおけるテストのオプションを増やしたい シン・探索的テストを学ぶ
3. アジャイルテスティングの4象限 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 3
4. テストの二つの考え方 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 4 1. 想定した条件で、意図どうりの動作をしているか？ ⇒チェック（この本でCheckingと呼んでいる） 2. ほかにリスクはあるか？ ⇒ 探索 “二つの重要な質問”に答えるテスト戦略が必要
5. チェック 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 5 ネット：網の交点が想定したテストポイント 事前に“想定した”ことを、確かめる 網の目が小さいほど、チェックによるカバー率は高くなる
6. 探索 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 6 探索は、“想定していない”障害を探ること 探索的テストでは、 ネットがカバーしていない（チェックではできない）領域 を探し回ることになります。
7. Elisabethの探索テストの定義 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 7 “テスト実行結果で得た知見を次のテストに生かす” “テスト設計し、すぐに実行してしまう”
8. 探索的テスト 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 8 テスト 実行 学習 テスト 設計 これが高速に回る
9. システムを学習するという姿勢 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 9 テスト結果の注意深い観察 バグが潜んでいる かもしれない場所 微妙な手がかり、におい システムの癖 自分の想定を超えて観察をする システムの特異性
10. テストの舵を切る 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 10 試行（テスト）を重ねる ソフトウェアの挙動につい て理解が深る ソフトウェアが苦手とする 条件に気づき 発見すべき最も重要な情報に焦点を当てながら舵取りをする
11. テストの設計 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 11 学習したこと 経験 価値観 リスク認識 次に“テスト”：“試したい“こと システムの癖 システムの特徴 バグのにおい 好奇心 テスト設計技法 疑問 仮説
12. タイムボックスセッション 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 12 セッション 焦 点 を 決 め る 振 り 返 り か じ 取 り や す み 焦 点 を 決 め る 振 り 返 り
13. 焦点を決める：チャーター 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 13 チャーター：憲章⇒プロジェクト憲章 目的、スコープ、責任；計画を立てるためのもの なぜ、探索的テストでチャーター？ 詳細な計画は役に立たない：すぐに変わるかもしれない ”想定外“を探る冒険だから なんでテストをするか、何を探そうとするか、どこを探索する のか、それでなにが得られるのか でも、目的、指針、それを支える意思の表明は必要
14. ワークショップ ２月１日 手順 1. 軽い復讐 2. 作ったチャーターをちょっと共有 3. ロールの簡単な説明 4. セッション： 1０分 ＋ 振り返り３分 ： ３セッション 5. 記録したいこと 1. チャーターの修正（かじ取り） 2. 最初のテスト 3. 何回テストしたか 4. 学んだこと 5. かじ取りした回数 6. 不具合の情報 7. 不具合の回数 6. 振り返り 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 14
15. ロール：ドライバ 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 15 ドライバの画面を共有 テスト対象アプリ画面を出して、テストする
16. ロール：ナビゲータ 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 16 ドライバと伴走 一緒に観察し、設計を考え、 次の一手をサポートする
17. ロール：記録 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 17 探索的テストはテストに集中するあまり なかなか記録が残らない：再現性が欲しい 記録は大局的に見て、次のかじ取りを考える際に有用 何手打ったか 不具合数 何を学んだか：かじ取りの回数 チャーターの修正 不具合の内容（スクショ）
18. ワークショップ ２月１日 手順 1. 軽い復讐 2. 作ったチャーターをちょっと共有 3. ロールの簡単な説明 4. セッション： 1０分 ＋ 振り返り３分 ： ３セッション 5. 記録したいこと 1. チャーターの修正（かじ取り） 2. 最初のテスト 3. 何回テストしたか 4. 学んだこと 5. かじ取りした回数 6. 不具合の情報 7. 不具合の回数 6. 振り返り 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 18
19. テストは両者必要 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 19 テスト ＝ チェック ＋ 探索
20. 探索的テストだけだと 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 20 ウィキペディアより 群盲象を評す
21. 探索的テストとアドホックテスト 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 21 IT用語辞典 e-Words “アドホックは探索ではなく、放浪です” 放浪 ＝ “その場の思い付きでの操作”
22. 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 22 お楽しみに 皆さん、どんどん現場で 試してみてください！！ 次回は、よりよくするノウハウなど ご紹介していきます
23. 探索的テストのチャーターのテンプレートの例 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 23 ⚫ テストのターゲット どこを探索するのか： どの機能：どの要求に対して？：どのモジュールをテストする？ ⚫ どのような情報をもとめているのか？ 使いにくいところ、わかりにくいところ、 弱いところ、性能、信頼性、セキュリティ ⚫ リソース 探索にあたり、使えるリソース：ツール、データセット、技法
24. 完璧なテストを目指して：テストの7原則 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 24 1. テストは欠陥があることは示せるが、欠陥がないことは示せない 2. 全数テストは不可 3. 早期テストで時間とコストを節約 4. 欠陥の偏在 5. 殺虫剤のパラドックスにご用心 6. .テストは状況次第 7. 「バグゼロ」の落とし穴 包括的なテストケースを完璧にそろえることではない JSTQB Foundation Level シラバス http://jstqb.jp/syllabus.html
25. 探索テストの定義 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 25 James Bach “探索的テストとは、学習、テスト設計、テスト実行の同時進行である” "システムについて学ぶためのテストの設計・実行し、 前回の実験（テスト）で得た知見を次のテストに生かす“ Elisabeth Hendrickson
26. テストの実行 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 26 即時実行 事前に”すべての”テストを設計することはない 実行してみないと、次に取り上げるべき“質問”は分からない 実行してみると、もっと先にテストするべきものが見えてくる 探索が始まったら、すぐ手を動かしテストを実行する つまり
27. テーマをまとめると 2022/2/1 COPYRIGHT © ATSUSHI NAGATA 27 チェックと探索の違い 包括的なテスト戦略にはチェックと探索両方が必要 探索的テストは テストの結果から、システムについて学ぶ 学んだ知見から、 最適な次のテストにかじ取りをして行う それを短いイテレーションで行う