wacate2020w

良いテストは良いフィードバック WACATE2020冬 2020/12/19 Kumiko Iseri 1 2020/12/19 WACATE2020winter Kumiko
Iseri 公開⽤資料

誰︖ WACATEとの関わり元実⾏委員、参加者現在のコミュニティ活動 JSTQB技術委員テスト設計コンテストU-30クラス審査委員テストツールガイド改訂WGメンバーなど趣味写真撮影(最近は⿃派)
過去の資料 https://speakerdeck.com/omn https://www.slideshare.net/omn 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 2

この講演の⽬指すところ良いテストに必要な考え⽅や基礎的な技術を俯瞰するしかし、漠然と、良いテストを考えるのは難しいまずは、テストは何のためのものかを考え、良いテストを考える⾜がかりを⾒つける 3 2020/12/19 WACATE2020winter Kumiko
Iseri 公開⽤資料

ソフトウェアテストは、何のため︖ 4 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

テストは、よく品質とセットで語られますが… テストすれば、品質は良くなりますか︖ 5 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

テストだけでは品質は良くならない • 品質が良いとは︖ • 顧客にとって価値があるプロダクトである • 顧客のビジネスに貢献できている • … •
少しブレークダウン • ニーズと合致する機能 • 処理速度に配慮したロジック • 直感的なUI • 派⽣開発しやすい設計 • 障害からすぐ復旧できる設計 • … 6 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

テストだけでは品質は良くならない • 品質が良いとは︖ • 顧客にとって価値があるプロダクトである • 顧客のビジネスに貢献できている • … •
少しブレークダウン • ニーズと合致する機能 • 処理速度に配慮したロジック • 直感的なUI • 派⽣開発しやすい設計 • 障害からすぐ復旧できる設計 • … 7 プログラミングやインフラ設計等で実現するテストだけでは品質は変わらないが、テスト対象を観察し試⾏することでバグやテストの合否などが分かるこれらのアウトプットは何のため︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

テストによるフィードバックの後、何が起こるか • よくあるアウトプットと、その後に起こる主なこと • テストは、改善と判断のインプットを提供するために⾏われる 8 バグを修正するバグレポートテストケース、合否プロセスを改善する
プロセスの開始/終了の判断をするバグの修正の優先順を決める次のプロジェクトの計画をする改善判断 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

テストをシンプルな図にすると • テスト設計や実⾏による観察、試⾏を通してテスト対象のできているところとできていないところを発⾒し、まとめて情報提供する 9 テスト対象 ①テスト設計や実⾏による観察、試⾏ ②できているところ、
できていないところをバグレポートやテストレポートにまとめる ③品質について情報提供判断 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

少し⼀般化すると • 何かに似ている︖ • ふりかえり • ⾃分たちの活動を観察し、続けたいことや課題を共有、次のアクションへ • ⽬標管理
• 業務を観察し働きぶりや成果を共有、次のアクションへ • ⽇常でのアドバイス • 普段の⾏動を⾒て気づきを共有、次のアクションへ • これらは、フィードバックと⾔える • テストもフィードバックの⼀種と考えることができる 10 対象 ①観察や試⾏ ③結果の共有 ②できているところ、できていないところの分析をする 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

この講演の⽬指すところ良いテストに必要な考え⽅や基礎的な技術を俯瞰したいそこで、テストをフィードバックの⼀種として捉えて、良いテストを考える 11 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

さあ、良いフィードバック、良いテストを考えよう…︖ 良い◦◦は、⼤抵の場合、複数の条件が組み合わさって実現されており複雑逆に考えてみる悪いフィードバック、つまり、役に⽴たないフィードバックや、不満を感じるフィードバックの特徴を考えるフィードバックを受け取って「あまり役に⽴たないな」「不満だな」と感じたことはありますか︖ • ふりかえり •
⽬標管理 • ⽇常でのアドバイス • … 12 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

悪いフィードバックあるある 13 • それ、事実じゃないです • ⼤事なことはそれだけではないのに • 今更︖ • 何を⾔いたい︖ダメ出ししたいだけ︖
• あんな居⼼地悪い場で⾔わなくても • 部外者にあれこれ⾔われても… • もしや、好みを押し付けたいだけ︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

悪いフィードバックあるある 14 • それ、事実じゃないです • ⼤事なことはそれだけではないのに • 今更︖ • 何を⾔いたい︖ダメ出ししたいだけ︖
• あんな居⼼地悪い場で⾔わなくても • 部外者にあれこれ⾔われても… • もしや、好みを押し付けたいだけ︖ →内容がよくない →タイミングがよくない →伝え⽅がよくない →伝える場がよくない →伝える⼈がよくない →伝える理由が不適切 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

良いフィードバックをするために考慮が必要なこと • 正しい内容か • ⽬的にふさわしい内容か • 次のアクションに間に合うか • 要点が伝わる伝え⽅か •
伝えるのにふさわしい場か(場の空気) 伝えるのにふさわしい場か(物理的な場) • 説得⼒を持って伝えられる⽴場か • 受け⼿が納得できる理由に基づいているか 15 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

