Slide 1
Slide 1 text
Agile Testing Days
参加報告
風間 裕也
Slide 2
Slide 2 text
Agile Testing Days とは
Slide 3
Slide 3 text
Agile Testing Daysとは
● ポツダムで11月上旬に毎年開催
● 期間は6日間（チュートリアル2日＋本会議4日）
● ホテルで開催
○ 当日の雰囲気は11/26のイベント（座談会）で話す
■ https://wingarc1st-spqi.connpass.com/event/155552/
● 朝・昼・晩の食事付き
● 参加費は約30万円（早割あり）
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
Day 1
Slide 6
Slide 6 text
Day 2
Slide 7
Slide 7 text
Day
3
Slide 8
Slide 8 text
Day
4
Slide 9
Slide 9 text
Day
5
Slide 10
Slide 10 text
Day
6
Slide 11
Slide 11 text
印象に残ったセッションの紹介
Slide 12
Slide 12 text
https://twitter.com/LadyXochi/status/1191265231160385536
Slide 13
Slide 13 text
Test Strategy Workshop
概要
● テスト戦略についてのワークショップ
● 前半はテスト戦略の考え方についての講義
● 後半は実在する題材を用いてテスト戦略を考えてみて、
最終的にテストまで行なった
Slide 14
Slide 14 text
Test Strategy Workshop
● なぜテスト戦略を作るのか？を考えよう
● プロダクトも違うのに、なぜ同じテンプレートなのか？
○ 製品に関わるチームや人に対してテスト戦略を作る
● I ALWAYS create test plan.
● Scrumチームが壊れる原因の一つとして、
Testerが成果物をチェックする役目に成り下がる
Slide 15
Slide 15 text
Test Strategy Workshop
● メトリクスは危険。
○ メトリクスはたまにミスの方へ導いてしまう。
○ メトリクスに対しては慎重になる必要がある。
● Product Coverage Outlines(PCO)を作成しよう
○ テストで関心のある領域を特定するため
○ チームメンバーから賛同を得るため
○ テストの優先順位づけを支援するため
Slide 16
Slide 16 text
Test Strategy Workshop
● Release Coverage Outlines(RCO)を作成しよう
○ リリースで達成される全体的なテスト範囲を迅速かつ
有意義な方法で示すために使用する
○ 深いところまで行かないマインドマップで作る
○ 主にインタフェースと機能部分に焦点を当てる
○ 全ての（主要な）回帰領域と
新しい機能/領域/バグ修正は「ズーム」して考える
Slide 17
Slide 17 text
Test Strategy Workshop
● このワークショップでは、付録として
「Test Strategy Workshop Handbook」を頂いた。
● その内容の一部を紹介。
● 日本語訳したものは後日公開予定。
（本人より承諾済み）
Slide 18
Slide 18 text
Test Strategy Handbook 目次
● テスト戦略で達成すべき結果
● テスト戦略とは何か
● コンテキストを理解するために必要なBUTT
● ヒューリスティックテスト戦略モデル
○ MIDTESTD
○ SFDIPOT
○ CRISP DUCCS
○ FDSFSCURA
Slide 19
Slide 19 text
コンテキストを理解するために必要なBUTT
テスト戦略を考えるにあたり、
まずは下記の側面(BUTT)を理解する必要がある。
● Business driver
● Usage
● Technology
● Team
Slide 20
Slide 20 text
ビジネスドライバー(Business Driver)
● クライアントは誰ですか？
● 製品はクライアントにとってどのような問題を解決しますか？
● 製品が解決されるとできる他の問題（間違った使い方）は何ですか？
● 製品はお客様にどのような価値を提供しますか？
● 内部および外部の顧客の考えにある製品のイメージは何ですか？
● 契約、罰則、またはその他の法的義務はありますか？
● 競合他社は（現在もしくは将来）ありますか？
● これはどのくらいのビジネスチャンスですか？
● なぜこの製品が構築されているのですか？なぜ今なのですか？
● 市場の力とプロジェクトの推進力について知っていますか？
Slide 21
Slide 21 text
使用方法(Usage)
● さまざまなタイプのユーザー（知っている人、ペルソナ）、
さまざまなニーズ、さまざまな感情、さまざまな状況は何ですか？
● 彼らはどのように製品を使用しますか？（シナリオ）
● 彼らはどのように製品を誤用しますか？
● 「良い」ユーザーは間違って何をするのでしょうか？
● 悪意のあるユーザーは何をしようとしますか？
● 新しいテスト方法につながるような変更はありますか？
● 現在の状況で、他にテスト対象に影響するものは何ですか？
● エンドユーザー、プリセールス、販売、マーケティング、コンサルタント、サポート担
当者にインタビューし、顧客のニーズについてさらに理解しよう
● 彼らが好きなものと嫌いなもの、
ソフトウェアの隣で何をするのかを見つけましょう。
Slide 22
Slide 22 text
技術(Technology)
アーキテクチャ
● データの依存関係（ソース）
● データ出力
● 製品を流れるデータ
● 他の製品/機能/システムへの依存関係は何ですか？
● 製品に依存している他の製品/機能/システムは何ですか？
プラットフォーム
● 製品の言語は何ですか？
● どのサーバーとサービスが使用されていますか？
○ ロードバランサー、スプーラー、ネットワークデバイスなど
Slide 23
Slide 23 text
チーム(Team) その1
あなたのチームについて
● あなたのチームには誰がいますか？
○ 彼らの役割は何ですか？
○ 彼らはあなたにどんなドキュメントを期待していますか？
● どのチームとやり取りする必要がありますか？
○ 彼らの役割と責任は何ですか？
○ 彼らはあなたが誰であり、 あなたが彼らに何を期待しているかを知っていますか？
● プロジェクトとその人々には、どの長所と短所がありますか？
● これらの項目に対して一連のテストアイデアをマッピングできるようにするためのプ
ロジェクトの技術的負債は何ですか？
● 開発者にコードのどの部分を改善したいのか尋ねてください。
● 開発者はどの機能で問題を抱えていますか？
Slide 24
Slide 24 text
チーム(Team) その2
他のチームについて
● 知っておく必要のある習慣や伝統はありますか？
● 文化の違いと、それがあなたとあなたの仕事にどのような影響を与えるかを知って
いますか？
● あなたの利害関係者は誰ですか？
● 利害関係者が本当に心配していることは何ですか？
● 他の利害関係者は誰ですか？
● 他の人によってテストされているものは何ですか？
Slide 25
Slide 25 text
Test Strategy Handbook 目次
● テスト戦略で達成すべき結果
● テスト戦略とは何か
● コンテキストを理解するために必要なBUTT
● ヒューリスティックテスト戦略モデル
○ MIDTESTD
○ SFDIPOT
○ CRISP DUCCS
○ FDSFSCURA
Slide 26
Slide 26 text
https://twitter.com/jrosaproenca/status/1192010123679535104
Slide 27
Slide 27 text
10分間で探索的テストを説明する方法
発表資料
● https://www.slideshare.net/KristineCorbus/how-to-explain-exploratory-testing-in-10min
Slide 28
Slide 28 text
10分間で探索的テストを説明する方法
探索的テストのポイント
1. 探索的テストはリュックサック1つで旅行するようなもの
Slide 29
Slide 29 text
10分間で探索的テストを説明する方法
Let’s play the game!
● 私に向けて最大20個の質問をしてください
● 3分以内に、私が思い浮かべているものを当ててください
● Yes/Noのみで答えます
● みんなが知っているものです
● それは大きいです
Slide 30
Slide 30 text
10分間で探索的テストを説明する方法
ふりかえり
● どうでしたか？
● 他にどんなことができたでしょうか？
Slide 31
Slide 31 text
10分間で探索的テストを説明する方法
ふりかえり
● どうでしたか？
● 他にどんなことができたでしょうか？
○ 以前にこれを行なった結果
■ メモを作ってない
■ 他人の話を聞かない
■ 戦略を持っていない
Slide 32
Slide 32 text
10分間で探索的テストを説明する方法
探索的テストのポイント
1. 探索的テストはリュックサック1つで旅行するようなもの
2. 探索的テストは野生の勘ではない
Slide 33
Slide 33 text
10分間で探索的テストを説明する方法
aSPAを意識しよう
● aim（目的）
● Sense（感覚）
● Protocol（やりとり）
● Analyse（分析）
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
10分間で探索的テストを説明する方法
● 探索的テストのポイント
1. 探索的テストはリュックサック1つで旅行するようなもの
2. 探索的テストは野生の勘ではない
3. 探索的テストは4つのイベント（aSPA）を持つ
タイムボックスで区切られた継続的な活動
これらの考え方を持って探索的テストをやろう！
Slide 36
Slide 36 text
https://twitter.com/mirjanakolarov/status/1192385550055022592
Slide 37
Slide 37 text
What do you mean... a Quality Owner?!
発表内容
● https://www.youtube.com/watch?v=jlygHJIFjTA
Slide 38
Slide 38 text
What do you mean... a Quality Owner?!
2007年時点
1. 新しい仕事が来る
2. 開発者が開発をする
3. QAが手動テストをする
4. QAが自動テストをする
5. バグが発生したら開発者が修正する
6. ドキュメントを書く
Slide 39
Slide 39 text
What do you mean... a Quality Owner?!
2007年時点
1. 新しい仕事が来る
2. 開発者が開発をする
3. QAが手動テストをする
4. QAが自動テストをする
5. バグが発生したら開発者が修正する
6. ドキュメントを書く
会場から「Oh...」というため息が漏れる
Slide 40
Slide 40 text
What do you mean... a Quality Owner?!
問題点
● 開発の外でテストしなかった
● 自動化におけるテスタビリティが足りていなかった
● 重い、遅い、Flakyが発生していた
● 品質への意識が足りていなかった
1つ1つは小さな問題だが、集まるとかなり大きな問題だった
Slide 41
Slide 41 text
What do you mean... a Quality Owner?!
品質のスペシャリストを採用
● DevOpsの考え方を用いてtrunkベースの開発に移行
● CI/CDパイプラインを作った
● フィードバックを短縮した
何かが足りない…
もっと全体的なアプローチを望んでいた
Slide 42
Slide 42 text
What do you mean... a Quality Owner?!
QA Ownerの採用（2017年）
QA Ownerとは…
● 開発者
● 品質エキスパート
● コーチ
● エバンジェリスト
Slide 43
Slide 43 text
What do you mean... a Quality Owner?!
QA Ownerのタスク
● リスク分析
● リスク管理
● リスク軽減
● テスト戦略
● テスト管理
● テスタビリティ
Slide 44
Slide 44 text
What do you mean... a Quality Owner?!
QA Ownerのタスク
● デリバリを増加させる
● 水平展開
● ドッグフーディング
● DevOpsやCI/CDでチームを教育する
Slide 45
Slide 45 text
What do you mean... a Quality Owner?!
3年間での変化
● Feature TeamからComponent Teamに変化させた。
Slide 46
Slide 46 text
No content
Slide 47
Slide 47 text
What do you mean... a Quality Owner?!
3年間での変化
● Feature TeamからComponent Teamに変化させた。
○ Feature Teamでは、
特定のチームが特定のテストを所有していなかった。
○ チーム全体がテストを所有していたが、
だれもテストに責任を感じていなかった状況を打破
Slide 48
Slide 48 text
What do you mean... a Quality Owner?!
開発チームがテストをすることが重要
開発者はテストしない多くの理由を考えることができる
● 費用対効果が低いから
● 後でテストするから
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
What do you mean... a Quality Owner?!
開発チームがテストをすることが重要
開発者はテストしない多くの理由を考えることができる
● 費用対効果が低いから
● 後でテストするから
→ 倒れるかもしれない家を作っているようなもの
● 我々は単なる開発者ではなくエンジニア
● 品質の責任を受け入れる必要がある
Slide 51
Slide 51 text
What do you mean... a Quality Owner?!
開発チームがテストをすることが重要
意識づけをするための行動
● 小さく始める。
○ 早期にやりたがる1,2名を選んで作業をする
● 経営陣に説得する
テストがない状態でQA Ownerがいなくなることはない。
Slide 52
Slide 52 text
What do you mean... a Quality Owner?!
品質成熟度レベル1
● 探索的テスト
● バグ分析
Slide 53
Slide 53 text
What do you mean... a Quality Owner?!
品質成熟度レベル2
● Frameworkの利用
● ツールの利用
● 基準やガイドラインの設定
Slide 54
Slide 54 text
What do you mean... a Quality Owner?!
品質成熟度レベル3
● フィードバックループの構築
● CI/CD
● より早くリリース
● モノリスからの脱却
● observability（可観測性）
Slide 55
Slide 55 text
What do you mean... a Quality Owner?!
最初は懐疑的だった人も、下記の価値をすぐに認識した。
● チームのリスクを軽減した
● 優れた品質の実践を学習できるようになった
Slide 56
Slide 56 text
No content
Slide 57
Slide 57 text
TESTERS, ARE YOU REALLY ENGAGED?
発表者はセキュリティエンジニア
セキュリティに対する認識とテストに対する認識は似ている
Slide 58
Slide 58 text
https://www.youtube.com/watch?v=J2uhWTFvug8
Slide 59
Slide 59 text
TESTERS, ARE YOU REALLY ENGAGED?
テストは次のように捉えられたりする
● コストセンター
● 結果ではなくツールに焦点が当たる
● 価値駆動ではなくチェックボックスを見るため
● コラボレーションやトレーニングが欠如している
Slide 60
Slide 60 text
TESTERS, ARE YOU REALLY ENGAGED?
テストを儀式にしないために、投資する必要がある。
● ドメイン知識
○ あなたの会社が何をするのか、どのように稼ぐのか…
● コードを学ぶ
○ 本格的はちょっと…でも、コードを読んでレビューを
● シェアする
○ 学習と経験を共有し、他の人を助ける
○ 職場での講義、イベントでの講演、ブログの公開など
Slide 61
Slide 61 text
TESTERS, ARE YOU REALLY ENGAGED?
テスターのスキル
● 質問する力
● 観察力
● 素早く学ぶ力
● バグの調査能力
● 批判的な思考力
● 水平思考力
● コミュニケーション能力
Slide 62
Slide 62 text
TESTERS, ARE YOU REALLY ENGAGED?
Be that team, Be that guy
● 実践的なリーダー/マネージャーになる
○ 行う方法を示す。仕事や経営の立ち向かい方を教える
● 細かな管理はせず、助ける
○ 他の人が苦労しているのを見たら踏み込む。
● ペアワークをする
● チームをカンファレンスに参加させる
○ 学ぶ機会を与える。良いチームの構築に投資する。
Slide 63
Slide 63 text
https://twitter.com/Maaikees/status/1192776756014526464
Slide 64
Slide 64 text
Uncomfortable Questions about Testing Addressed
発表資料
● https://t.co/pEGEj663b1?amp=1
Slide 65
Slide 65 text
Uncomfortable Questions about Testing Addressed
● 発表のテーマ…なぜ我々はここにいるのか？
● 人々は不快な事実よりも心地よい嘘に流れていく
○ 手を洗うことが命を救うことが証明されたとしても
すぐにそれを定期的に行う必要性を感じなかった
○ 認知的不協和が発生している
● テストにおける認知的不協和
○ 「AIを使用したコードレスな自動化ツール」といった
単純な策で複雑な問題を解決できると信じたい
Slide 66
Slide 66 text
Uncomfortable Questions about Testing Addressed
● 認知的不協和の定義（1956年）
○ 態度と行動が対立しているという認識から生じる、
2つの思考または認識が一致しない場合に
発生する心理的緊張の不快な状態。
Slide 67
Slide 67 text
Uncomfortable Questions about Testing Addressed
● 確認バイアス
○ 既存の信念を支持する情報のみが表示されている状態
● 認知的不協和
○ 我々はそれが本当だと真面目に信じている状態。
○ 嘘と真実の両方になり得る。
● 経験によってあなたの信念は変わっていく。
Slide 68
Slide 68 text
No content
Slide 69
Slide 69 text
Uncomfortable Questions about Testing Addressed
● カンニングするかどうかの例
○ 誠実さを保つ
■ 不正行為は不道徳である。
■ 不正行為者は学校から追放されるべき。
○ テストに合格する必要がある
■ 私はリスクをとった。
■ みんなカンニングしている。
● ピラミッドの底＝内面化された信念
Slide 70
Slide 70 text
Uncomfortable Questions about Testing Addressed
● 「テスターの投資なしで
ソフトウェア開発を行うことはできるか？」
○ 「あなたはクレイジーなのか？」
テスターの貢献が必要ない訳がない。
○ テスターなしで開発している多くの製品は、
プロのテスターなしでも正常に機能している。
Slide 71
Slide 71 text
No content
Slide 72
Slide 72 text
Uncomfortable Questions about Testing Addressed
● テストが必要かどうかの例
○ 常にバグがある
■ 問題を素早く修正すれば良い
■ テストはボトルネックになる
○ バグを見つけます
■ 適切なテストプロセスは品質を向上させる。
■ テストは必要です
Slide 73
Slide 73 text
Uncomfortable Questions about Testing Addressed
● 発表のテーマ…我々はなぜここにいるのか？
○ テスターの集まりは、
心を安らかにするための場所に過ぎないのでは？
● 重要なのは、様々な意見や視点を皆が持っていること
○ 我々が学ぶ方法にも繋がる
● 心を開き、様々なカンファレンスに行き、
様々な本を読みましょう。
Slide 74
Slide 74 text
Uncomfortable Questions about Testing Addressed
● 不快に感じるのは普通のことです。
○ 簡単な方法で自分に嘘をつきたいですか？
○ その感情を引き起こしているものを
掘り下げて調べたいですか？
● 認知バイアスまたは確認バイアスが発生しているか
考えてみましょう。
● 我々は人間なので、間違っていても大丈夫です。
● テストを再考し、価値を再考しましょう。
Slide 75
Slide 75 text
https://twitter.com/lisacrispin/status/1192834355674132480
Slide 76
Slide 76 text
I can’t do this… alone! A Tale of Two Learning Partners
発表資料
● https://www.slideshare.net/lisihocke/i-cant-do-this-alone-a-tale-of-two-learning-partners-agile-testing-days-2019
Slide 77
Slide 77 text
I can’t do this… alone! A Tale of Two Learning Partners
● 2016年のAgile Testing Daysで2人は出会った
○ ドイツ（ミュンヘン）と南アフリカ
○ 学習パートナーとして一緒にやっていくことを決めた
■ 公に発表することを提案した
■ 勇気を出して次のステップへ進んだ
Slide 78
Slide 78 text
I can’t do this… alone! A Tale of Two Learning Partners
● ペアリングを行なっていった
○ 2週間ごとに1時間のビデオ会議を行った
■ 進捗状況を更新した。
○ GoogleカレンダーとGoogleドキュメントを共有した
○ ソーシャルメディアでお互いサポートしていった
Slide 79
Slide 79 text
I can’t do this… alone! A Tale of Two Learning Partners
● プロポーザルの提出へ…
○ プロポーザルのアイデアを共有した
○ お互いのプロポーザルをレビューした
○ 他の人にもレビューしてもらった
● Agile Testing Daysと他の2つのカンファレンスで採用！
Slide 80
Slide 80 text
I can’t do this… alone! A Tale of Two Learning Partners
● プレゼンに向けて…
○ プレゼンの準備を共有した
○ 舞台上での恐怖の克服などのヒントを共有
■ その一部はAgile Testing Daysで学んだことに基づく
○ 自身の会社や地元の交流会などで練習した
Slide 81
Slide 81 text
I can’t do this… alone! A Tale of Two Learning Partners
● 認知度を高める
○ ソーシャルメディアや地元のミートアップに参加
○ 2人ともブログを始めた
■ お互い励ましあったりレビューをした
○ ポッドキャストへのゲスト依頼をされ始めた
Slide 82
Slide 82 text
I can’t do this… alone! A Tale of Two Learning Partners
● トピックを共有した
○ モブプロ
○ テスト戦略
○ ツール
○ メンタリング
● 仕事で成功し、昇進した
Slide 83
Slide 83 text
I can’t do this… alone! A Tale of Two Learning Partners
● 仕事上の課題を共有した
○ 相手のチームの課題に対する解決策を考えた
○ アイデアを試し、うまくチームで採用できた
● 学習パートナーシップを表明し、チームで励ましあった
Slide 84
Slide 84 text
I can’t do this… alone! A Tale of Two Learning Partners
● 暗黙知の表出
○ コンテキストが2つある中で共有することで、
暗黙の知識が必ずしも明らかではないことを学んだ。
■ 様々な手法を様々な方法でどのように適用できるか
■ 何が機能し、何が機能しないか
Slide 85
Slide 85 text
I can’t do this… alone! A Tale of Two Learning Partners
● 不快な提案を乗り越える
○ モブプロに関するビデオを提案されたが、
最初は嫌だった
○ パートナーをがっかりさせたくないので
アイデアがなんであれ、フォローしていった
Slide 86
Slide 86 text
I can’t do this… alone! A Tale of Two Learning Partners
● 新たな協定
○ 異なる目標になっていたが
学習のパートナーシップを継続した。
○ さらにグループに人が追加された
■ ７カ国10人のメンバーを持つグループになった
● グループの人々のために技術セッションを実施した
○ 22人で25個のセッションを行なった
Slide 87
Slide 87 text
I can’t do this… alone! A Tale of Two Learning Partners
● 新たな挑戦
○ 自身のアプリを作成する
■ 多くの人々とペアリングを行なった
■ ユニットテスト、リファクタリング、
ミューテーションテストを書いた
■ 負荷も大きいため、適度な休憩は必要となった
○ リーダーシップについて学ぶ
■ 委任について学ぶ
■ ソリューションの推進と人の管理との間で時間のバランスを取る
Slide 88
Slide 88 text
I can’t do this… alone! A Tale of Two Learning Partners
● 学習パートナーシップの利点
○ 客観的なアドバイスの取得
○ 経験の共有
○ ネットワークの拡大
○ 他の人への還元とインスピレーション
● 「毎日カンファレンスに参加している気分になった」
Slide 89
Slide 89 text
I can’t do this… alone! A Tale of Two Learning Partners
● 成果
○ 2019年のMIATPP（最もコミュニティに貢献した人）
に選ばれた
○ 大規模な多国籍企業でQAの責任者になった
Slide 90
Slide 90 text
I can’t do this… alone! A Tale of Two Learning Partners
● Agile Testing Daysの参加者、Twitter読者の皆さんへ
○ 距離について言い訳するのはやめましょう
○ 会議や会話からの関係を築きましょう
○ 独自のパートナーシップを構築しましょう
● 周りの皆さんは…
○ 学習パートナーですか？
○ それともカンファレンスに参加している他人ですか？
● 成長を助けるための必要なパートナーになりましょう！
Slide 91
Slide 91 text
https://twitter.com/lisacrispin/status/1192371518061326336
Slide 92
Slide 92 text
Building a Developer-Tester Relationship
最初のプロジェクトの状況
● Agileでは無かった
● テストはされていた
● Lisaが来て、バグをたくさん見つけた。
● プロジェクトで開発していた人たちはAgileな方法で
開発していないことに気付いた。
Slide 93
Slide 93 text
Building a Developer-Tester Relationship
選択肢
● 全てのバグを見つけて修正する
● 開発を停止し、新しいプロバイダーでやり直す
● 現在の開発を停止し、アジャイルの原則を使用して
小さな部分の修正を再開する
Slide 94
Slide 94 text
Building a Developer-Tester Relationship
選択肢
● 全てのバグを見つけて修正する
● 開発を停止し、新しいプロバイダーでやり直す
● 現在の開発を停止し、アジャイルの原則を使用して
小さな部分の修正を再開する
Slide 95
Slide 95 text
Building a Developer-Tester Relationship
我々が行なった変更
● Agileに連携して作業する
● 優先度を設定する
● タスク/ストーリーボードを作成して追跡する
Slide 96
Slide 96 text
Building a Developer-Tester Relationship
JanetはPOとして多くの間違いをした。
開発者にも頼ってストーリーを切り分けた。
それによって信頼を築いた。
問題を共有し、協力して変更を実施した。
Slide 97
Slide 97 text
Building a Developer-Tester Relationship
意見を共有することは助けになる
● 視点を共有する
● アイディアが解決策になる
● 試すことを恐れない
Slide 98
Slide 98 text
Building a Developer-Tester Relationship
意見を共有することは助けになる
● 視点を共有する
● アイディアが解決策になる
● 試すことを恐れない
効果的なコミュニケーションは
相互尊重を持ったコミュニケーションから始まる
by Zig Ziglar
Slide 99
Slide 99 text
Building a Developer-Tester Relationship
我々は悪い状況から来た。
誰もが非難する状態だった。
お互いに諦めないでください。
お互いに学んでいきましょう。
そのためにコミュニケーションをとりましょう。
Slide 100
Slide 100 text
Building a Developer-Tester Relationship
Q&A
「全てを知っている」という開発者に
もっと関心を持ってもらうには？
チョコレートで誘い、彼らが何しているのか見せてもらい、
数分間一緒にテストをする。
Slide 101
Slide 101 text
https://twitter.com/profesor_dragan/status/1192083040014622720
Slide 102
Slide 102 text
Deliberate Practice: What does it get us?
「人間は間違いを犯したり、間違ったりする生き物です。
これらの間違いを認めることは、あなたが学習する能力を
持ち、賢くなっていることを示しています。」
場にはsafetyは必要。
Slide 103
Slide 103 text
Deliberate Practice: What does it get us?
質問
最近、仕事で新しい何かを意図的に試したのはいつですか？
Slide 104
Slide 104 text
Deliberate Practice: What does it get us?
質問
最近、仕事で新しい何かを意図的に試したのはいつですか？
例：探索的テスト
● あなたはいつも同じテクニックを使っていますか？
● 同じ道を辿っていますか？
Slide 105
Slide 105 text
Deliberate Practice: What does it get us?
観察スキルの練習
● 周囲を歩く
● ワークショップで参加者を観察する
● チームMTGで
● カンファレンスで
観察することでフィードバックが得られる
Slide 106
Slide 106 text
Deliberate Practice: What does it get us?
協同するための10の要因
● 意図的に行なう
● 共有の目標を持つ
● プロセスを定める
● 共有の言語を構築する
● 関係を築く（他のメンバーの意見に興味を持つ）
Slide 107
Slide 107 text
Deliberate Practice: What does it get us?
協同するための10の要因
● 簡単に話す（権威者ぶって話さない）
● 学ぶ意図で聞く（学習を受け入れないと創造できない）
● 知らない場合は知らないことを表明する
● 誰でも貢献する機会があることを確認する
● 繰り返し行い調節する
Slide 108
Slide 108 text
Deliberate Practice: What does it get us?
協同するために、意図的な練習を適用する
1. 基本から始める
2. 練習
3. 実験（学び、適応する）
Slide 109
Slide 109 text
Deliberate Practice: What does it get us?
立ち往生しない
いつもそれをやっているからといっても。
練習することは価値です。
Slide 110
Slide 110 text
https://twitter.com/kev_barbe/status/1192030271614455810
Slide 111
Slide 111 text
開発とテスターのペアによる品質改善
● 以前はチームが分割されていた
○ コミュニケーションが無い
○ 品質が悪い
○ 時間もかかっていた
● プロジェクトが大きかった
● 私は新人だった
● テスターと開発者の壁を乗り越えることをゴールにした
Slide 112
Slide 112 text
開発とテスターのペアによる品質改善
施策1: カンバンボード
● レーンは4つ
○ TODO
○ WIP（最大5アイテムまで）
○ TEST
○ DONE
● 良い実装物であればすぐにTEST→DONEにできるが…
Slide 113
Slide 113 text
開発とテスターのペアによる品質改善
施策2: モブテスト
● 前まではチケットの説明などに時間がかかった
● Clean Codeを維持するのが簡単になった
● インプットと情報をシェアしあった
○ Whyの部分を伝えるのが簡単だった
Slide 114
Slide 114 text
開発とテスターのペアによる品質改善
施策3: チェックリストの改善
● 前までは「レビューをすること」ぐらいしか
書かれていなかった。
● 具体的に注意すべき点をチェックリスト化した
Slide 115
Slide 115 text
開発とテスターのペアによる品質改善
施策4: チームビルディング
● 毎週金曜日に1時間遊ぶ時間を設けた
○ マリオカート、スマブラ…
○ TVゲームをやらない人もいたので、
アナログゲームもやった
● みんなで朝食を食べるようになった
Slide 116
Slide 116 text
開発とテスターのペアによる品質改善
良いコミュニケーションとは
● メール上やSlack上のやり取りではない
● 現在、ピンポンゲームは終わった
● 開発完了したら、テスターの席に来て
テストを一緒にやるようになった
これらは5ヶ月間で変えることができた
Slide 117
Slide 117 text
No content
Slide 118
Slide 118 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
推理小説（動画）
https://www.youtube.com/watch?v=ubNF9QNEQLA
Slide 119
Slide 119 text
No content
Slide 120
Slide 120 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
1.検出する
感情とは何か？
● EmotionとFeelingはシグナルです。
彼らが伝えようとしているシグナルを見てください。
Slide 121
Slide 121 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
2.吸い上げる
● 頭の中で関連情報を取得する方法を見つける
● マインドマップなどを使う
Slide 122
Slide 122 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
3.経験とスキル
● ソフトスキル
● 経験
● 情報
新しい経験を積むには
● カンファレンスに行く
● スキルを開発する
Slide 123
Slide 123 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
4.推論する
● 推論とは、あなたが真実であると知っている他のことによっ
て、何かについて結論に達するプロセスのこと
Slide 124
Slide 124 text
LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE
YOUR TESTING SKILLS
テスターのための学び
● バグや本番での障害を修正するだけでなく、
引き続き本当の原因を見つけて修正する
● 実際のユーザーから事実を収集して、
品質を本当に向上させる
Slide 125
Slide 125 text
https://twitter.com/a_bangser/status/1191669256330588162
Slide 126
Slide 126 text
デプロイメントパイプラインの品質
発表資料
● https://noti.st/unremarkableqa/4IHAqK/turning-the-quality-of-your-deployment-pipeline-into-a-team-task#sTRvqo7
Slide 127
Slide 127 text
デプロイメントパイプラインの品質
● よくある問題
○ パイプラインが失敗しているが、誰も調査して修正する責
任を追っていない
○ テスターをセーフティネットとして扱う
● 傍観者効果
○ 周囲に多くの人がいると、介入して支援するのは
自分の責任ではないと感じること
Slide 128
Slide 128 text
デプロイメントパイプラインの品質
● 「誰もが品質に責任を追う」は理解されている
○ ただし、各人が追うべき個人的な責任が無くなりがち
● 発表者がFailedのフォローをし始めたら、他の人は
予防的になるのをやめ、通知を待つようになった。
Slide 129
Slide 129 text
デプロイメントパイプラインの品質
● デプロイパイプラインの品質責任を自分のタスクに。
● 修正またはリバートに15分の制限を設けた。
○ 「共有部分での障害発生を気にする
プレッシャーによって多くのミスを犯す」を防ぐ
○ 低ストレスの状況で必要なことに多くの時間をかける
● パイプラインの品質オーナーはロイヤリティが無い。
○ 改善点を強調することができる
○ 仕組みやドキュメントなどで人々に力を与えられる
Slide 130
Slide 130 text
デプロイメントパイプラインの品質
● デプロイパイプラインの品質責任を
チームに引き渡すためのロードマップも作成した。
Slide 131
Slide 131 text
No content
Slide 132
Slide 132 text
デプロイメントパイプラインの品質
私たちは持っていたもので最善を尽くしました。
Slide 133
Slide 133 text
https://twitter.com/the_qa_guy/status/1191399393582301184
Slide 134
Slide 134 text
Being-Lucky
発表資料
● https://seasidetesting.com/being-lucky/
Slide 135
Slide 135 text
Being-Lucky
● Luckyは幸せでもギャンブルでも偶然でもない。
関連しているが異なるものである。
● 努力や能力の結果としてでなく、
何か良い機会を引き起こす力
● 自動車事故によって、車に問題は無かったが、
身体をチェックした結果、腫瘍が見つかった。
● 私が癌に勝ったんじゃない。
メディカルスタッフや周りが勝ったのだ。
私はラッキーだ。
Slide 136
Slide 136 text
Being-Lucky
4つの原則
● チャンスである機会を最大化しよう
● ラッキーな予感に耳を澄ませよう
● 幸運を期待しよう
● 不運を良い方向に変化させよう
Slide 137
Slide 137 text
https://twitter.com/Mondazzle87/status/1191635595505872896
Slide 138
Slide 138 text
自己紹介してください
● 指名された人は自己紹介してください。
● 挨拶を言われたら挨拶を返しましょう。
Slide 139
Slide 139 text
More Than That
● 人をラベル付けするのは、
その人を分かりやすく表すことができる
● I’m JUST tester. のJUSTに気をつけよう。
「単なる」テスターでは無いはず。
● 我々はT型人間でもπ型人間でもなく、櫛型人間
○ それも壊れた櫛型人間
○ その長短をチームで動くことで補い合うことが大事
Slide 140
Slide 140 text
https://twitter.com/ghkero/status/1192484096099921921
Slide 141
Slide 141 text
Let’s Talk about Men’s Mental Health
発表資料
● https://www.slideshare.net/KevinHarris145/mens-mental-health
Slide 142
Slide 142 text
Let’s Talk about Men’s Mental Health
● イギリスでは仕事をしている人の50%以上が
メンタルヘルスに問題がある。
● ストレスの原因は仕事と人生の2つに分けられる
○ 長時間労働、自律性の欠如、管理の欠如、
期待が不明確、仕事の不安定さ、差別やハラスメント
○ 健康、子供、対人関係、家族、お金、引っ越しなど…
Slide 143
Slide 143 text
Let’s Talk about Men’s Mental Health
● イギリスでは仕事をしている人の50%以上が
メンタルヘルスに問題がある。
● ストレスの原因は仕事と人生の2つに分けられる
○ 長時間労働、自律性の欠如、管理の欠如、
期待が不明確、仕事の不安定さ、差別やハラスメント
○ 健康、子供、対人関係、家族、お金、引っ越しなど…
● 発表者は、3つのチームのテスターと
1つのチームのスクラムマスターを兼務した。
○ 病院に入院することになった。
Slide 144
Slide 144 text
Let’s Talk about Men’s Mental Health
ストレスになっていると気づくための10のサイン
● 「スイッチを切る」のが難しい
● 感情を管理するのが難しい
● 何をやってもやる気が出ない
● しばしば具合が悪くなる。
● 社交的でなくなる
Slide 145
Slide 145 text
Let’s Talk about Men’s Mental Health
ストレスになっていると気づくための10のサイン
● 睡眠パターンが変わる
● 仕事に行きたくなくなる
● 暴飲になる
● 集中するのが難しい
● 自分の面倒を見ない
Slide 146
Slide 146 text
Let’s Talk about Men’s Mental Health
あなたの助けになる9つの方法
● 誰かと話す
● 食べたり飲んだりタバコを吸う
● 睡眠習慣をつける
● 何か運動する
● 自分の時間を作る
● 新鮮な空気と日差しを浴びる
● 小さな変化をする
● ヨガやヒーリングを試す
● 誰かと話す
Slide 147
Slide 147 text
Let’s Talk about Men’s Mental Health
友人や家族から兆候がないか探してください
● サインを探す
● 聞く準備をする
自分自身についても探してください
● 自分自身のサインを理解する
● 自分自身のワークを見つける
● 話すことを怖がらない
Slide 148
Slide 148 text
https://twitter.com/jdiaz_berlin/status/1192717270558158853
Slide 149
Slide 149 text
The Missing Piece
● オリジナルをコピペするとおかしな結果になる
● 木を切るのに忙しくてノコギリを研ぐ時間が取れない
Slide 150
Slide 150 text
The Missing Piece
欠けているのは文化です。
● 文化とはどういう意味ですか？
● 文化はどのように形成されますか？
● 文化を変えるには何が必要ですか？
Slide 151
Slide 151 text
The Missing Piece
● 文化（Culture）はラテン語の「Cultus」に由来し、
「ケア」を意味します。
● 共通の目標に向かって働く一連の生きた関係を示す。
● 強い文化があると、
10年間で純利益を750%まで増加させます。
Slide 152
Slide 152 text
The Missing Piece
● 我々は潜在意識レベルでは
心理的および感情的な安全性を常に恐れています。
● 野生動物や他の危険からの攻撃されていた時代では、我々
の脳は生存のために動いています。
● 心理的および感情的な安全はチームが成長するために
非常に重要です。
● 質問を提起し、プロセスを改善することができます。
Slide 153
Slide 153 text
The Missing Piece
● 企業のイノベーションは、破壊する抗体を作成することによっ
て企業の免疫システムを刺激する。
by ドラッカー
Slide 154
Slide 154 text
The Missing Piece
● 最初のフォロワーなしでは動きはない。
● 勇気を持って始めてほしい。
● First Follower
○ https://www.youtube.com/watch?v=fW8amMCVAJQ
Slide 155
Slide 155 text
https://twitter.com/the_qa_guy/status/1191649118210445312
Slide 156
Slide 156 text
Test Strategy
ウォーターフォールの頃を顧みて、
テスト戦略とテスト計画についてどのように考えると
実際にどのように役立つか話していた。
Slide 157
Slide 157 text
Test Strategy
● テスター/テストアーキテクトとして何をしているのかを
マネージャーに説明する必要がある場合に役立つ
● コンテキストに応じて異なる形式で示す
○ 長いドキュメント
○ マインドマップ
● 重要なことは形式ではなく、それを理解すること
● 開発プロセスに関わる全ての人にメリットがある
Slide 158
Slide 158 text
Test Strategy
● テスト戦略は新しいドレスを手に入れるようなもの
○ 通常の店でサイズとモデルを手に入れることができる
○ テーラーモデルの服を手に入れると
手袋のようにフィットする
● テスト戦略はプロジェクト固有のものにする必要あり
○ 「万能」なテンプレートは無い
Slide 159
Slide 159 text
Test Strategy
● マインドマップとしてのテスト戦略
○ チームが順調に機能している場合は良い
○ 新しいメンバーが素早く把握することができる
● チーム全体でテスト戦略の構築に参加すべき
Slide 160
Slide 160 text
No content
Slide 161
Slide 161 text
Influencing Without Power
5つの原則
● 明示的に物事を作る
● レーダーの上か下のどちらを飛行するか選ぶ
● 負のスペースを描く
● 損失を得る
● 光を恐れない
Slide 162
Slide 162 text
Influencing Without Power
● 明示的に物事を作る
○ 「これをやろうと思う」と言うと
人々は”Good Luck”と言うが、
「これを○日目にやる」と言うと
「どうすれば手伝える？」と言ってくれる
Slide 163
Slide 163 text
Influencing Without Power
● 損失を得る
○ 議論が白熱している場合、
負けの状況になる可能性がある。
○ 「今は同意できないと思うので、また明日」
と言ってみましょう。
○ 今すぐ損失を取ることで、
あとで解決できる場合があります。
Slide 164
Slide 164 text
Influencing Without Power
● 光を恐れない
○ 誰もが価値を付加できる。
○ 私たちは皆異なっていて特別。
○ 私たちは自分のスキルと能力を信頼すべき。
■ これこそが私たちの力
Slide 165
Slide 165 text
No content
Slide 166
Slide 166 text
Ready Tester One? Go!
テスターのキャリアパス
● テスター → 開発者
● テスター → 製品マネージャ
● テスター → 管理職
テスターの役割を非技術領域と読んでいたりする。
● 「コードの学習」と「技術的である」は別物
● では、技術的なスキルとは？
Slide 167
Slide 167 text
Ready Tester One? Go!
コアキャリアスキル
● コミュニケーション
● リサーチ
● テクニカルライティング
● プロジェクト管理
● 探索的テスト
Slide 168
Slide 168 text
Ready Tester One? Go!
コアキャリアスキル
● コマンドラインの使用方法の理解
● ペアリング
● モビング
● 自動化
● ツール
Slide 169
Slide 169 text
Ready Tester One? Go!
専門分野別のスーパーテスタースキル
● Web
● モバイル
● Ops
● データ分析
● パイプライン
● 設計/ユーザビリティ
Slide 170
Slide 170 text
Ready Tester One? Go!
専門分野別のスーパーテスタースキル
● モニタリング/ロギング
● パフォーマンス
● セキュリティ
● アクセシビリティ
● IoT
● サービス（API、検索機能など…）
Slide 171
Slide 171 text
https://twitter.com/darktelecom/status/1192736910730506240
Slide 172
Slide 172 text
Bell Bottoms & Beyond
テスターのスキルギャップ
● バイナリの考え方や解析の手がかりを持っていません。
● 解釈済みまたは高レベルのスクリプトを使用します。
● スレッドセーフではないコードを記述します。
● 思考プロセスが同期的な仕組みになっています。
要するに、私たちは技術の変化に全く対応できていません。
Slide 173
Slide 173 text
No content
Slide 174
Slide 174 text
Agile Testing Daysに行って
感じたこと
Slide 175
Slide 175 text
Agile Testing Daysの良いところ
● 発表者と聴講者の関係に留まっていない
○ 参加型の発表も多い
● ホテルが会場なので、そのまま宿泊できるし
夜中までみんなでお喋りできる
○ 当日の雰囲気は11/26のイベント（座談会）で…
■ https://wingarc1st-spqi.connpass.com/event/155552/
● 研究発表や事例発表ではなく、
もっとカジュアルな発表が多い
Slide 176
Slide 176 text
そういうイベントって
日本に無いのかな…
Slide 177
Slide 177 text
No content
Slide 178
Slide 178 text
No content
Slide 179
Slide 179 text
https://twitter.com/_mirer/status/685832359166390272
Slide 180
Slide 180 text
おしまい