見えないゴリラを見つけに行こう！ 〜テストのバイブル『Explore It!』翻訳プロジェクトから見えた、チームの未来〜

https://confengine.com/conferences/scrummatsuri/proposal/23261

Transcript

1. 見えないゴリラを見つけに行こう！ 〜テストのバイブル『 Explore It!』翻訳プロジェクトから見えた、チームの未来〜
2. 2 • 伊藤 潤平(@jp_110) • ウイングアーク１ｓｔ株式会社 ◦ ソフトウェアプロセス＆品質改善部　マネージャー • 社外活動 ◦ Scrum Fest Niigata 実行委員会 代表 ◦ JaSST Niigata アドバイザー ◦ SigSQAメンバー ◦ YouTube翻訳活動 ◦ 書籍『Explore It!』翻訳 • プロフィール AgileTD Zone Keynotes in Japanese https://niigatabase.shabellbase.com/engineer_01/
3. 自己紹介 • 古橋 明久(@AckyF1) • コミュニティ活動 ◦ Scrum Fest Mikawa 実行委員会 ◦ Scrum Fest Niigata 実行委員会 ◦ 書籍『Explore It!』翻訳 • お仕事 ◦ 製造業のソフトウェアエンジニア
5. 著書『Explore It!』を翻訳しています 著者は「エリザベス・ヘンドリクソン」です。 2013年に発売され、探索的テストのバイブルとま で言われる名著ですが、未だに日本語訳が出ていま せん。 現在は、スクラムフェス新潟コミュニティの有志が 集まって翻訳中です。来年には出版予定です。 本セッションでは著書『Explore It!』の見どころを 紹介します！ https://www.oreilly.com/library/view/explore-it/9781941222584/
6. チラ見（目次構成） 第1章 テストと探索について 第2章 探索をチャーターする 第3章 詳細を観察する 第4章 興味深いバリエーションを探す 第5章 結果を評価する 第6章 手順と相互作用を変化させる 第7章 エンティティとその関係性を探索する 第8章 状態遷移の発見 第9章 エコシステムを探索する 第10章 ユーザーインターフェイスがない場合の 探索 第11章 既存システムの探索 第12章 要件の探索 第13章 探索を全体に統合する 付録1 探索的テストのスキルを見極める面接 付録2 テストヒューリスティック・チートシー ト
7. パスの回数を数えてみよう
8. こんなこと起きてませんか? 「パス回しを数えること」 →仕様書に書かれたテストを実施すること 「ゴリラを見つけること」 →仕様書には明確に書かれれていないが、重要なこと (使いにくい・分かりにくい・遅い)
9. なんでこんな事が起きるのか? 「仕様通りに動くか?」に集中している Awareness Test ↓ ユーザー体験を損なう致命的な"ゴリ ラ"を見逃している
10. 探索的テスト 探索的ソフトウェアテストとは、個々のテスターの個人的自由と責任に 重点をおくソフトウェアテストのスタイルです。テスト関連の学習・テ スト設計・テスト実行・テスト結果の解釈を、プロジェクト全体を通じ て並行して実行される相互に支援的な活動として扱うことで、自分の仕 事の価値を継続的に最適化していきます。 システムについて学ぶためのテストを設計・実行すると同時に、前回の 実験で得た知見を次の実験に生かす。
11. 探索的テストは何を見つけるのか? 仕様書に書かれたことをテストすること →重要なテスト。 いろいろな書籍で分析手法が紹介されている 実験と学習で得られた知見を使ってテストをすること(探索的テスト) →これも重要なテスト。 機能要件の隙間にあるテスト、見えにくい品質特性
12. なんで探索的テストをやるのか? • 「学習」と「テスト」を同時に行うことで、システムの理解を深 め、新たなテストのアイデアを得るため。 • テスト担当者の経験、知識、直感を最大限に活かし、スクリプトテ ストでは見つけられない欠陥を発見するため。 テストの設計、テストの実行、システムの学習すべて大事 「知識」と「経験」を組み合わせることで、重要なことをテスト出来 るようになる
13. Appendix:モンキーテストと何が違うの? 探索的テスト モンキーテスト アドホックテスト 思考 考える 学習し、次に何をすべきか判断する 考えない (ランダム) 思いつき (場当たり的) 目的 欠陥の発見とシステムの学習 システムを破壊す ること 目の前の欠陥を見つける こと スキル 高いスキルとドメイン知識が活きる 不要 経験に依存 体系性 体系的 (チャーター、セッション管理) 無秩序 非体系的
14. AI時代に探索的テストは有効なのか? • 水面上 ◦ フロントエンド ◦ 機能要件 ◦ バグ出し • 水面下 ◦ バックエンド ◦ 非機能要件 ▪ セキュリティ ▪ パフォーマンス ▪ 保守性 ◦ 他モジュールとの連携 2013年発売の本ですが、AI時代に突入した現在でも有効！
15. こんな経験はありませんか？ "どれだけたくさんのテストを書いても、いくらテストケースを実行し ても、深刻なバグはいつもテストスクリプトから外れたところで見つ かります。" 出典：『Explore it!』第１章 テストの２つの側面
16. テスト完了 = チェックした + 探索した チェックする 探索する • 網がカバーしていない領域を偵察 • テスターの個々のスキルを発揮 • リスクを発見したらより深く掘り下げ • テスト設計・実行・学習・舵取りを同時に トリップワイヤーの網の例
17. セッションベースドテストマネジメント(SBTM) • ハマると何時間でも何日でもソフトウェアをさ迷う • 気になる情報も有益な情報も共有することができずに終わってしまう • そんなときはタイムボックス化したセッションを用いて作業時間を組み立てる • セッション内で注視すべきポイントをメモする • ポイントは、テストのアイデア、質問、リスク、驚き、探索したい追加領域、 バグなど
18. チャーター • ターゲット：どこを探索するのか？機能、要件、モジュールなど。 • リソース：どんな荷物を持っていくのか？リソースにはあらゆるものが含ま れる。ツール、データセット、技術、コンフィグなど。相互に依存する機能 もありうる。 • 情報：どんな情報を見つけたいのか？セキュリティ、パフォーマンス、信頼 性、性能、ユーザビリティ、その他のシステムの側面などを明らかにしたい のか？設計の一貫性や標準からの逸脱を発見したいのか？ Explore（ターゲット） with（リソース） to discover（情報）
19. チャーターの例 ターゲット：名字の編集 リソース：オマリー（O’Maley）とい う値を入力してみる 情報：プロフィール編集機能がアポ ストロフィー付きの名前を扱えるこ とを確認 細かすぎる例 ターゲット：システム全体 リソース：知りえる限り全てのハッ キングプログラム 情報：セキュリティホール ざっくりすぎる例 良いチャーターとは、テスト活動をあまり詳細に決めつけず、方向性だけを示すものです。いうなれば良いチャーターはプ ロンプトです。それは、インスピレーションの源を提示するのみで、こと細かに行動やアウトカムを指示しません。 ターゲット：プロフィールの変更 リソース：制約違反の可能性がある ユーザー名 情報：ユーザー名の制約が適用され ないケースがあるかどうかを確認 ターゲット：フィールド入力 リソース：JavaScriptおよびSQLイ ンジェクション攻撃 情報：セキュリティの脆弱性 ターゲット：ログインが必要なペー ジ リソース：なりすましURLとPOSTパ ラメータを使う 情報：購入していないコンテンツに アクセスできるかどうかを確認
20. 第9章 エコシステムの探索 • エコシステムの図解 ◦ インターフェースの描画 ◦ 外部依存関係のマッピング ◦ 内部を埋める • 信頼境界 • What If?(もしも？)ゲーム ソフトウェアの内部にばかり気を取られるのではなく、大きなシステムとして捉える。
21. 第10章 UIがない場合の探索 どんなシステムにも、少なくとも1つ、通常はそれ以上の種類のインターフェー スがある。例えばAPIの場合。 public double calculateSimilarity( String stringA, String stringB) calculateSimilarity(3, 5); // 整数型は文字列 型ではないので無効です calculateSimilarity(); // 2つのパラメータを必要とするため無効です calculateSimilarity( "a" , "a" ); calculateSimilarity( "a" , "z" ); calculateSimilarity( "" , "" ); calculateSimilarity(null, null); String myString = "100文字程度の長文 ... calculateSimilarity(myString, myString); Javaコンパイラの探索に なってしまう 正常な結果を確認 エラーになる結果を確認 性能の問題を検知 この辺はかなりAIの活 用が有効になってくる
22. 第12章 要件の探索 AI時代の現在でも要件の探索は重要であり、 10年前の手法は今でも使える（むしろ重要 度は増している気がする） • Never/Always条件 • コア機能の発見 • 品質特性 • リスク（What if?(もしも？)） • 期待値の調整 要件の議論の段階から、探索的手法を適用できる
23. 例えばログイン画面の場合 ログイン画面で ログインIDとパス ワードの入力 WebAPIのパラメー ター（リクエスト ＆レスポンス） バックエンドの 認証処理 セッションの 貼り方 SQL処理 インジェクショ ンのバリデー ション
24. おすすめの章:第6章 手順と相互作用を変化させる 仕様書通りのテストを実施するとどうなるか? 1つ1つ動作確認する ノブは1つずつ操作 規定回数のボタン操作
25. おすすめの章:第6章 手順と相互作用を変化させる 探索的テストで進めたら? 同時押ししたら? ノブは全部 グリグリ回したら? 連打し続けたら? 探索的テストで進めると… • ペルソナは? • 「名詞」と「動詞」を 色々組み合わせたら? • ランダムに操作してみ たら?
26. おすすめの章：付録1 探索的テストのスキルを見極める面接 面接の一部としてペアで探索的テスト • 準備：「これから一時間ほど探索していきましょう」 • 開始：一緒に操作し偵察チャーターから始める • 候補者の観察：思考パターンを観察する（テストのヒューリスティックや チャーターから逸脱していないか等） • ふりかえり：分かったことを話し合う（コミュニケーション能力が見えてく る） • 舵取り：別のチャーターを選ぶ（「システムの中から、特定の情報を見つけ 出す力」を持っているかを確認）
27. テストヒューリスティック • アブストラクト（抽象化） • Never/Alwaysルール • 先頭、途中、最後 • すべてを一箇所に集める • モデルを変えてみる • CRUD • すべてを分散させる • データを追跡する • ゴルディロックス（Goldilocks） • 中断 • 逆にする • 一部、なし、すべて • リソース不足にする • 少なすぎる • 多すぎる • 役立つ概算 • データ形式のルールを破ってみる • ゼロ • ゼロ、単数、複数 • ズームイン
28. Explore It!