本講演のスコープ • 正しい内容か • ⽬的にふさわしい内容か • 次のアクションに間に合うか • 要点が伝わる伝え⽅か •
伝えるのにふさわしい場か(場の空気) 伝えるのにふさわしい場か(物理的な場) • 説得⼒を持って伝えられる⽴場か • 受け⼿が納得できる理由に基づいているか 16 こちらを扱うテストの場合、変えにくい改善や判断といったアクションを促すこと正確的確適時理解容易信頼構築 What When How Who Where Why 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

この講演の⽬指すところ良いテストに必要な考え⽅や基礎的な技術を俯瞰する要点テストは、フィードバックの⼀種である良いテストに必要なこと正確︓正しい理解に基づいた内容である的確︓⽬的にふさわしい内容である適時︓改善や判断のタイミングに間に合う理解容易︓改善や判断に必要な情報を理解してもらえる伝え⽅である信頼構築︓安⼼してフィードバックを受けられる場づくりに貢献できる
17 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは 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 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要求や設計を理解する • モデリング︖ • アドホックな図、DFD、
UML、SysML、ラルフチャート、状態遷移テスト、CFD、… • この資料での「モデリング」 • 何に着⽬するか、視点を決める。データ、⼊⼒値、状態、… • 視点に基づいて、知っていることの分解や統合をして、抽象度を調節する • 分解や統合した結果を相互に関連づけ、再構成する 20 着⽬する視点を決定分解、抽象化/具体化再構成(図⽰) 登録済未登録ユーザーID ⼊⼒なし⼊⼒ありパスワード⼊⼒なし⼊⼒ありメールアドレス登録処理エラー CFD(Cause Flow Diagram)の例 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要求や設計を理解する • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。申請者が申請ボタンを押すと、第⼀承認者が承認か不承認
のボタンを押せるようになる。第⼀承認者が承認ボタンを押すと第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承認者が、承認か不承認のボタンを押せるようになる。最終承認されると、申請者が確認ボタンを押せるようになる。確認ボタンが押された時、ワークフローが完了する。第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認者が未設定のときは、申請ボタンが押されると最終承認か最終不承認のボタンが押せるようになる。次にアクションを起こすべき⼈が気づけるように、承認ボタンや不承認ボタンが押されると、通知のためのメールが送信される。 21 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築 • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。申請者が申請ボタンを押すと、第⼀承認者が承認か不承認のボタンを押せるようになる。第⼀承認者が承認ボタンを押す
と第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承認者が、承認か不承認のボタンを押せるようになる。最終承認されると、申請者が確認ボタンを押せるようになる。確認ボタンが押された時、ワークフローが完了する。第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認者が未設定のときは、申請ボタンが押されると最終承認か最終不承認のボタンが押せるようになる。次にアクションを起こすべき⼈が気づけるように、承認ボタンや不承認ボタンが押されると、通知のためのメールが送信される。申請者要求や設計を理解する 22 アドホックなモデルでも、元の⽂より理解しやすい (不承認のフローは割愛) 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※図は当⽇限り

正確的確適時理解容易信頼構築 • 例題︓あるWEBワークフローシステム 1つのワークフローに1〜3名の異なる承認者を設定できる。申請者が申請ボタンを押すと、第⼀承認者が承認か不承認のボタンを押せるようになる。第⼀承認者が承認ボタンを押す
と第⼆承認者が、第⼆承認者が承認ボタンを押すと最終承認者が、承認か不承認のボタンを押せるようになる。最終承認されると、申請者が確認ボタンを押せるようになる。確認ボタンが押された時、ワークフローが完了する。第⼀、第⼆承認者の設定は任意。第⼀承認者と第⼆承認者が未設定のときは、申請ボタンが押されると最終承認か最終不承認のボタンが押せるようになる。次にアクションを起こすべき⼈が気づけるように、承認ボタンや不承認ボタンが押されると、通知のためのメールが送信される。申請者要求や設計を理解する 23 アドホックなモデルでも、元の⽂より理解しやすい (不承認のフローは割愛) 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※図は当⽇限り

正確的確適時理解容易信頼構築要求や設計を理解する • モデリングは難しい… • ⾃然⾔語は曖昧
• インプットとなるドキュメントや会話は⾃然⾔語でモデルより厳密でない • 逆に考える。曖昧な部分を洗い出すことも、モデリングの⽬的にする • 視点の明確化が必要 • データ構造か︖ 状態か︖ …適切なモデルを定めるのは難しい • 既存のモデリング技術を使う場合は、そのノウハウを活⽤できる • でも、価値あり • 俯瞰しやすくなる • インプットと異なる表現をすることで、理解できていないところが浮き彫りになる 24 俯瞰違う表現⽅法理解 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは 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 公開⽤資料

