良いテストは良いフィードバック/wacate2020w

WACATE2020冬の招待講演資料です。

Transcript

1. 良いテストは 良いフィードバック WACATE2020冬 2020/12/19 Kumiko Iseri 1 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
2. 誰︖ WACATEとの関わり 元実⾏委員、参加者 現在のコミュニティ活動 JSTQB技術委員 テスト設計コンテストU-30クラス審査委員 テストツールガイド改訂WGメンバー など 趣味 写真撮影(最近は⿃派) 過去の資料 https://speakerdeck.com/omn https://www.slideshare.net/omn 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 2
3. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する しかし、 漠然と、良いテストを考えるのは難しい まずは、 テストは何のためのものかを考え、良いテストを考える⾜がかりを⾒つける 3 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
4. ソフトウェアテストは、何のため︖ 4 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
5. テストは、よく品質とセットで語られますが… テストすれば、品質は良くなりますか︖ 5 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
6. テストだけでは品質は良くならない • 品質が良いとは︖ • 顧客にとって価値があるプロダクトである • 顧客のビジネスに貢献できている • … • 少しブレークダウン • ニーズと合致する機能 • 処理速度に配慮したロジック • 直感的なUI • 派⽣開発しやすい設計 • 障害からすぐ復旧できる設計 • … 6 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
7. テストだけでは品質は良くならない • 品質が良いとは︖ • 顧客にとって価値があるプロダクトである • 顧客のビジネスに貢献できている • … • 少しブレークダウン • ニーズと合致する機能 • 処理速度に配慮したロジック • 直感的なUI • 派⽣開発しやすい設計 • 障害からすぐ復旧できる設計 • … 7 プログラミングやインフラ設計等で実現する テストだけでは品質は変わらない が、テスト対象を観察し試⾏することで バグやテストの合否などが分かる これらのアウトプットは何のため︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
8. テストによるフィードバックの後、何が起こるか • よくあるアウトプットと、その後に起こる主なこと • テストは、改善と判断のインプットを提供するために⾏われる 8 バグを修正する バグレポート テストケース、合否 プロセスを改善する プロセスの開始/終了の判断をする バグの修正の優先順を決める 次のプロジェクトの計画をする 改善 判断 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
9. テストをシンプルな図にすると • テスト設計や実⾏による観察、試⾏を通して テスト対象のできているところとできていないところを発⾒し、 まとめて情報提供する 9 テスト対象 ①テスト設計や実⾏による 観察、試⾏ ②できているところ、 できていないところを バグレポートや テストレポートにまとめる ③品質について情報提供 判断 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
10. 少し⼀般化すると • 何かに似ている︖ • ふりかえり • ⾃分たちの活動を観察し、 続けたいことや課題を共有、次のアクションへ • ⽬標管理 • 業務を観察し働きぶりや成果を共有、次のアクションへ • ⽇常でのアドバイス • 普段の⾏動を⾒て気づきを共有、次のアクションへ • これらは、フィードバックと⾔える • テストもフィードバックの⼀種と考えることができる 10 対象 ①観察や試⾏ ③結果の共有 ②できているところ、 できていないところ の分析をする 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
11. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰したい そこで、 テストをフィードバックの⼀種として捉えて、良いテストを考える 11 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
12. さあ、良いフィードバック、良いテストを考えよう…︖ 良い◦◦は、⼤抵の場合、複数の条件が組み合わさって実現されており複雑 逆に考えてみる 悪いフィードバック、つまり、 役に⽴たないフィードバックや、不満を感じるフィードバックの特徴を考える フィードバックを受け取って 「あまり役に⽴たないな」「不満だな」と感じたことはありますか︖ • ふりかえり • ⽬標管理 • ⽇常でのアドバイス • … 12 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
13. 悪いフィードバックあるある 13 • それ、事実じゃないです • ⼤事なことはそれだけではないのに • 今更︖ • 何を⾔いたい︖ダメ出ししたいだけ︖ • あんな居⼼地悪い場で⾔わなくても • 部外者にあれこれ⾔われても… • もしや、好みを押し付けたいだけ︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
14. 悪いフィードバックあるある 14 • それ、事実じゃないです • ⼤事なことはそれだけではないのに • 今更︖ • 何を⾔いたい︖ダメ出ししたいだけ︖ • あんな居⼼地悪い場で⾔わなくても • 部外者にあれこれ⾔われても… • もしや、好みを押し付けたいだけ︖ →内容がよくない →タイミングがよくない →伝え⽅がよくない →伝える場がよくない →伝える⼈がよくない →伝える理由が不適切 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
15. 良いフィードバックをするために考慮が必要なこと • 正しい内容か • ⽬的にふさわしい内容か • 次のアクションに間に合うか • 要点が伝わる伝え⽅か • 伝えるのにふさわしい場か(場の空気) 伝えるのにふさわしい場か(物理的な場) • 説得⼒を持って伝えられる⽴場か • 受け⼿が納得できる理由に基づいているか 15 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
16. 本講演のスコープ • 正しい内容か • ⽬的にふさわしい内容か • 次のアクションに間に合うか • 要点が伝わる伝え⽅か • 伝えるのにふさわしい場か(場の空気) 伝えるのにふさわしい場か(物理的な場) • 説得⼒を持って伝えられる⽴場か • 受け⼿が納得できる理由に基づいているか 16 こちらを扱う テストの場合、 変えにくい 改善や判断といった アクションを促すこと 正確 的確 適時 理解容易 信頼構築 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
17. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓正しい理解に基づいた内容である 的確︓⽬的にふさわしい内容である 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 17 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
18. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは p What p 正確 p 要求や設計を理解する p的確 p ⼈を理解する p 環境を理解する p 発想を広げる p When p 適時 p テストの順序をリスクに基づいて決める p プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 18 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
19. 正確 的確 適時 理解容易 信頼構築 要求や設計を理解する • テスト対象を正確に知る • 当たり前のことだが、まず必要なこと • テストタイプやテストレベルにより変わるものの、 多くの場合は要求や設計を理解する必要がある • ドキュメントにまとまっていても、テストを考えやすい形になっていなければ 再構成し理解する必要がある • 必要な情報が複数箇所に散らばっている • エラーが起こる条件やエラーが起きた後の処理の記述が不⼗分 • 複雑なものを理解する場合、モデリングが役⽴つ 19 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
20. 正確 的確 適時 理解容易 信頼構築 要求や設計を理解する • モデリング︖ • アドホックな図、DFD、 UML、SysML、ラルフチャート、 状態遷移テスト、CFD、… • この資料での「モデリング」 • 何に着⽬するか、視点を決める。データ、⼊⼒値、状態、… • 視点に基づいて、知っていることの分解や統合をして、抽象度を調節する • 分解や統合した結果を相互に関連づけ、再構成する 20 着⽬する 視点を決定 分解、 抽象化/具体化 再構成(図⽰) 登録済 未登録 ユーザーID ⼊⼒なし ⼊⼒あり パスワード ⼊⼒なし ⼊⼒あり メールアドレス 登録 処理 エラー CFD(Cause Flow Diagram)の例 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
21. 正確 的確 適時 理解容易 信頼構築 要求や設計を理解する • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。 申請者が申請ボタンを押すと、第⼀承認者が承認か不承認 のボタンを押せるようになる。第⼀承認者が承認ボタンを押す と第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承 認者が、承認か不承認のボタンを押せるようになる。最終承 認されると、申請者が確認ボタンを押せるようになる。確認ボ タンが押された時、ワークフローが完了する。 第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認 者が未設定のときは、申請ボタンが押されると最終承認か最 終不承認のボタンが押せるようになる。 次にアクションを起こすべき⼈が気づけるように、承認ボタンや 不承認ボタンが押されると、通知のためのメールが送信される。 21 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
22. 正確 的確 適時 理解容易 信頼構築 • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。 申請者が申請ボタンを押すと、第⼀承認者が承認か不承認 のボタンを押せるようになる。第⼀承認者が承認ボタンを押す と第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承 認者が、承認か不承認のボタンを押せるようになる。最終承 認されると、申請者が確認ボタンを押せるようになる。確認ボ タンが押された時、ワークフローが完了する。 第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認 者が未設定のときは、申請ボタンが押されると最終承認か最 終不承認のボタンが押せるようになる。 次にアクションを起こすべき⼈が気づけるように、承認ボタンや 不承認ボタンが押されると、通知のためのメールが送信される。 申請者 要求や設計を理解する 22 アドホックなモデルでも、元の⽂より理解しやすい (不承認のフローは割愛) 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※図は当⽇限り
23. 正確 的確 適時 理解容易 信頼構築 • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。 申請者が申請ボタンを押すと、第⼀承認者が承認か不承認 のボタンを押せるようになる。第⼀承認者が承認ボタンを押す と第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承 認者が、承認か不承認のボタンを押せるようになる。最終承 認されると、申請者が確認ボタンを押せるようになる。確認ボ タンが押された時、ワークフローが完了する。 第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認 者が未設定のときは、申請ボタンが押されると最終承認か最 終不承認のボタンが押せるようになる。 次にアクションを起こすべき⼈が気づけるように、承認ボタンや 不承認ボタンが押されると、通知のためのメールが送信され る。 申請者 要求や設計を理解する 23 アドホックなモデルでも、元の⽂より理解しやすい (不承認のフローは割愛) 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※図は当⽇限り
24. 正確 的確 適時 理解容易 信頼構築 要求や設計を理解する • モデリングは難しい… • ⾃然⾔語は曖昧 • インプットとなるドキュメントや会話は⾃然⾔語でモデルより厳密でない • 逆に考える。曖昧な部分を洗い出すことも、モデリングの⽬的にする • 視点の明確化が必要 • データ構造か︖ 状態か︖ …適切なモデルを定めるのは難しい • 既存のモデリング技術を使う場合は、そのノウハウを活⽤できる • でも、価値あり • 俯瞰しやすくなる • インプットと異なる表現をすることで、理解できていないところが浮き彫りになる 24 俯瞰 違う表現⽅法 理解 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
25. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓正しい理解に基づいた内容である 的確︓⽬的にふさわしい内容である 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 25 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
26. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは p What ü 正確 ü 要求や設計を理解する ü 要求や設計の背景を理解する p 的確 p ⼈を理解する p 環境を理解する p 発想を広げる p When p 適時 p テストの順序をリスクに基づいて決める p プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 26 ワークあり 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
27. 正確 的確 適時 理解容易 信頼構築 的確、的を外していないとは︖ • 的は、実現すべき品質 • 明⽰的な品質要求だけでなく、暗黙的な品質要求もあるため 実現すべき品質を理解するには要求や設計の理解だけでは⾜りない • リスクを理解する …適時の説明で取り上げる • ソフトウェアを取り巻く⼈を理解する • ソフトウェアを取り巻く環境を理解する • 実現すべき品質を踏まえた上で、発想を広げて確度を上げる • 『QAの⼈たちはシステムを破壊する⽅法を⾒つける能⼒を買われて雇われている。深い専⾨性 を持った⼈たちであり、ユーザーがシステムに対して⾏うあらゆる奇妙なことを予⾒できる。』 • 引⽤元︓ Robert C.Martin (著), ⾓ 征典 (翻訳), ⾓⾕ 信太郎 (翻訳), Clean Agile 基本に⽴ち戻れ, 初版, 株式会社ドワンゴ, 2020/10/5, PDF版, 95ページ 27 以降で、もう少し詳しく 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
28. 正確 的確 適時 理解容易 信頼構築 ⼈、環境を理解する • 要求も設計も実現すべき品質も、⼈が考え出すものである • ソフトウェアを取り巻く⼈、つまりステークホルダを理解する必要がある • ステークホルダの要求、不安、コミュニケーションパスが要求や設計に影響する • 実現したい品質は、テスト対象それ⾃体だけで決まるわけではない • ソフトウェアを取り巻く環境を理解する • 競合製品や外部のルールが実現したい品質に影響する 28 環境 ソフトウェア 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
29. 正確 的確 適時 理解容易 信頼構築 ⼈を理解する • ソフトウェアを取り巻く⼈を理解する 1. ステークホルダを洗い出す • 体制図や⾃らの業務からステークホルダを探し、発⾒したステークホルダのコミュニケーション相⼿を探す 2. ステークホルダーを分析する • 浅く広く、狭く深くの２通りに分けられる • 浅く広く︓複数のステークホルダの関係分析 • ステークホルダマトリクス • 重要度(ステークホルダの要求の必要度合い)と 意思決定への影響度合いとで評価、図⽰する • ユーザビリティ要求など要求ごとにつくる 29 重要度 ⾼い 低い 低い ⾼い 影響度 ユーザ 運⽤者 プロダクト オーナー 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 • 参考 ⼀般社団法⼈情報サービス産業協会REBOK企画WG (編集), 要求⼯学実践ガイド REBOKシリーズ2, 初版, 近代科学社, 2014/3/31, 11-12ページ・183­204ページ • 参考 ⼀般社団法⼈情報サービス産業協会REBOK企画WG (編集), 要求⼯学知識体系 第1版, 初版, 近代科学社, 2011/6/30, 49-53 • 参考 https://www.ipa.go.jp/files/000005375.pdf 要求⼯学知識体系(REBOK)概説, 25ページ, 最終閲覧2020/11/29
30. 正確 的確 適時 理解容易 信頼構築 ⼈を理解する • 浅く広く︓複数のステークホルダの関係分析 • 組織の構造やコミュニケーションパスの理解 • コンウェイの法則 『システムを設計する組織は、その構造をそっくりまねた 構造の設計を⽣み出してしまう』 • 『ソフトウェアにどれだけバグが含まれているかなどを⼤規模な プロジェクトで精査した結果、組織階層の深さや地理的に離れた 複数⼈が関わるコード、離職者の数、関わっている開発者の⼈数など、 コミュニケーションコストが⼀般に多くかかるであろう環境ほど、 バグが多くなる傾向が発⾒されているのです。 』 • 上記2箇所の引⽤元︓広⽊ ⼤地. エンジニアリング組織論への招待 〜不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) , 初版, 技術評論社, 2018/3/8(電⼦版2018/2/22), Kindle 版, Kindle の位置No.4164・ No.4168-4171 30 組織構造 コミュニケーション 品質 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
31. 正確 的確 適時 理解容易 信頼構築 ⼈を理解する • 深く狭く︓特定のステークホルダ、特にユーザの深堀分析 • ペルソナ • 多数いるユーザーをグルーピングし、各グループの特徴をおさえた架空のユーザー像をつくる • 名前、プロフィール、プロダクトとの関わり、… • 具体的なユーザー像から、ユーザーがなにを考え、どう⾏動するかを考える • 参考︓ • https://enterprisezine.jp/iti/detail/2705 アジャイルUXの潮流 〜 ⽶国発アジャイル開発の新しい波、 只今⽇本に接近中!? 第3回 仮⾯のユーザ「ペルソナ」参上︕, 最終閲覧2020/11/29 • https://www.stickyminds.com/article/how-pragmatic-personas-help-you-understand-your- end-user How Pragmatic Personas Help You Understand Your End-User, 最終閲覧⽇2020/11/29 • 特性かけあわせ • ステークホルダーを、更に習熟度や環境といった特性によりグルーピングし、違いを考える • 例 熟練者はキーボードショートカットを多く使いたがるのでは︖ 31 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
32. 正確 的確 適時 理解容易 信頼構築 環境を理解する • 例 動画が多⽤され使い⽅が分かりやすく解説されているWEBサイト 32 品質は良い(悪くない)︖ それとも、悪い︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
33. 正確 的確 適時 理解容易 信頼構築 ソフトウェアを取り巻く環境を理解する • 例 動画が多⽤され使い⽅が分かりやすく解説されているWEBサイト • 帯域制限の影響を受けやすい⼈、ネットワークが遅く不安定な環境で使われる場合が多いと…︖ • 品質の良し悪しは、テスト対象のソフトウェアや機能それ⾃体だけでなく 環境にも左右される • ステークホルダが使うデバイス、ネットワーク環境 • 競合製品 • 競合製品の⽅が洗練されていたら︖ 使える環境が多かったら︖ • 法律や、外部機関による検証や審査のルール 33 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
34. 正確 的確 適時 理解容易 信頼構築 発想を広げる • ⼈や環境を基に実現すべき品質の理解を深めた後は、発想を広げる • テストと発想 • テスト担当者としての適正判断をするためのお題の例 …⾃動販売機のソフトウェアのテスト 『筆者の理想としては、「韓国ウオンを⼊れて、その瞬間ケリを3発⼊れている 間に、すべての指を使ってありったけのボタンを押す」なのですが、未だ そのような答えをしてくれた⼈はいません。せめて、硬貨のコンビネーションとか 同時にボタンを押す（組み合わせテスト）とか、多量のコインを⼊れる （⼤容量テスト）といった答えは欲しいものです。』 • 引⽤元︓⾼橋 寿⼀ (著), 湯本 剛 (著), 現場の仕事がバリバリ進む ソフトウェアテスト⼿法, 初版, 技術評論社, 平成18年6⽉1⽇, 177ページ • まずは、ワークで、お互いの発想について知りましょう 34 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
35. 正確 的確 適時 理解容易 信頼構築 ワーク [個⼈ワーク 5分] • 右記の状況で1回だけ テストを実⾏しバグを⾒つけたい • どんなテストをしますか︖ • テストを、どのように思いついた か、理由やインプットを考えてくだ さい • 例 過去に同様のテストをしてバグを ⾒つけたから [グループワーク 10分] • どんなテストを/どのように 思いついたか、1⼈1〜2分程 で共有してください • 発表順や進⾏は各班にお任せ • ⽬的は、他の⼈の発想内容や インプットを知ること 35 u A社では、全社向けバグ管理システムを開発中である u このバグ管理システムの概要は、以下の通り u PCやモバイル端末(スマホ、タブレット)のWEBブラウザで利⽤可能 u バグレポート、ユーザ情報、プロジェクト情報は、 それぞれ登録、編集、削除、登録済データの検索が可能である u バグレポートは、1件ずつ⼿⼊⼒の他、CSVファイルのインポートで 登録可能 u 別のツール(表計算ソフト)でバグ分析できるよう、検索後に検索 結果のバグレポートを⼀括でCSVファイルにエクスポート可能 u バグレポートとユーザーは、必ず1プロジェクト以上に紐づく u バグレポートの⼊⼒項⽬と表⽰項⽬、ステータスとステータス遷移 のルールは、プロジェクトごとにカスタマイズ可能 例︓ステータス「新規」→「完了」の直接遷移を禁⽌する u 要求や設計を基に計画したテストは終わっている。正常系の シナリオが動作することは分かっている。 [ 状 況 ] 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
36. 正確 的確 適時 理解容易 信頼構築 ワーク回答例 • どんなテストをするか • • • • • • • 理由、インプット • • • 36 ワークで、⾃分や他の⼈の 発想の内容やインプットを 知ることはできましたか︖ この後も発想についての話です このワークの内容を思い出しながら、 聞いていただくと良いでしょう 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※回答例は当⽇限り ※回答例は当⽇限り
37. 正確 的確 適時 理解容易 信頼構築 • 発想を発散させた後、収束させてテストで利⽤する • 要求や設計や背景といったテスト対象の情報、実現すべき品質などを事前に理解する • まずは発想を発散させ、その結果を収束させる。場合によっては、何度か繰り返す • 収束した結果を、テストケースなどへ反映する 発想して、その結果をテストに活かすまで 37 発散させる 抽象化 具体化 テスト対象の情報 テストの⽬的 収束させる 発想の統廃合 テストケースなどへ反映 実現すべき品質 ? 必要な情報を得る 活⽤する 何を取っ掛かりに︖ どうやって︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
38. 正確 的確 適時 理解容易 信頼構築 発想を広げる • 『⼈間の脳にとっての⾃然な傾向は、最も確実なものの⾒⽅によって強い印象を刻まれ、 そこから思考を進めていくことだ。 この⾃然の傾向に打ち勝つためには、意識的、⼈為的にさまざまな⾒⽅を探し求める 必要がある。』 • 引⽤元︓エドワード デボノ (著), 藤島みさ⼦ (翻訳), ⽔平思考の世界 固定観念がはずれる創造的思考法, きこ書房, 2015/11/8, 145ページ • ラテラルシンキング(⽔平思考)では視点を変えたり制約を外したりする • テストの場合︖ 何を取っ掛かりに︖ どのような⼿段で︖ 38 • 抽象的な知恵や標準から発想する • 具体的な事例や場⾯から発想する • 強制連想法、⾃由連想法を組み合わせる • モデリングする • モブ作業で発想する 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
39. 正確 的確 適時 理解容易 信頼構築 発想を広げる取っ掛かり • 抽象的な知恵や標準から発想する • 組織標準や外部の規格などから、トップダウンで考える • 組織標準のテストの分類、 国際規格 ISO/IEC 25000シリーズ SQuaREの品質特性(品質モデル)、… • 標準や規格に囚われて実態とかけ離れないように注意 • 標準や規格に綺麗におさまるように考えるのではなく、 実態を中⼼に考え標準や規格の取捨選択や優先順付けをする • 品質特性同⼠の間には、トレードオフがあるという意⾒もある • 例 使⽤性のための処理が、性能効率性には負の影響を及ぼす • 「安全性」などの「品質属性」を定義、関係性を紹介している書籍もある • カール ウィーガーズ(著), ジョイ ビーティ (著), 渡部洋⼦ (翻訳), 宗 雅彦 (監修), ソフトウェア要求 第3版 (Japanese Edition), 2014/12/19, Kindle 版, 14.5 品質属性のトレードオフ(Kindle の位置 No.8497) 39 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
40. 余談︓狩野モデル • 魅⼒的品質、⼀元的品質、当り前品質…聞いたことはありますか︖ 40 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
41. 余談︓狩野モデル 充⾜している 場合 充⾜していない 場合 区分 満⾜ 仕⽅ない 魅⼒的品質要素 （Attractive Quality Element） 満⾜ 不満 ⼀元的品質要素 （One-Dimensional Quality Element） 当り前 不満 当り前品質要素 （Must-Be Quality Element） 満⾜でも 不満でもない 満⾜でも 不満でもない 無関⼼品質要素 （Indifferent Quality Element） 不満 満⾜ 逆品質要素（Reverse Quality Element） ⽣産者は充⾜させようと努⼒しているが ユーザからは不満と評価される 41 上記表は、以下を参考に、本資料作成者にて作成 狩野 紀昭(著), 瀬楽 信彦(著), ⾼橋 ⽂夫(著), 辻 新⼀(著), 魅⼒的品質と当り前品質, 品質 14(2), 147-156, 1984 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
42. 余談︓狩野モデル • 基となった論⽂では、5種類が提唱されていた • 魅⼒的品質、⼀元的品質、当り前品質、無関⼼品質、逆品質 • それぞれの品質要素は別の品質要素に変化することがある • 『また、ある時点まで魅⼒品質に分類できた機能も、競合他社が提供するようになれば すぐ当たり前品質になってしまいます。⼀元的品質も同じで、突出したレベルにまで ⾼められれば魅⼒品質に転じることがある⼀⽅、陳腐化すれば当たり前品質に変質して しまうので、注意が必要です。』 • 引⽤元︓及川 卓也, ソフトウェア・ファースト (Japanese Edition), 第1版,⽇経ＢＰ, 2019/10/15, Kindle 版, Kindle の位置No.1041-1044 42 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
43. 正確 的確 適時 理解容易 信頼構築 発想を広げる取っ掛かり • 具体的な事例や場⾯から発想する • 事例や場⾯を探して、ボトムアップで考える • 類似のプロダクトやプロジェクトの事例をテスト対象に当てはめる • 過去バージョン、類似した他社製品など、機能やユースケースに共通点がある他のプロダクト • 体制、システム構成、採⽤技術などに共通点があるプロジェクト • ⽐較や組み合わせ、その結果として起こりそうなことを考えてテスト対象に当てはめる • 機能同⼠、システム同⼠を⽐較、組み合わせて考える • データ、操作感、デザインの⽅向性など整合性を保つべき機能はあるか︖ • 他のシステムと組み合わせて使う際にスムーズに使えるか︖ • 時間の流れと組み合わせる • プロダクトのライフサイクル。企画、開発、運⽤、廃棄の各フェーズで何が起こるか︖ • インストール、マスタデータの更新や削除、バージョンアップ、… • データの増減があったら︖ 43 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
44. 正確 的確 適時 理解容易 信頼構築 トップダウンとボトムアップ、いずれから始めても⼤事なこと • 抽象化と具体化を繰り返す • 『抽象化とは⼀⾔で表現すれば、 「枝葉を切り捨てて幹を⾒ること」といえます。 ⽂字どおり、「特徴を抽出する」ということです。』 • 引⽤元︓細⾕ 功(著), 具体と抽象(Japanese Edition), 初版, 株式会社ｄＺＥＲＯ, 2014/12/7, Kindle 版, Kindle の位置No.196-197 • 抽象化しないと、発想が広がらない 具体化しないと、現状にどう適⽤するか分かりにくい、⼈により理解が異なりがち • 例︓前バージョンにて、会員退会処理で想定外のエラー → [抽象化]→ 会員状態の変更 → [具体化]→ ⼀時休会処理 → [抽象化]→ 会員状態の変更 → [具体化]→ 会員ランクのアップとダウン • 抽象化と具体化をしやすくするためにどうすればよいか︖ 44 発散させる 抽象化 具体化 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
45. 正確 的確 適時 理解容易 信頼構築 • モデリングをする • 正確なフィードバックだけではなく、的確なフィードバックにも効果的 • 発想を広げる上での効果 • 関連を持つもの同⼠や関連の内容が 視覚的に表現され連想に役⽴つ • 同じ/逆の関連を持つものは他には︖ • 端的に表現しようとすることが 抽象度の上げ下げの助けになる 発想を広げる⼿段 45 着⽬する 視点を決定 分解、 抽象化/具体化 再構成(図⽰) 俯瞰 違う表現⽅法 理解 関連から連想 抽象的表現 発想 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
46. 正確 的確 適時 理解容易 信頼構築 発想を広げる⼿段 • 強制連想法、⾃由連想法を組み合わせて発想する • 強制連想法︓ガイドワードなどを使い、⽅向性を決めて発想する • オズボーンのチェックリスト、HAZOPのガイドワード、… • ⾃由連想法︓思いついたままにアイデアを出す • 習熟度により使い分けるが、基本的には両⽅を組み合わせて使う • 初⼼者は、⽅向性が決まっている強制連想法を中⼼にするほうがやりやすい • 慣れた⼈の場合、⾃由連想法の⽅が、発想をより広く効率的にできる⼈もいる • 参考 https://mag.executive.itmedia.co.jp/executive/articles/0911/12/news007_2.html 内⼭悟志の 「IT⼈材育成物語」︓【第13話】アイデアの連鎖 (2/2), 最終閲覧⽇2020/12/9 • 参考 https://enterprisezine.jp/iti/detail/1311 ファシリテーションで会議を変える 第7回 「その発想はなかった︕」と ⾔わせる技術を⾝につけよう〜仕事の幅を広げる19の発想技法, 最終閲覧⽇2020/12/10 • 参考 https://note.com/akiyama924/n/n09e4b0575818 “強制連想法”で思考を発散させる, 最終閲覧⽇2020/12/9 46 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
47. 正確 的確 適時 理解容易 信頼構築 発想を広げる⼿段 • モブ作業をする • 利点 • 強みが違う⼈と⾏うことで、双⽅の知⾒を活⽤し、発想を広げやすくなる • 内部構造に詳しい開発者とテストに詳しいQA、機能Aに強い⼈と機能Bに強い⼈ • 注意点 • 1⼈ではできない • コストが冗⻑に⾒られがち • 効果を無視すると、1名での作業に⽐べて膨⼤なコストがかかる • しかし、育成、情報や経験の共有といった発想以外の効果もある • トラックナンバー(ハネムーンナンバー)の増加 • すべてをモブでやらなくてもよい。調査は個⼈作業、成果物作成はモブ作業など 47 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
48. 正確 的確 適時 理解容易 信頼構築 モブ作業をする • モブ作業をする（続き） • 『しかし、冗⻑性を持つ組織を作ることは、知識創造プロセスの マネジメントにとって⾮常に重要である。なぜならそれは、頻繁な対話と コミュニケーションを促進するからである。冗⻑性は、社員のあいだに 「認識上の共通基盤」を創り、暗黙知の移転を助けるのである。組織 成員は情報を重複共有してこそ、お互いが四苦⼋苦しながら表現 しようとしていることをわかり合える。この情報共有という冗⻑性によって、 新しい形式知が組織全体に広まり、⼀⼈ひとりのものになるのである。』 • 引⽤元︓野中 郁次郎,⽵内 弘⾼. 知識創造企業 (Japanese Edition) (Kindle の位置No.475-479). Kindle 版. 48 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
49. 余談︓集まってコミュニケーションをとることの効果 • レビューにおける効果 • 『「ファントムインスペクター（phantominspector）」というレビュー⽤語を ご存じでしょうか。ファントムとは幻のことで、インスペクターはレビューアー と同じ意味で⽤いられています。つまり「幻のレビューアー」というわけです。レビュー アーが個別にドキュメントをチェックしたときには⾒逃した問題が、レビュー会議で 集まって話し合うとスムーズに⾒つかるという効果を意味します。』 • 『ファントムインスペクターは主に、1⼈のレビューアーの指摘内容から 他のレビューアーが気付きを得ることによって⽣まれます。』 • 上記2箇所の引⽤元︓森崎修司, なぜ重⼤な問題を⾒逃すのか︖間違いだらけの設計レビュー [改訂版] (Japanese Edition) , 初版, ⽇経BP, 2015/9/15, Kindle 版, Kindle の位置No.381-384・No.387-388 49 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
50. 余談︓ブレーンストーミングの注意点 • ブレーンストーミング • グループで多様なアイディアを出したいときに、よく⾏われるが… 多様な意⾒を効率的に取得できるわけではないという研究結果がある • 原因は、⼀説として • ブレーンストーミングでは同時に複数⼈が発⾔できない。 また、別の⼈の話を聞いているうちに忘れたり、発⾔をやめてしまったりすることがある • 他の⼈から評価される懸念 • ただ乗り、さぼり • やり⽅を⼯夫して効率的、効果的に • コラボレーションツールを使って他の⼈の発⾔中もアイディアを発信できる仕組みの構築、 ⼼理的安全性の確保、等 • 参考︓鈴⽊宏昭, 認知バイアス ⼼に潜むふしぎな働き (Japanese Edition) ,株式会社講談社, 2020/11/1, Kindle 版, Kindle の位置 No.2046-2073 • 参考︓⻲⽥ 達也 (著), 認知科学モノグラフ③ 合議の知を求めて―グループの意思決定, 初版, 共⽴出版, 1997/2/5, 111-116ページ 50 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
51. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓正しい理解に基づいた内容である 的確︓⽬的にふさわしい内容である 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 51 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
52. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは ü What ü 正確 ü 要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる p When p 適時 p テストの順序をリスクに基づいて決める p プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 52 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
53. 正確 的確 適時 理解容易 信頼構築 • 早くフィードバックが得られると、どんな嬉しいことがあるか︖ • すぐに対応すべき重⼤な問題について、対応の時間が⼗分とれる • 重⼤な問題がない⾒通しが⽴てば、別のことができる • 重⼤な問題︖ • ⼈命や健康、⾦銭を左右しかねないバグ • ビジネスへの影響が⼤きい部分のテスト結果 • 多くの⼈から、よく使われる機能の問題 • 影響⼒の⼤きいユーザーが頻繁に使う機能の問題 • ウリになる機能など、顧客を獲得・維持する上で 重要な機能の問題 より早く欲しいフィードバックは何か︖ 53 ひょっとすると 起こるかもしれないこと リスク 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
54. 正確 的確 適時 理解容易 信頼構築 リスクに応じたフィードバックをする • リスクとは︖ • 『リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクの レベルは、そのような事象が 起きる可能性とその影響（事象による結果が もたらす損害）で決まる。』 • 引⽤元︓http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J02.pdf テスト技術者 資格制度 Foundation Level シラバス Version 2018V3.1.J02, 71ページ, 最終閲覧2020/11/29 • 障害や損失になるものという考え⽅と、前向きなリスクも含める考え⽅がある • 本書でのリスクは、将来起こるかもしれない、プロダクトとプロジェクトの少なくとも ⼀⽅に影響を及ぼす事象とする • 未来の不確実さとうまく付き合うために、リスクを管理しテストに活かす 54 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
55. 正確 的確 適時 理解容易 信頼構築 リスクに応じたフィードバックをする • バグによるリスクが 危害を及ぼすまでの イメージ • 事象⾃体だけでなく、 事象の源なども考慮する • 1種類の事象に複数の ⽋陥やエラーが 影響することも 55 状況 例︓コーディングルールの未整備 • 図「バグでリスクが発⽣する場合」の枠内の 引⽤元︓ https://www.slideshare.net/goyoki/ss-29203311 リスクベースドテストを活⽤しよう,11ページ, 最終閲覧2020/11/29 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
56. 正確 的確 適時 理解容易 信頼構築 • リスク管理プロセス リスクに応じたフィードバックをする 56 計画 識別 分析 対応、 残余リスク確認 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
57. 正確 的確 適時 理解容易 信頼構築 • テストがリスク管理プロセスに与える影響 • 適切なタイミングで対応結果を確認できるようにテストをしなくてはならない • 例 完成に近づいてからしかテストできないが、想定外のことが⾒つかると修正に時間がかかる • シミュレーターを使って先⾏して⼀部のテストを⾏う、等 リスクに応じたフィードバックをする 57 計画 識別 分析 対応、 残余リスク確認 テストの分析や設計中に リスクに気づくことがある 対応結果(の⼀部)を、 テストで確認する 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
58. 正確 的確 適時 理解容易 信頼構築 リスクに応じたフィードバックをする • リスクがテストに与える影響 • リスクからわかったことをテストの優先順に反映させることで適時なフィードバックに • テストを、リスクとの関連性(テストの⽬的やスコープなど)により、分割して考える • 例 機能テスト→顧客向け機能テスト／管理者向け機能テスト • 適時だけでなく、リスクを理解することは様々な⾯でテストの最適化に繋がる • フィードバックの正確さ、的確さにもプラスの影響がある 58 プロダクトリスク バグやバグが引き起こす問題 使いにくさ … プロジェクトリスク ⼈員不⾜ ⾒積もりミス … テストの順序 テストの規模(厚み) 必要スキル テストプロセス 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
59. 正確 的確 適時 理解容易 信頼構築 これで⼗分︖ • ちょうど良いタイミングでフィードバックできるようにするには︖ • リスクに基づいてテストの優先順を決める • プロジェクト全体における適時を考える • 動的なテストは、実際にソフトウェアを動かすので、遅くなりがちで⾼くなりがち • バグが顕在化してから潰し込むより、予防できる⽅が良い 59 テストプロセスの中で 要件 設計 実装 テスト 要件 設計 実装 テスト 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
60. 正確 的確 適時 理解容易 信頼構築 プロジェクト全体における適時を考える • なるべく早くフィードバックができるとよい • 受け⼊れテストやユーザストーリーを検討する会話、 設計のレビュー … • 『テスト担当者、開発者、ビジネス代表者がフィーチャの検討すべてに参加するという コンセプトは、「三⼈の⼒」として知られている[Crispin08]。』 • 引⽤元︓ http://jstqb.jp/dl/JSTQB-SyllabusFoundation-AgileExt_Version2014.J01.pdf テスト技術者 資格制度Foundation Level Extension シラバスアジャイルテスト担当者Version 2014.J01, 10-11ページ, 最終閲覧20201129 • まだ曖昧な話、不確実な話が多いタイミングだが…指摘ではなく質問する • 『QA は「Question Asker」の略で、Pete Walen から得たアイデアです。 テスターは、他の誰も質問しないと思う質問を定期的に出します。 そのため、チームにテスターがいない場合は、質問者の役割を指定してみてください。 』 • 引⽤元︓ Janet Gregory (著), Lisa Crispin(著), ⾵間 裕也(翻訳), Agile Testing Condensed Japanese Edition,第2版, 2020/4/27, 22ページ • では、何をフィードバック、質問するか︖ 60 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
61. 正確 的確 適時 理解容易 信頼構築 プロジェクト全体における適時を考える • 何をフィードバックするか︖ • 要求や設計 • 曖昧な点。コミュニケーションミスを予防するため • テストの事前条件や期待結果を特定できる⾒込みか︖ 影響範囲は︖ • 現バージョンとの振る舞いとの整合性 • リスク(になりそうなもの)。事前に分かれば、予防や対応準備ができるようにするため • 過去のバグやユーザからの問い合わせ、競合製品との差異 • テストの⽅法。テスタビリティを確保するため • どうやって検証するか︖ テストオラクルは︖ テスト環境は︖ • 例 現在時刻をインプットとする処理に対し、テスト中インプットの時刻を⼈為的に変更できる 仕組みを追加する • テストの効率性、有効性が確保しやすくなるよう相談や提案をする • 参考 https://thinkit.co.jp/article/14136 連載 [第8回] : 開発現場で役⽴つテスト「超」実践講座 「テスタビリティ」を作り込む, 最終閲覧2020/12/13 61 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
62. 余談︓プロセス改善の⼿法 • 適時を追求した結果、プロセス改善が必要になることがある • SaPID︓⾃律を重視した改善⼿法 • TPI NEXT • CMMI • 経験からのシンプルな⼿法 • 現状の課題の確認、現状のプロセスやプロセスの結果の⾒える化 • PFD、BPMN、フローチャート等によるプロセスモデリング • 改善点の洗い出しと対策の決定 • ボトルネックを探す • ECRSを⼿がかりにする • 『⼯程をなくす』 『⼯程を統合する』 『順番を変える』 『単純化する』 • 引⽤元︓https://slide.meguro.ryuzee.com/slides/78 カイゼンの基本 ~組織・プロダクト・プロセスを どう改善するか~, 42-45ページ, 最終閲覧2020/11/29 • プロセスの変更 • 効果の確認 62 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
63. この講演でお伝えしたいこと 本⽇のゴール 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓テスト対象の正しい理解に基づいている 的確︓ステークホルダーに提供する価値の理解に基づいている 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 63 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
64. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは ü What ü 正確 ü 要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 64 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
65. 正確 的確 適時 理解容易 信頼構築 「理解容易」って︖ • 得た情報の取捨選択や加⼯の仕⽅に気を付けましょうというお話 • 気をつけて伝えなくてもフィードバックが活⽤されるなら、問題なし • 得意分野も状況も異なる⼈同⼠、コミュニケーションにノイズは付き物 • テスト結果の伝達までを責務とするか︖ 価値あるプロダクトの提供までを⽬指すか︖ • 『テストを担当したら，バグ報告できない⼈たちの代弁者となれ』 • 引⽤元︓Cem Kaner (著), James Bach (著), Bret Pettichord (著), テスト技術者交流会 (翻訳), ソフトウェアテスト293の鉄則, 初版,⽇経BP, 2003/4/21, 78ページ • 次ページから、関わる⼈が多く⼈による差が出やすい バグレポート を取り上げる • レポート⼀般の話は避け、バグレポートならではの理解容易を考える • フォーマットや組織体制の考慮も不可⽋だが、今回はフィードバック内容に注⽬する 65 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
66. 正確 的確 適時 理解容易 信頼構築 要点をわかりやすく表現する • バグレポートを利⽤する⼈にとっての要点をわかりやすく • バグを直す⼈ • バグの対応優先順を決める⼈ • バグを直す⼈にとっての要点 • オープンソースのバグレポートの研究より • 『開発者たちから得られた反応から、スタックトレース、バグの再現⼿順、期待された 振る舞い、観察された振る舞いが、バグ解決時に重要であることが分かりました。』 • 実際に起きた事象(事実)と、本来あるべき状態を正しく理解しないとバグは直せない • 『最も重⼤な問題は、バグ再現⼿順の間違いと情報の不完全さです。』 • 上記２点の引⽤元︓Andy Oram (編集), Greg Wilson (編集), 久野 禎⼦ (翻訳), 久野 靖 (翻訳), Making Software ―エビデンスが変えるソフトウェア開発, 初版, オライリージャパン, 2011/9/22, 418・424ページ 66 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 バグレポートの利⽤者のうち、今回焦点を当てる⼈
67. 正確 的確 適時 理解容易 信頼構築 要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点 • 事象だけでなく、その影響が分からないと、対応優先順は決められない • 架空の⽇報システムのバグレポートより…これは急いで直すべきバグか︖ • データ削除の権限を持たないユーザーでログインして、 管理画⾯を表⽰させると [データ全削除] ボタンが表⽰される 67 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
68. 正確 的確 適時 理解容易 信頼構築 要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点(続き) • 事象だけでなく、その影響が分からないと、対応優先順は決められない • 架空の⽇報システムのバグレポートより…これは急いで直すべきバグか︖ • データ削除の権限を持たないユーザーでログインして、 管理画⾯を表⽰させると [データ全削除] ボタンが表⽰される • [データ全削除] ボタンをクリックするとデータが全削除される →急ぐ • [データ全削除] ボタンをクリックしても、データ削除は起こらない →︖ • 「権限がありません」とメッセージが表⽰される • ボタンに⾒えるが、クリックしても何も起こらない 68 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
69. 正確 的確 適時 理解容易 信頼構築 要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点(続き) • 事象だけでなく、その影響が分からないと、対応優先順は決められない • 『障害レポートを商売道具として活かせ』 • 修正した場合に得られるものを明確に伝えて売り込む • 受け⼊れられないことを予期して情報をまとめ報告する • 『』内の引⽤元︓Cem Kaner (著), James Bach (著), Bret Pettichord (著), テスト 技術者交流会 (翻訳), ソフトウェアテスト293の鉄則, 初版,⽇経BP, 2003/4/21, 74-75ページ • 事象をユーザーが⾃ら回避する⽅法があるか︖ • 事象により発⽣したエラー画⾯などからユーザーが⾃ら復帰する⽅法はあるか︖ • 正常フローへ戻ったり操作をやり直したりする⽅法はあるか︖ • 事象を点ではなく、ユーザーが⽬的達成するためのフローの⼀部として考える 69 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
70. 正確 的確 適時 理解容易 信頼構築 要点をわかりやすく表現する • 書籍「Bug Advocacy」(Cem Kaner (著), Rebecca L Fiedler (著) , 2015年7⽉下旬に 出版)に紹介されている「RIMGEN」が活⽤できる 70 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 『』内および右表の引⽤元︓ https://www.slideshare.net/tomohiroodan/ss-66393352 バグ票⾒つめて気づきませんか︖〜⽴場いろいろ、悩みいろいろ〜, 22ページ, 最終閲覧2020/11/29
71. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓正しい理解に基づいた内容である 的確︓⽬的にふさわしい内容である 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 71 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
72. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは ü What ü 正確 ü 要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える ü How ü 理解容易 ü 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 72 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
73. 正確 的確 適時 理解容易 信頼構築 信頼してフィードバックできる場づくりに貢献する • 効果的で効率的なフィードバックには、 率直な話をしても⼤丈夫だと信頼しあえる雰囲気が必要 • 周りのステークホルダと対⽴している場では、フィードバックは受け⼊れられにくくなる • 『ほとんどの⼈が、私が対⼈リスクと呼ぶもの、つまり他の⼈にばかにされるリスクを 何とかしなければならないと思っている。とりわけ職場で、わけても上司や公式 権⼒を持つ⼈の前でイメージを傷つけられるのを最⼩限に⾷いとめるためである。 そのための⼀つの⽅法が、⾃分が正しいと⾃信が持てないときは意⾒を⾔わない こと、間違いを認めないこと、そして⾔うまでもないが、絶対に質問しないこと、 利点を確信できないちょっと思いついただけのアイデアは⼝にしないことなのだ。』 • 引⽤元︓エイミー・Ｃ・エドモンドソン (著), 野津智⼦ (翻訳), チームが機能するとはどういうことか 「学習⼒」と「実⾏⼒」を⾼める実 践アプローチ ＥＰＵＢ版(Japanese Edition), 英治出版株式会社, 2014/5/31(EPUB版2014/9/5), Kindle 版, Kindle の位置No.1173-1178 73 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
74. 正確 的確 適時 理解容易 信頼構築 信頼してフィードバックできる場づくりに貢献する • しかも、テスト活動でよく登場するバグの話は、 プロジェクトやステークホルダーを脅かすものとして捉えられやすい • バグの報告が、設計者や実装者に対する⾮難と捉えられる • プロジェクトの進⾏の邪魔と捉えられる • バグレポートが争いの場になったり、役に⽴たないと⾔われ続けると、 他に誰も気づいていない⼩さな違和感や、重⼤だが確証が得られない問題を フィードバックしにくくなる • 組織の場の雰囲気まるごとを、個⼈で⼤きく改善することは難しい しかし、悪化を防いだり、⾝の回りの雰囲気を変えたりすることはできる 74 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
75. 正確 的確 適時 理解容易 信頼構築 信頼してフィードバックできる場づくりに貢献する • フィードバックで信頼を構築する • 個⼈への指摘と、プロダクトへの指摘を混同しない • 先ほど紹介した『RIMGEN』（書籍「Bug Advocacy」 より）のN • 『』内および右表の引⽤元︓ https://www.slideshare.net/tomohiroodan/ss- 66393352 （バグ票⾒つめて気づきませんか︖〜⽴場いろいろ、悩みいろいろ〜 ） 22ページ, 最終閲覧2020/11/29 • ⽬的を⾒失わない • ステークホルダーに価値を届けることであり、誰かの⾮難ではない • ⾮難は、応酬による時間の浪費やモチベーションの低下を招く • 表現を⼯夫する • ネガティブ・フィードバックを伝えるときは『はっきりと問題を指摘しながらも、 相⼿への配慮を込めた丁寧な表現を⽤いる。』 • 引⽤元︓https://www.slideshare.net/rochellekopp/jasst20-kyushu- 239353816 (【JaSSTʻ20 Kyushu】サーバントリーダーシップを⾝に付けましょう︕) 34ページ, 最終閲覧2020/11/29 75 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
76. この講演の⽬指すところ 良いテストに必要な考え⽅や基礎的な技術を俯瞰する 要点 テストは、フィードバックの⼀種である 良いテストに必要なこと 正確︓正しい理解に基づいた内容である 的確︓⽬的にふさわしい内容である 適時︓改善や判断のタイミングに間に合う 理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である 信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる 76 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
77. お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは ü What ü 正確 ü 要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える ü How ü 理解容易 ü 要点をわかりやすく表現する ü Where ü 信頼構築 ü 安⼼してフィードバックをやりとりできる場づく りに貢献する p おわりに 77 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
78. おわりに • ところで… プロジェクトの関係者全員が、「うまく動くはず」と思い込んでいたら、 何が起こるだろうか︖ • 確証バイアス • 『私たちは，⾃分の仮説に合う事例ばかりを探し，⾃分の仮説に合わない事例を探そうとし ない傾向があり， これを確証バイアス（confirmation bias）という。』 • 引⽤元︓服部雅史; ⼩島治幸; 北神慎司. 基礎から学ぶ認知⼼理学――⼈間の認識の不思議 有斐閣ストゥ ディア, 電⼦書籍PDF版Ver.1.0, 株式会社有斐閣, 2016/3/22, Kindle 版, 131ページ 78 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
79. おわりに • ところで… プロジェクトの関係者全員が、「うまく動くはず」と思い込んでいたら、 何が起こるだろうか︖ • 確証バイアス • 「私たちは，⾃分の仮説に合う事例ばかりを探し，⾃分の仮説に合わない事例を探そうとし ない傾向があり， これを確証バイアス（confirmation bias）という。」 • 引⽤元︓服部雅史; ⼩島治幸; 北神慎司. 基礎から学ぶ認知⼼理学――⼈間の認識の不思議 有斐閣ストゥ ディア, 電⼦書籍PDF版Ver.1.0, 株式会社有斐閣, 2016/3/22, Kindle 版, 131ページ • ソフトウェア開発では、⼤半の⼈はうまく動かすことに関⼼がある • ⼀⽅、テストをするときは、うまく動かせないことにも⽬を向けざるを得ない • テスト担当者のフィードバックにより、実態により即した判断や改善ができる 79 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
80. おわりに • フィードバックを効果的に伝えるには様々な考慮が必要 • 内容はもちろん、伝え⽅やタイミングが効果を左右することがある • 正確、的確、適時、理解容易、信頼構築 • 今⽇お話ししたのは、基礎的な考え⽅や技術の俯瞰 興味がある技術は、後⽇、ぜひ深堀りしていただければと思います 良いテスト、良いフィードバックを通して プロダクトの価値向上に貢献しましょう 80 [Special Thanks to] レビュアーの井芹洋輝さん、機会をくださったWACATE実⾏委員会のみなさん 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料
81. 参考⽂献 本⽂中で触れていない⽂献のみ、以下に掲載する。 • 良いフィードバック、良いテストとは • http://www.jasst.jp/symposium/jasst15kansai/pdf/A3-1.pdf なんじゃこりゃ︕このバグ票なんか腹たつ〜バグ票の 失敗から学ぶソフトウェア開発のための 幸せなコミュニケーション術〜, 2020年11⽉29⽇最終閲覧 • 的確 • 吉澤準特. ロジカル・ラテラル・クリティカルの基本がしっかり⾝につくビジネス思考法使いこなしブック (Japanese Edition), 初版, ⽇本能率協会マネジメントセンター, 2015/6/30, Kindle 版 • 適時 • ⽥邉 ⼀盛 (著), エンジニアのためのリスクマネジメント⼊⾨, 初版, 技術評論社,2020/2/27, PDF • 鈴⽊安⽽ (著) , 図解⼊⾨よくわかる 最新PMBOK第6版の基本, 第1版, 秀和システム, 2018/4/1, Kindle版 • http://jstqb.jp/dl/JSTQB-glossary-.V3.2.pdf Standard Glossary of Terms used in Software Testing Version 3.2, 最終閲覧2020/11/29 • https://www.software-quasol.com/sapid3-0/ SaPID®3.0 （サピッド3.0） ⾃らの問題意識から始める⾃律運営組織構築・変⾰のための共創プログラム, 最終閲覧2020/11/29 • 薮⽥和夫(訳), 湯本剛(訳), 皆川義孝(訳), TPI NEXT® ビジネス主導のテストプロセス改善, 初版, 株式会社トリフォリオ, 2015/9/20 • https://xtech.nikkei.com/it/article/lecture/20070405/267507/ CMMIって何だろう, 最終閲覧2020/11/29 81 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料