正確的確適時理解容易信頼構築的確、的を外していないとは︖ • 的は、実現すべき品質 • 明⽰的な品質要求だけでなく、暗黙的な品質要求もあるため
実現すべき品質を理解するには要求や設計の理解だけでは⾜りない • リスクを理解する …適時の説明で取り上げる • ソフトウェアを取り巻く⼈を理解する • ソフトウェアを取り巻く環境を理解する • 実現すべき品質を踏まえた上で、発想を広げて確度を上げる • 『QAの⼈たちはシステムを破壊する⽅法を⾒つける能⼒を買われて雇われている。深い専⾨性を持った⼈たちであり、ユーザーがシステムに対して⾏うあらゆる奇妙なことを予⾒できる。』 • 引⽤元︓ Robert C.Martin (著), ⾓征典 (翻訳), ⾓⾕信太郎 (翻訳), Clean Agile 基本に⽴ち戻れ, 初版, 株式会社ドワンゴ, 2020/10/5, PDF版, 95ページ 27 以降で、もう少し詳しく 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築⼈、環境を理解する • 要求も設計も実現すべき品質も、⼈が考え出すものである • ソフトウェアを取り巻く⼈、つまりステークホルダを理解する必要がある
• ステークホルダの要求、不安、コミュニケーションパスが要求や設計に影響する • 実現したい品質は、テスト対象それ⾃体だけで決まるわけではない • ソフトウェアを取り巻く環境を理解する • 競合製品や外部のルールが実現したい品質に影響する 28 環境ソフトウェア 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築⼈を理解する • ソフトウェアを取り巻く⼈を理解する 1. ステークホルダを洗い出す
• 体制図や⾃らの業務からステークホルダを探し、発⾒したステークホルダのコミュニケーション相⼿を探す 2. ステークホルダーを分析する • 浅く広く、狭く深くの２通りに分けられる • 浅く広く︓複数のステークホルダの関係分析 • ステークホルダマトリクス • 重要度(ステークホルダの要求の必要度合い)と意思決定への影響度合いとで評価、図⽰する • ユーザビリティ要求など要求ごとにつくる 29 重要度⾼い低い低い⾼い影響度ユーザ運⽤者プロダクトオーナー 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 • 参考⼀般社団法⼈情報サービス産業協会REBOK企画WG (編集), 要求⼯学実践ガイド REBOKシリーズ2, 初版, 近代科学社, 2014/3/31, 11-12ページ・183204ページ • 参考⼀般社団法⼈情報サービス産業協会REBOK企画WG (編集), 要求⼯学知識体系第1版, 初版, 近代科学社, 2011/6/30, 49-53 • 参考 https://www.ipa.go.jp/ﬁles/000005375.pdf 要求⼯学知識体系(REBOK)概説, 25ページ, 最終閲覧2020/11/29

正確的確適時理解容易信頼構築⼈を理解する • 浅く広く︓複数のステークホルダの関係分析 • 組織の構造やコミュニケーションパスの理解
• コンウェイの法則『システムを設計する組織は、その構造をそっくりまねた構造の設計を⽣み出してしまう』 • 『ソフトウェアにどれだけバグが含まれているかなどを⼤規模なプロジェクトで精査した結果、組織階層の深さや地理的に離れた複数⼈が関わるコード、離職者の数、関わっている開発者の⼈数など、コミュニケーションコストが⼀般に多くかかるであろう環境ほど、バグが多くなる傾向が発⾒されているのです。』 • 上記2箇所の引⽤元︓広⽊⼤地. エンジニアリング組織論への招待〜不確実性に向き合う思考と組織のリファクタリング (Japanese Edition) , 初版, 技術評論社, 2018/3/8(電⼦版2018/2/22), Kindle 版, Kindle の位置No.4164・ No.4168-4171 30 組織構造コミュニケーション品質 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築⼈を理解する • 深く狭く︓特定のステークホルダ、特にユーザの深堀分析 • ペルソナ
• 多数いるユーザーをグルーピングし、各グループの特徴をおさえた架空のユーザー像をつくる • 名前、プロフィール、プロダクトとの関わり、… • 具体的なユーザー像から、ユーザーがなにを考え、どう⾏動するかを考える • 参考︓ • 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 公開⽤資料

正確的確適時理解容易信頼構築環境を理解する • 例動画が多⽤され使い⽅が分かりやすく解説されているWEBサイト 32
品質は良い(悪くない)︖ それとも、悪い︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築ソフトウェアを取り巻く環境を理解する • 例動画が多⽤され使い⽅が分かりやすく解説されているWEBサイト •
帯域制限の影響を受けやすい⼈、ネットワークが遅く不安定な環境で使われる場合が多いと…︖ • 品質の良し悪しは、テスト対象のソフトウェアや機能それ⾃体だけでなく環境にも左右される • ステークホルダが使うデバイス、ネットワーク環境 • 競合製品 • 競合製品の⽅が洗練されていたら︖ 使える環境が多かったら︖ • 法律や、外部機関による検証や審査のルール 33 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる • ⼈や環境を基に実現すべき品質の理解を深めた後は、発想を広げる • テストと発想
• テスト担当者としての適正判断をするためのお題の例 …⾃動販売機のソフトウェアのテスト『筆者の理想としては、「韓国ウオンを⼊れて、その瞬間ケリを3発⼊れている間に、すべての指を使ってありったけのボタンを押す」なのですが、未だそのような答えをしてくれた⼈はいません。せめて、硬貨のコンビネーションとか同時にボタンを押す（組み合わせテスト）とか、多量のコインを⼊れる（⼤容量テスト）といった答えは欲しいものです。』 • 引⽤元︓⾼橋寿⼀ (著), 湯本剛 (著), 現場の仕事がバリバリ進むソフトウェアテスト⼿法, 初版, 技術評論社, 平成18年6⽉1⽇, 177ページ • まずは、ワークで、お互いの発想について知りましょう 34 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築ワーク [個⼈ワーク 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 ワークで、⾃分や他の⼈の発想の内容やインプットを知ることはできましたか︖ この後も発想についての話ですこのワークの内容を思い出しながら、聞いていただくと良いでしょう 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料 ※回答例は当⽇限り ※回答例は当⽇限り

正確的確適時理解容易信頼構築 • 発想を発散させた後、収束させてテストで利⽤する • 要求や設計や背景といったテスト対象の情報、実現すべき品質などを事前に理解する •
まずは発想を発散させ、その結果を収束させる。場合によっては、何度か繰り返す • 収束した結果を、テストケースなどへ反映する発想して、その結果をテストに活かすまで 37 発散させる抽象化具体化テスト対象の情報テストの⽬的収束させる発想の統廃合テストケースなどへ反映実現すべき品質 ? 必要な情報を得る活⽤する何を取っ掛かりに︖ どうやって︖ 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる • 『⼈間の脳にとっての⾃然な傾向は、最も確実なものの⾒⽅によって強い印象を刻まれ、そこから思考を進めていくことだ。この⾃然の傾向に打ち勝つためには、意識的、⼈為的にさまざまな⾒⽅を探し求める
必要がある。』 • 引⽤元︓エドワードデボノ (著), 藤島みさ⼦ (翻訳), ⽔平思考の世界固定観念がはずれる創造的思考法, きこ書房, 2015/11/8, 145ページ • ラテラルシンキング(⽔平思考)では視点を変えたり制約を外したりする • テストの場合︖ 何を取っ掛かりに︖ どのような⼿段で︖ 38 • 抽象的な知恵や標準から発想する • 具体的な事例や場⾯から発想する • 強制連想法、⾃由連想法を組み合わせる • モデリングする • モブ作業で発想する 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる取っ掛かり • 抽象的な知恵や標準から発想する • 組織標準や外部の規格などから、トップダウンで考える
• 組織標準のテストの分類、国際規格 ISO/IEC 25000シリーズ SQuaREの品質特性(品質モデル)、… • 標準や規格に囚われて実態とかけ離れないように注意 • 標準や規格に綺麗におさまるように考えるのではなく、実態を中⼼に考え標準や規格の取捨選択や優先順付けをする • 品質特性同⼠の間には、トレードオフがあるという意⾒もある • 例使⽤性のための処理が、性能効率性には負の影響を及ぼす • 「安全性」などの「品質属性」を定義、関係性を紹介している書籍もある • カールウィーガーズ(著), ジョイビーティ (著), 渡部洋⼦ (翻訳), 宗雅彦 (監修), ソフトウェア要求第3版 (Japanese Edition), 2014/12/19, Kindle 版, 14.5 品質属性のトレードオフ(Kindle の位置 No.8497) 39 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

余談︓狩野モデル • 魅⼒的品質、⼀元的品質、当り前品質…聞いたことはありますか︖ 40 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

余談︓狩野モデル充⾜している場合充⾜していない場合区分満⾜仕⽅ない魅⼒的品質要素（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 公開⽤資料

余談︓狩野モデル • 基となった論⽂では、5種類が提唱されていた • 魅⼒的品質、⼀元的品質、当り前品質、無関⼼品質、逆品質 • それぞれの品質要素は別の品質要素に変化することがある • 『また、ある時点まで魅⼒品質に分類できた機能も、競合他社が提供するようになればすぐ当たり前品質になってしまいます。⼀元的品質も同じで、突出したレベルにまで
⾼められれば魅⼒品質に転じることがある⼀⽅、陳腐化すれば当たり前品質に変質してしまうので、注意が必要です。』 • 引⽤元︓及川卓也, ソフトウェア・ファースト (Japanese Edition), 第1版,⽇経ＢＰ, 2019/10/15, Kindle 版, Kindle の位置No.1041-1044 42 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる取っ掛かり • 具体的な事例や場⾯から発想する • 事例や場⾯を探して、ボトムアップで考える
• 類似のプロダクトやプロジェクトの事例をテスト対象に当てはめる • 過去バージョン、類似した他社製品など、機能やユースケースに共通点がある他のプロダクト • 体制、システム構成、採⽤技術などに共通点があるプロジェクト • ⽐較や組み合わせ、その結果として起こりそうなことを考えてテスト対象に当てはめる • 機能同⼠、システム同⼠を⽐較、組み合わせて考える • データ、操作感、デザインの⽅向性など整合性を保つべき機能はあるか︖ • 他のシステムと組み合わせて使う際にスムーズに使えるか︖ • 時間の流れと組み合わせる • プロダクトのライフサイクル。企画、開発、運⽤、廃棄の各フェーズで何が起こるか︖ • インストール、マスタデータの更新や削除、バージョンアップ、… • データの増減があったら︖ 43 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築トップダウンとボトムアップ、いずれから始めても⼤事なこと • 抽象化と具体化を繰り返す • 『抽象化とは⼀⾔で表現すれば、
「枝葉を切り捨てて幹を⾒ること」といえます。⽂字どおり、「特徴を抽出する」ということです。』 • 引⽤元︓細⾕功(著), 具体と抽象(Japanese Edition), 初版, 株式会社ｄＺＥＲＯ, 2014/12/7, Kindle 版, Kindle の位置No.196-197 • 抽象化しないと、発想が広がらない具体化しないと、現状にどう適⽤するか分かりにくい、⼈により理解が異なりがち • 例︓前バージョンにて、会員退会処理で想定外のエラー → [抽象化]→ 会員状態の変更 → [具体化]→ ⼀時休会処理 → [抽象化]→ 会員状態の変更 → [具体化]→ 会員ランクのアップとダウン • 抽象化と具体化をしやすくするためにどうすればよいか︖ 44 発散させる抽象化具体化 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築 • モデリングをする • 正確なフィードバックだけではなく、的確なフィードバックにも効果的 •
発想を広げる上での効果 • 関連を持つもの同⼠や関連の内容が視覚的に表現され連想に役⽴つ • 同じ/逆の関連を持つものは他には︖ • 端的に表現しようとすることが抽象度の上げ下げの助けになる発想を広げる⼿段 45 着⽬する視点を決定分解、抽象化/具体化再構成(図⽰) 俯瞰違う表現⽅法理解関連から連想抽象的表現発想 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる⼿段 • 強制連想法、⾃由連想法を組み合わせて発想する • 強制連想法︓ガイドワードなどを使い、⽅向性を決めて発想する
• オズボーンのチェックリスト、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 公開⽤資料

正確的確適時理解容易信頼構築発想を広げる⼿段 • モブ作業をする • 利点
• 強みが違う⼈と⾏うことで、双⽅の知⾒を活⽤し、発想を広げやすくなる • 内部構造に詳しい開発者とテストに詳しいQA、機能Aに強い⼈と機能Bに強い⼈ • 注意点 • 1⼈ではできない • コストが冗⻑に⾒られがち • 効果を無視すると、1名での作業に⽐べて膨⼤なコストがかかる • しかし、育成、情報や経験の共有といった発想以外の効果もある • トラックナンバー(ハネムーンナンバー)の増加 • すべてをモブでやらなくてもよい。調査は個⼈作業、成果物作成はモブ作業など 47 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築モブ作業をする • モブ作業をする（続き） • 『しかし、冗⻑性を持つ組織を作ることは、知識創造プロセスの
マネジメントにとって⾮常に重要である。なぜならそれは、頻繁な対話とコミュニケーションを促進するからである。冗⻑性は、社員のあいだに「認識上の共通基盤」を創り、暗黙知の移転を助けるのである。組織成員は情報を重複共有してこそ、お互いが四苦⼋苦しながら表現しようとしていることをわかり合える。この情報共有という冗⻑性によって、新しい形式知が組織全体に広まり、⼀⼈ひとりのものになるのである。』 • 引⽤元︓野中郁次郎,⽵内弘⾼. 知識創造企業 (Japanese Edition) (Kindle の位置No.475-479). Kindle 版. 48 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

余談︓集まってコミュニケーションをとることの効果 • レビューにおける効果 • 『「ファントムインスペクター（phantominspector）」というレビュー⽤語をご存じでしょうか。ファントムとは幻のことで、インスペクターはレビューアーと同じ意味で⽤いられています。つまり「幻のレビューアー」というわけです。レビューアーが個別にドキュメントをチェックしたときには⾒逃した問題が、レビュー会議で集まって話し合うとスムーズに⾒つかるという効果を意味します。』 •
『ファントムインスペクターは主に、1⼈のレビューアーの指摘内容から他のレビューアーが気付きを得ることによって⽣まれます。』 • 上記2箇所の引⽤元︓森崎修司, なぜ重⼤な問題を⾒逃すのか︖間違いだらけの設計レビュー [改訂版] (Japanese Edition) , 初版, ⽇経BP, 2015/9/15, Kindle 版, Kindle の位置No.381-384・No.387-388 49 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

余談︓ブレーンストーミングの注意点 • ブレーンストーミング • グループで多様なアイディアを出したいときに、よく⾏われるが… 多様な意⾒を効率的に取得できるわけではないという研究結果がある • 原因は、⼀説として • ブレーンストーミングでは同時に複数⼈が発⾔できない。
また、別の⼈の話を聞いているうちに忘れたり、発⾔をやめてしまったりすることがある • 他の⼈から評価される懸念 • ただ乗り、さぼり • やり⽅を⼯夫して効率的、効果的に • コラボレーションツールを使って他の⼈の発⾔中もアイディアを発信できる仕組みの構築、⼼理的安全性の確保、等 • 参考︓鈴⽊宏昭, 認知バイアス⼼に潜むふしぎな働き (Japanese Edition) ,株式会社講談社, 2020/11/1, Kindle 版, Kindle の位置 No.2046-2073 • 参考︓⻲⽥達也 (著), 認知科学モノグラフ③ 合議の知を求めて―グループの意思決定, 初版, 共⽴出版, 1997/2/5, 111-116ページ 50 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

お話しすること ü テストはフィードバックの⼀種である ü 良いフィードバック、良いテストとは ü What ü 正確 ü
要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる p When p 適時 p テストの順序をリスクに基づいて決める p プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づくりに貢献する p おわりに 52 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築 • 早くフィードバックが得られると、どんな嬉しいことがあるか︖ • すぐに対応すべき重⼤な問題について、対応の時間が⼗分とれる •
重⼤な問題がない⾒通しが⽴てば、別のことができる • 重⼤な問題︖ • ⼈命や健康、⾦銭を左右しかねないバグ • ビジネスへの影響が⼤きい部分のテスト結果 • 多くの⼈から、よく使われる機能の問題 • 影響⼒の⼤きいユーザーが頻繁に使う機能の問題 • ウリになる機能など、顧客を獲得・維持する上で重要な機能の問題より早く欲しいフィードバックは何か︖ 53 ひょっとすると起こるかもしれないことリスク 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築リスクに応じたフィードバックをする • リスクとは︖ • 『リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクの
レベルは、そのような事象が起きる可能性とその影響（事象による結果がもたらす損害）で決まる。』 • 引⽤元︓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 公開⽤資料

正確的確適時理解容易信頼構築リスクに応じたフィードバックをする • バグによるリスクが危害を及ぼすまでのイメージ
• 事象⾃体だけでなく、事象の源なども考慮する • 1種類の事象に複数の⽋陥やエラーが影響することも 55 状況例︓コーディングルールの未整備 • 図「バグでリスクが発⽣する場合」の枠内の引⽤元︓ https://www.slideshare.net/goyoki/ss-29203311 リスクベースドテストを活⽤しよう,11ページ, 最終閲覧2020/11/29 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築 • リスク管理プロセスリスクに応じたフィードバックをする 56 計画
識別分析対応、残余リスク確認 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築 • テストがリスク管理プロセスに与える影響 • 適切なタイミングで対応結果を確認できるようにテストをしなくてはならない •
例完成に近づいてからしかテストできないが、想定外のことが⾒つかると修正に時間がかかる • シミュレーターを使って先⾏して⼀部のテストを⾏う、等リスクに応じたフィードバックをする 57 計画識別分析対応、残余リスク確認テストの分析や設計中にリスクに気づくことがある対応結果(の⼀部)を、テストで確認する 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築リスクに応じたフィードバックをする • リスクがテストに与える影響 • リスクからわかったことをテストの優先順に反映させることで適時なフィードバックに
• テストを、リスクとの関連性(テストの⽬的やスコープなど)により、分割して考える • 例機能テスト→顧客向け機能テスト／管理者向け機能テスト • 適時だけでなく、リスクを理解することは様々な⾯でテストの最適化に繋がる • フィードバックの正確さ、的確さにもプラスの影響がある 58 プロダクトリスクバグやバグが引き起こす問題使いにくさ … プロジェクトリスク⼈員不⾜⾒積もりミス … テストの順序テストの規模(厚み) 必要スキルテストプロセス 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築これで⼗分︖ • ちょうど良いタイミングでフィードバックできるようにするには︖ • リスクに基づいてテストの優先順を決める
• プロジェクト全体における適時を考える • 動的なテストは、実際にソフトウェアを動かすので、遅くなりがちで⾼くなりがち • バグが顕在化してから潰し込むより、予防できる⽅が良い 59 テストプロセスの中で要件設計実装テスト要件設計実装テスト 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築プロジェクト全体における適時を考える • なるべく早くフィードバックができるとよい • 受け⼊れテストやユーザストーリーを検討する会話、
設計のレビュー … • 『テスト担当者、開発者、ビジネス代表者がフィーチャの検討すべてに参加するというコンセプトは、「三⼈の⼒」として知られている[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 公開⽤資料

正確的確適時理解容易信頼構築プロジェクト全体における適時を考える • 何をフィードバックするか︖ • 要求や設計
• 曖昧な点。コミュニケーションミスを予防するため • テストの事前条件や期待結果を特定できる⾒込みか︖ 影響範囲は︖ • 現バージョンとの振る舞いとの整合性 • リスク(になりそうなもの)。事前に分かれば、予防や対応準備ができるようにするため • 過去のバグやユーザからの問い合わせ、競合製品との差異 • テストの⽅法。テスタビリティを確保するため • どうやって検証するか︖ テストオラクルは︖ テスト環境は︖ • 例現在時刻をインプットとする処理に対し、テスト中インプットの時刻を⼈為的に変更できる仕組みを追加する • テストの効率性、有効性が確保しやすくなるよう相談や提案をする • 参考 https://thinkit.co.jp/article/14136 連載 [第8回] : 開発現場で役⽴つテスト「超」実践講座「テスタビリティ」を作り込む, 最終閲覧2020/12/13 61 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

余談︓プロセス改善の⼿法 • 適時を追求した結果、プロセス改善が必要になることがある • 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 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える p How p 理解容易 p 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づくりに貢献する p おわりに 64 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築「理解容易」って︖ • 得た情報の取捨選択や加⼯の仕⽅に気を付けましょうというお話 • 気をつけて伝えなくてもフィードバックが活⽤されるなら、問題なし
• 得意分野も状況も異なる⼈同⼠、コミュニケーションにノイズは付き物 • テスト結果の伝達までを責務とするか︖ 価値あるプロダクトの提供までを⽬指すか︖ • 『テストを担当したら，バグ報告できない⼈たちの代弁者となれ』 • 引⽤元︓Cem Kaner (著), James Bach (著), Bret Pettichord (著), テスト技術者交流会 (翻訳), ソフトウェアテスト293の鉄則, 初版,⽇経BP, 2003/4/21, 78ページ • 次ページから、関わる⼈が多く⼈による差が出やすいバグレポートを取り上げる • レポート⼀般の話は避け、バグレポートならではの理解容易を考える • フォーマットや組織体制の考慮も不可⽋だが、今回はフィードバック内容に注⽬する 65 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要点をわかりやすく表現する • バグレポートを利⽤する⼈にとっての要点をわかりやすく • バグを直す⼈
• バグの対応優先順を決める⼈ • バグを直す⼈にとっての要点 • オープンソースのバグレポートの研究より • 『開発者たちから得られた反応から、スタックトレース、バグの再現⼿順、期待された振る舞い、観察された振る舞いが、バグ解決時に重要であることが分かりました。』 • 実際に起きた事象(事実)と、本来あるべき状態を正しく理解しないとバグは直せない • 『最も重⼤な問題は、バグ再現⼿順の間違いと情報の不完全さです。』 • 上記２点の引⽤元︓Andy Oram (編集), Greg Wilson (編集), 久野禎⼦ (翻訳), 久野靖 (翻訳), Making Software ―エビデンスが変えるソフトウェア開発, 初版, オライリージャパン, 2011/9/22, 418・424ページ 66 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料バグレポートの利⽤者のうち、今回焦点を当てる⼈

正確的確適時理解容易信頼構築要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点 • 事象だけでなく、その影響が分からないと、対応優先順は決められない
• 架空の⽇報システムのバグレポートより…これは急いで直すべきバグか︖ • データ削除の権限を持たないユーザーでログインして、管理画⾯を表⽰させると [データ全削除] ボタンが表⽰される 67 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点(続き) • 事象だけでなく、その影響が分からないと、対応優先順は決められない
• 架空の⽇報システムのバグレポートより…これは急いで直すべきバグか︖ • データ削除の権限を持たないユーザーでログインして、管理画⾯を表⽰させると [データ全削除] ボタンが表⽰される • [データ全削除] ボタンをクリックするとデータが全削除される →急ぐ • [データ全削除] ボタンをクリックしても、データ削除は起こらない →︖ • 「権限がありません」とメッセージが表⽰される • ボタンに⾒えるが、クリックしても何も起こらない 68 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要点をわかりやすく表現する • バグの対応優先順を決める⼈にとっての要点(続き) • 事象だけでなく、その影響が分からないと、対応優先順は決められない
• 『障害レポートを商売道具として活かせ』 • 修正した場合に得られるものを明確に伝えて売り込む • 受け⼊れられないことを予期して情報をまとめ報告する • 『』内の引⽤元︓Cem Kaner (著), James Bach (著), Bret Pettichord (著), テスト技術者交流会 (翻訳), ソフトウェアテスト293の鉄則, 初版,⽇経BP, 2003/4/21, 74-75ページ • 事象をユーザーが⾃ら回避する⽅法があるか︖ • 事象により発⽣したエラー画⾯などからユーザーが⾃ら復帰する⽅法はあるか︖ • 正常フローへ戻ったり操作をやり直したりする⽅法はあるか︖ • 事象を点ではなく、ユーザーが⽬的達成するためのフローの⼀部として考える 69 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築要点をわかりやすく表現する • 書籍「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

要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える ü How ü 理解容易 ü 要点をわかりやすく表現する p Where p 信頼構築 p 安⼼してフィードバックをやりとりできる場づくりに貢献する p おわりに 72 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築信頼してフィードバックできる場づくりに貢献する • 効果的で効率的なフィードバックには、率直な話をしても⼤丈夫だと信頼しあえる雰囲気が必要 •
周りのステークホルダと対⽴している場では、フィードバックは受け⼊れられにくくなる • 『ほとんどの⼈が、私が対⼈リスクと呼ぶもの、つまり他の⼈にばかにされるリスクを何とかしなければならないと思っている。とりわけ職場で、わけても上司や公式権⼒を持つ⼈の前でイメージを傷つけられるのを最⼩限に⾷いとめるためである。そのための⼀つの⽅法が、⾃分が正しいと⾃信が持てないときは意⾒を⾔わないこと、間違いを認めないこと、そして⾔うまでもないが、絶対に質問しないこと、利点を確信できないちょっと思いついただけのアイデアは⼝にしないことなのだ。』 • 引⽤元︓エイミー・Ｃ・エドモンドソン (著), 野津智⼦ (翻訳), チームが機能するとはどういうことか「学習⼒」と「実⾏⼒」を⾼める実践アプローチＥＰＵＢ版(Japanese Edition), 英治出版株式会社, 2014/5/31(EPUB版2014/9/5), Kindle 版, Kindle の位置No.1173-1178 73 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築信頼してフィードバックできる場づくりに貢献する • しかも、テスト活動でよく登場するバグの話は、プロジェクトやステークホルダーを脅かすものとして捉えられやすい •
バグの報告が、設計者や実装者に対する⾮難と捉えられる • プロジェクトの進⾏の邪魔と捉えられる • バグレポートが争いの場になったり、役に⽴たないと⾔われ続けると、他に誰も気づいていない⼩さな違和感や、重⼤だが確証が得られない問題をフィードバックしにくくなる • 組織の場の雰囲気まるごとを、個⼈で⼤きく改善することは難しいしかし、悪化を防いだり、⾝の回りの雰囲気を変えたりすることはできる 74 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

正確的確適時理解容易信頼構築信頼してフィードバックできる場づくりに貢献する • フィードバックで信頼を構築する • 個⼈への指摘と、プロダクトへの指摘を混同しない
• 先ほど紹介した『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 公開⽤資料

要求や設計を理解する ü 的確 ü ⼈を理解する ü 環境を理解する ü 発想を広げる ü When ü 適時 ü テストの順序をリスクに基づいて決める ü プロジェクト全体における適時を考える ü How ü 理解容易 ü 要点をわかりやすく表現する ü Where ü 信頼構築 ü 安⼼してフィードバックをやりとりできる場づくりに貢献する p おわりに 77 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

おわりに • ところで… プロジェクトの関係者全員が、「うまく動くはず」と思い込んでいたら、何が起こるだろうか︖ • 確証バイアス • 『私たちは，⾃分の仮説に合う事例ばかりを探し，⾃分の仮説に合わない事例を探そうとしない傾向があり，
これを確証バイアス（confirmation bias）という。』 • 引⽤元︓服部雅史; ⼩島治幸; 北神慎司. 基礎から学ぶ認知⼼理学――⼈間の認識の不思議有斐閣ストゥディア, 電⼦書籍PDF版Ver.1.0, 株式会社有斐閣, 2016/3/22, Kindle 版, 131ページ 78 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

おわりに • ところで… プロジェクトの関係者全員が、「うまく動くはず」と思い込んでいたら、何が起こるだろうか︖ • 確証バイアス • 「私たちは，⾃分の仮説に合う事例ばかりを探し，⾃分の仮説に合わない事例を探そうとしない傾向があり，
これを確証バイアス（confirmation bias）という。」 • 引⽤元︓服部雅史; ⼩島治幸; 北神慎司. 基礎から学ぶ認知⼼理学――⼈間の認識の不思議有斐閣ストゥディア, 電⼦書籍PDF版Ver.1.0, 株式会社有斐閣, 2016/3/22, Kindle 版, 131ページ • ソフトウェア開発では、⼤半の⼈はうまく動かすことに関⼼がある • ⼀⽅、テストをするときは、うまく動かせないことにも⽬を向けざるを得ない • テスト担当者のフィードバックにより、実態により即した判断や改善ができる 79 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

おわりに • フィードバックを効果的に伝えるには様々な考慮が必要 • 内容はもちろん、伝え⽅やタイミングが効果を左右することがある • 正確、的確、適時、理解容易、信頼構築 • 今⽇お話ししたのは、基礎的な考え⽅や技術の俯瞰興味がある技術は、後⽇、ぜひ深堀りしていただければと思います
良いテスト、良いフィードバックを通してプロダクトの価値向上に貢献しましょう 80 [Special Thanks to] レビュアーの井芹洋輝さん、機会をくださったWACATE実⾏委員会のみなさん 2020/12/19 WACATE2020winter Kumiko Iseri 公開⽤資料

参考⽂献本⽂中で触れていない⽂献のみ、以下に掲載する。 • 良いフィードバック、良いテストとは • 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 公開⽤資料

wacate2020w

wacate2020w

More Decks by k.i.

Other Decks in Technology

Featured

Transcript