Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile Testing Days 参加報告 #D3QA #AgileTD / Report on Agile Testing Days

706ff501573a736401aa4de5adc88e05?s=47 nihonbuson
November 22, 2019

Agile Testing Days 参加報告 #D3QA #AgileTD / Report on Agile Testing Days

D3イベント『海外テスト系カンファレンス参加報告』での発表資料です。
https://d-cube.connpass.com/event/155527/

706ff501573a736401aa4de5adc88e05?s=128

nihonbuson

November 22, 2019
Tweet

Transcript

  1. Agile Testing Days
 参加報告
 風間 裕也


  2. Agile Testing Days とは


  3. Agile Testing Daysとは
 • ポツダムで11月上旬に毎年開催
 • 期間は6日間(チュートリアル2日+本会議4日)
 • ホテルで開催
 ◦

    当日の雰囲気は11/26のイベント(座談会)で話す
 ▪ https://wingarc1st-spqi.connpass.com/event/155552/
 • 朝・昼・晩の食事付き
 • 参加費は約30万円(早割あり)

  4. None
  5. Day 1


  6. Day 2


  7. Day
 3


  8. Day
 4


  9. Day
 5


  10. Day
 6


  11. 印象に残ったセッションの紹介


  12. https://twitter.com/LadyXochi/status/1191265231160385536

  13. Test Strategy Workshop
 概要
 • テスト戦略についてのワークショップ
 • 前半はテスト戦略の考え方についての講義
 • 後半は実在する題材を用いてテスト戦略を考えてみて、


    最終的にテストまで行なった

  14. Test Strategy Workshop
 • なぜテスト戦略を作るのか?を考えよう
 • プロダクトも違うのに、なぜ同じテンプレートなのか?
 ◦ 製品に関わるチームや人に対してテスト戦略を作る
 •

    I ALWAYS create test plan.
 • Scrumチームが壊れる原因の一つとして、
 Testerが成果物をチェックする役目に成り下がる

  15. Test Strategy Workshop
 • メトリクスは危険。
 ◦ メトリクスはたまにミスの方へ導いてしまう。
 ◦ メトリクスに対しては慎重になる必要がある。
 •

    Product Coverage Outlines(PCO)を作成しよう
 ◦ テストで関心のある領域を特定するため
 ◦ チームメンバーから賛同を得るため
 ◦ テストの優先順位づけを支援するため

  16. Test Strategy Workshop
 • Release Coverage Outlines(RCO)を作成しよう
 ◦ リリースで達成される全体的なテスト範囲を迅速かつ
 有意義な方法で示すために使用する


    ◦ 深いところまで行かないマインドマップで作る
 ◦ 主にインタフェースと機能部分に焦点を当てる
 ◦ 全ての(主要な)回帰領域と
 新しい機能/領域/バグ修正は「ズーム」して考える

  17. Test Strategy Workshop
 
 • このワークショップでは、付録として
 「Test Strategy Workshop Handbook」を頂いた。


    • その内容の一部を紹介。
 • 日本語訳したものは後日公開予定。
 (本人より承諾済み)

  18. Test Strategy Handbook 目次
 • テスト戦略で達成すべき結果
 • テスト戦略とは何か
 • コンテキストを理解するために必要なBUTT


    • ヒューリスティックテスト戦略モデル
 ◦ MIDTESTD
 ◦ SFDIPOT
 ◦ CRISP DUCCS
 ◦ FDSFSCURA

  19. コンテキストを理解するために必要なBUTT
 テスト戦略を考えるにあたり、
 まずは下記の側面(BUTT)を理解する必要がある。
 • Business driver
 • Usage
 • Technology


    • Team

  20. ビジネスドライバー(Business Driver)
 • クライアントは誰ですか? • 製品はクライアントにとってどのような問題を解決しますか? • 製品が解決されるとできる他の問題(間違った使い方)は何ですか? • 製品はお客様にどのような価値を提供しますか?

    • 内部および外部の顧客の考えにある製品のイメージは何ですか? • 契約、罰則、またはその他の法的義務はありますか? • 競合他社は(現在もしくは将来)ありますか? • これはどのくらいのビジネスチャンスですか? • なぜこの製品が構築されているのですか?なぜ今なのですか? • 市場の力とプロジェクトの推進力について知っていますか?

  21. 使用方法(Usage)
 • さまざまなタイプのユーザー(知っている人、ペルソナ)、 さまざまなニーズ、さまざまな感情、さまざまな状況は何ですか? • 彼らはどのように製品を使用しますか?(シナリオ) • 彼らはどのように製品を誤用しますか? • 「良い」ユーザーは間違って何をするのでしょうか?

    • 悪意のあるユーザーは何をしようとしますか? • 新しいテスト方法につながるような変更はありますか? • 現在の状況で、他にテスト対象に影響するものは何ですか? • エンドユーザー、プリセールス、販売、マーケティング、コンサルタント、サポート担 当者にインタビューし、顧客のニーズについてさらに理解しよう • 彼らが好きなものと嫌いなもの、 ソフトウェアの隣で何をするのかを見つけましょう。

  22. 技術(Technology)
 アーキテクチャ • データの依存関係(ソース) • データ出力 • 製品を流れるデータ • 他の製品/機能/システムへの依存関係は何ですか?

    • 製品に依存している他の製品/機能/システムは何ですか? プラットフォーム • 製品の言語は何ですか? • どのサーバーとサービスが使用されていますか? ◦ ロードバランサー、スプーラー、ネットワークデバイスなど
  23. チーム(Team) その1
 あなたのチームについて • あなたのチームには誰がいますか? ◦ 彼らの役割は何ですか? ◦ 彼らはあなたにどんなドキュメントを期待していますか? •

    どのチームとやり取りする必要がありますか? ◦ 彼らの役割と責任は何ですか? ◦ 彼らはあなたが誰であり、 あなたが彼らに何を期待しているかを知っていますか? • プロジェクトとその人々には、どの長所と短所がありますか? • これらの項目に対して一連のテストアイデアをマッピングできるようにするためのプ ロジェクトの技術的負債は何ですか? • 開発者にコードのどの部分を改善したいのか尋ねてください。 • 開発者はどの機能で問題を抱えていますか?

  24. チーム(Team) その2
 他のチームについて • 知っておく必要のある習慣や伝統はありますか? • 文化の違いと、それがあなたとあなたの仕事にどのような影響を与えるかを知って いますか? • あなたの利害関係者は誰ですか?

    • 利害関係者が本当に心配していることは何ですか? • 他の利害関係者は誰ですか? • 他の人によってテストされているものは何ですか?
  25. Test Strategy Handbook 目次
 • テスト戦略で達成すべき結果
 • テスト戦略とは何か
 • コンテキストを理解するために必要なBUTT


    • ヒューリスティックテスト戦略モデル
 ◦ MIDTESTD
 ◦ SFDIPOT
 ◦ CRISP DUCCS
 ◦ FDSFSCURA

  26. https://twitter.com/jrosaproenca/status/1192010123679535104

  27. 10分間で探索的テストを説明する方法
 発表資料
 • https://www.slideshare.net/KristineCorbus/how-to-explain-exploratory-testing-in-10min


  28. 10分間で探索的テストを説明する方法
 探索的テストのポイント
 1. 探索的テストはリュックサック1つで旅行するようなもの


  29. 10分間で探索的テストを説明する方法
 Let’s play the game!
 • 私に向けて最大20個の質問をしてください
 • 3分以内に、私が思い浮かべているものを当ててください
 •

    Yes/Noのみで答えます
 • みんなが知っているものです
 • それは大きいです

  30. 10分間で探索的テストを説明する方法
 ふりかえり
 • どうでしたか?
 • 他にどんなことができたでしょうか?


  31. 10分間で探索的テストを説明する方法
 ふりかえり
 • どうでしたか?
 • 他にどんなことができたでしょうか?
 ◦ 以前にこれを行なった結果
 ▪ メモを作ってない


    ▪ 他人の話を聞かない
 ▪ 戦略を持っていない

  32. 10分間で探索的テストを説明する方法
 探索的テストのポイント
 1. 探索的テストはリュックサック1つで旅行するようなもの
 2. 探索的テストは野生の勘ではない


  33. 10分間で探索的テストを説明する方法
 aSPAを意識しよう
 • aim(目的)
 • Sense(感覚)
 • Protocol(やりとり)
 • Analyse(分析)


  34. None
  35. 10分間で探索的テストを説明する方法
 • 探索的テストのポイント
 1. 探索的テストはリュックサック1つで旅行するようなもの
 2. 探索的テストは野生の勘ではない
 3. 探索的テストは4つのイベント(aSPA)を持つ
 タイムボックスで区切られた継続的な活動


    
 これらの考え方を持って探索的テストをやろう!

  36. https://twitter.com/mirjanakolarov/status/1192385550055022592

  37. What do you mean... a Quality Owner?!
 発表内容
 • https://www.youtube.com/watch?v=jlygHJIFjTA


  38. What do you mean... a Quality Owner?!
 2007年時点
 1. 新しい仕事が来る


    2. 開発者が開発をする
 3. QAが手動テストをする
 4. QAが自動テストをする
 5. バグが発生したら開発者が修正する
 6. ドキュメントを書く

  39. What do you mean... a Quality Owner?!
 2007年時点
 1. 新しい仕事が来る


    2. 開発者が開発をする
 3. QAが手動テストをする
 4. QAが自動テストをする
 5. バグが発生したら開発者が修正する
 6. ドキュメントを書く
 会場から「Oh...」というため息が漏れる

  40. What do you mean... a Quality Owner?!
 問題点
 • 開発の外でテストしなかった


    • 自動化におけるテスタビリティが足りていなかった
 • 重い、遅い、Flakyが発生していた
 • 品質への意識が足りていなかった
 1つ1つは小さな問題だが、集まるとかなり大きな問題だった

  41. What do you mean... a Quality Owner?!
 品質のスペシャリストを採用
 • DevOpsの考え方を用いてtrunkベースの開発に移行


    • CI/CDパイプラインを作った
 • フィードバックを短縮した
 何かが足りない…
 もっと全体的なアプローチを望んでいた

  42. What do you mean... a Quality Owner?!
 QA Ownerの採用(2017年)
 QA

    Ownerとは…
 • 開発者
 • 品質エキスパート
 • コーチ
 • エバンジェリスト

  43. What do you mean... a Quality Owner?!
 QA Ownerのタスク
 •

    リスク分析
 • リスク管理
 • リスク軽減
 • テスト戦略
 • テスト管理
 • テスタビリティ

  44. What do you mean... a Quality Owner?!
 QA Ownerのタスク
 •

    デリバリを増加させる
 • 水平展開
 • ドッグフーディング
 • DevOpsやCI/CDでチームを教育する

  45. What do you mean... a Quality Owner?!
 3年間での変化
 • Feature

    TeamからComponent Teamに変化させた。

  46. None
  47. What do you mean... a Quality Owner?!
 3年間での変化
 • Feature

    TeamからComponent Teamに変化させた。
 ◦ Feature Teamでは、
 特定のチームが特定のテストを所有していなかった。
 ◦ チーム全体がテストを所有していたが、
 だれもテストに責任を感じていなかった状況を打破

  48. What do you mean... a Quality Owner?!
 開発チームがテストをすることが重要
 開発者はテストしない多くの理由を考えることができる
 •

    費用対効果が低いから
 • 後でテストするから

  49. None
  50. What do you mean... a Quality Owner?!
 開発チームがテストをすることが重要
 開発者はテストしない多くの理由を考えることができる
 •

    費用対効果が低いから
 • 後でテストするから
 → 倒れるかもしれない家を作っているようなもの
 • 我々は単なる開発者ではなくエンジニア
 • 品質の責任を受け入れる必要がある

  51. What do you mean... a Quality Owner?!
 開発チームがテストをすることが重要
 意識づけをするための行動
 •

    小さく始める。
 ◦ 早期にやりたがる1,2名を選んで作業をする
 • 経営陣に説得する
 
 テストがない状態でQA Ownerがいなくなることはない。

  52. What do you mean... a Quality Owner?!
 品質成熟度レベル1
 • 探索的テスト


    • バグ分析

  53. What do you mean... a Quality Owner?!
 品質成熟度レベル2
 • Frameworkの利用


    • ツールの利用
 • 基準やガイドラインの設定

  54. What do you mean... a Quality Owner?!
 品質成熟度レベル3
 • フィードバックループの構築


    • CI/CD
 • より早くリリース
 • モノリスからの脱却
 • observability(可観測性)

  55. What do you mean... a Quality Owner?!
 最初は懐疑的だった人も、下記の価値をすぐに認識した。
 • チームのリスクを軽減した


    • 優れた品質の実践を学習できるようになった

  56. None
  57. TESTERS, ARE YOU REALLY ENGAGED?
 発表者はセキュリティエンジニア
 セキュリティに対する認識とテストに対する認識は似ている


  58. https://www.youtube.com/watch?v=J2uhWTFvug8 


  59. TESTERS, ARE YOU REALLY ENGAGED?
 テストは次のように捉えられたりする
 • コストセンター
 • 結果ではなくツールに焦点が当たる


    • 価値駆動ではなくチェックボックスを見るため
 • コラボレーションやトレーニングが欠如している

  60. TESTERS, ARE YOU REALLY ENGAGED?
 テストを儀式にしないために、投資する必要がある。
 • ドメイン知識
 ◦ あなたの会社が何をするのか、どのように稼ぐのか…


    • コードを学ぶ
 ◦ 本格的はちょっと…でも、コードを読んでレビューを
 • シェアする
 ◦ 学習と経験を共有し、他の人を助ける
 ◦ 職場での講義、イベントでの講演、ブログの公開など

  61. TESTERS, ARE YOU REALLY ENGAGED?
 テスターのスキル
 • 質問する力
 • 観察力


    • 素早く学ぶ力
 • バグの調査能力
 • 批判的な思考力
 • 水平思考力
 • コミュニケーション能力

  62. TESTERS, ARE YOU REALLY ENGAGED?
 Be that team, Be that

    guy
 • 実践的なリーダー/マネージャーになる
 ◦ 行う方法を示す。仕事や経営の立ち向かい方を教える
 • 細かな管理はせず、助ける
 ◦ 他の人が苦労しているのを見たら踏み込む。
 • ペアワークをする
 • チームをカンファレンスに参加させる
 ◦ 学ぶ機会を与える。良いチームの構築に投資する。

  63. https://twitter.com/Maaikees/status/1192776756014526464

  64. Uncomfortable Questions about Testing Addressed
 発表資料
 • https://t.co/pEGEj663b1?amp=1


  65. Uncomfortable Questions about Testing Addressed
 • 発表のテーマ…なぜ我々はここにいるのか?
 • 人々は不快な事実よりも心地よい嘘に流れていく
 ◦

    手を洗うことが命を救うことが証明されたとしても
 すぐにそれを定期的に行う必要性を感じなかった
 ◦ 認知的不協和が発生している
 • テストにおける認知的不協和
 ◦ 「AIを使用したコードレスな自動化ツール」といった
 単純な策で複雑な問題を解決できると信じたい

  66. Uncomfortable Questions about Testing Addressed
 • 認知的不協和の定義(1956年)
 ◦ 態度と行動が対立しているという認識から生じる、
 2つの思考または認識が一致しない場合に


    発生する心理的緊張の不快な状態。

  67. Uncomfortable Questions about Testing Addressed
 • 確認バイアス
 ◦ 既存の信念を支持する情報のみが表示されている状態
 •

    認知的不協和
 ◦ 我々はそれが本当だと真面目に信じている状態。
 ◦ 嘘と真実の両方になり得る。
 • 経験によってあなたの信念は変わっていく。

  68. None
  69. Uncomfortable Questions about Testing Addressed
 • カンニングするかどうかの例
 ◦ 誠実さを保つ
 ▪

    不正行為は不道徳である。
 ▪ 不正行為者は学校から追放されるべき。
 ◦ テストに合格する必要がある
 ▪ 私はリスクをとった。
 ▪ みんなカンニングしている。
 • ピラミッドの底=内面化された信念

  70. Uncomfortable Questions about Testing Addressed
 • 「テスターの投資なしで
 ソフトウェア開発を行うことはできるか?」
 ◦ 「あなたはクレイジーなのか?」


    テスターの貢献が必要ない訳がない。
 ◦ テスターなしで開発している多くの製品は、
 プロのテスターなしでも正常に機能している。

  71. None
  72. Uncomfortable Questions about Testing Addressed
 • テストが必要かどうかの例
 ◦ 常にバグがある
 ▪

    問題を素早く修正すれば良い
 ▪ テストはボトルネックになる
 ◦ バグを見つけます
 ▪ 適切なテストプロセスは品質を向上させる。
 ▪ テストは必要です

  73. Uncomfortable Questions about Testing Addressed
 • 発表のテーマ…我々はなぜここにいるのか?
 ◦ テスターの集まりは、
 心を安らかにするための場所に過ぎないのでは?


    • 重要なのは、様々な意見や視点を皆が持っていること
 ◦ 我々が学ぶ方法にも繋がる
 • 心を開き、様々なカンファレンスに行き、
 様々な本を読みましょう。

  74. Uncomfortable Questions about Testing Addressed
 • 不快に感じるのは普通のことです。
 ◦ 簡単な方法で自分に嘘をつきたいですか?
 ◦

    その感情を引き起こしているものを
 掘り下げて調べたいですか?
 • 認知バイアスまたは確認バイアスが発生しているか
 考えてみましょう。
 • 我々は人間なので、間違っていても大丈夫です。
 • テストを再考し、価値を再考しましょう。

  75. https://twitter.com/lisacrispin/status/1192834355674132480

  76. 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

  77. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 2016年のAgile Testing Daysで2人は出会った
 ◦ ドイツ(ミュンヘン)と南アフリカ
 ◦ 学習パートナーとして一緒にやっていくことを決めた
 ▪ 公に発表することを提案した
 ▪ 勇気を出して次のステップへ進んだ

  78. I can’t do this… alone! A Tale of Two Learning

    Partners
 • ペアリングを行なっていった
 ◦ 2週間ごとに1時間のビデオ会議を行った
 ▪ 進捗状況を更新した。
 ◦ GoogleカレンダーとGoogleドキュメントを共有した
 ◦ ソーシャルメディアでお互いサポートしていった

  79. I can’t do this… alone! A Tale of Two Learning

    Partners
 • プロポーザルの提出へ…
 ◦ プロポーザルのアイデアを共有した
 ◦ お互いのプロポーザルをレビューした
 ◦ 他の人にもレビューしてもらった
 • Agile Testing Daysと他の2つのカンファレンスで採用!

  80. I can’t do this… alone! A Tale of Two Learning

    Partners
 • プレゼンに向けて…
 ◦ プレゼンの準備を共有した
 ◦ 舞台上での恐怖の克服などのヒントを共有
 ▪ その一部はAgile Testing Daysで学んだことに基づく
 ◦ 自身の会社や地元の交流会などで練習した

  81. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 認知度を高める
 ◦ ソーシャルメディアや地元のミートアップに参加
 ◦ 2人ともブログを始めた
 ▪ お互い励ましあったりレビューをした
 ◦ ポッドキャストへのゲスト依頼をされ始めた

  82. I can’t do this… alone! A Tale of Two Learning

    Partners
 • トピックを共有した
 ◦ モブプロ
 ◦ テスト戦略
 ◦ ツール
 ◦ メンタリング
 • 仕事で成功し、昇進した

  83. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 仕事上の課題を共有した
 ◦ 相手のチームの課題に対する解決策を考えた
 ◦ アイデアを試し、うまくチームで採用できた
 • 学習パートナーシップを表明し、チームで励ましあった

  84. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 暗黙知の表出
 ◦ コンテキストが2つある中で共有することで、
 暗黙の知識が必ずしも明らかではないことを学んだ。
 ▪ 様々な手法を様々な方法でどのように適用できるか
 ▪ 何が機能し、何が機能しないか

  85. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 不快な提案を乗り越える
 ◦ モブプロに関するビデオを提案されたが、
 最初は嫌だった
 ◦ パートナーをがっかりさせたくないので
 アイデアがなんであれ、フォローしていった

  86. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 新たな協定
 ◦ 異なる目標になっていたが
 学習のパートナーシップを継続した。
 ◦ さらにグループに人が追加された
 ▪ 7カ国10人のメンバーを持つグループになった
 • グループの人々のために技術セッションを実施した
 ◦ 22人で25個のセッションを行なった

  87. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 新たな挑戦
 ◦ 自身のアプリを作成する
 ▪ 多くの人々とペアリングを行なった
 ▪ ユニットテスト、リファクタリング、
 ミューテーションテストを書いた
 ▪ 負荷も大きいため、適度な休憩は必要となった
 ◦ リーダーシップについて学ぶ
 ▪ 委任について学ぶ
 ▪ ソリューションの推進と人の管理との間で時間のバランスを取る

  88. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 学習パートナーシップの利点
 ◦ 客観的なアドバイスの取得
 ◦ 経験の共有
 ◦ ネットワークの拡大
 ◦ 他の人への還元とインスピレーション
 • 「毎日カンファレンスに参加している気分になった」

  89. I can’t do this… alone! A Tale of Two Learning

    Partners
 • 成果
 ◦ 2019年のMIATPP(最もコミュニティに貢献した人)
 に選ばれた
 ◦ 大規模な多国籍企業でQAの責任者になった

  90. I can’t do this… alone! A Tale of Two Learning

    Partners
 • Agile Testing Daysの参加者、Twitter読者の皆さんへ
 ◦ 距離について言い訳するのはやめましょう
 ◦ 会議や会話からの関係を築きましょう
 ◦ 独自のパートナーシップを構築しましょう
 • 周りの皆さんは…
 ◦ 学習パートナーですか?
 ◦ それともカンファレンスに参加している他人ですか?
 • 成長を助けるための必要なパートナーになりましょう!

  91. https://twitter.com/lisacrispin/status/1192371518061326336

  92. Building a Developer-Tester Relationship
 最初のプロジェクトの状況
 • Agileでは無かった
 • テストはされていた
 •

    Lisaが来て、バグをたくさん見つけた。
 • プロジェクトで開発していた人たちはAgileな方法で
 開発していないことに気付いた。

  93. Building a Developer-Tester Relationship
 選択肢
 • 全てのバグを見つけて修正する
 • 開発を停止し、新しいプロバイダーでやり直す
 •

    現在の開発を停止し、アジャイルの原則を使用して
 小さな部分の修正を再開する

  94. Building a Developer-Tester Relationship
 選択肢
 • 全てのバグを見つけて修正する
 • 開発を停止し、新しいプロバイダーでやり直す
 •

    現在の開発を停止し、アジャイルの原則を使用して
 小さな部分の修正を再開する

  95. Building a Developer-Tester Relationship
 我々が行なった変更
 • Agileに連携して作業する
 • 優先度を設定する
 •

    タスク/ストーリーボードを作成して追跡する

  96. Building a Developer-Tester Relationship
 JanetはPOとして多くの間違いをした。
 開発者にも頼ってストーリーを切り分けた。
 それによって信頼を築いた。
 問題を共有し、協力して変更を実施した。


  97. Building a Developer-Tester Relationship
 意見を共有することは助けになる
 • 視点を共有する
 • アイディアが解決策になる
 •

    試すことを恐れない

  98. Building a Developer-Tester Relationship
 意見を共有することは助けになる
 • 視点を共有する
 • アイディアが解決策になる
 •

    試すことを恐れない
 効果的なコミュニケーションは
 相互尊重を持ったコミュニケーションから始まる
 by Zig Ziglar

  99. Building a Developer-Tester Relationship
 我々は悪い状況から来た。
 誰もが非難する状態だった。
 お互いに諦めないでください。
 お互いに学んでいきましょう。
 そのためにコミュニケーションをとりましょう。


  100. Building a Developer-Tester Relationship
 Q&A
 「全てを知っている」という開発者に
 もっと関心を持ってもらうには?
 チョコレートで誘い、彼らが何しているのか見せてもらい、
 数分間一緒にテストをする。


  101. https://twitter.com/profesor_dragan/status/1192083040014622720

  102. Deliberate Practice: What does it get us?
 「人間は間違いを犯したり、間違ったりする生き物です。
 これらの間違いを認めることは、あなたが学習する能力を
 持ち、賢くなっていることを示しています。」


    
 場にはsafetyは必要。

  103. Deliberate Practice: What does it get us?
 質問
 最近、仕事で新しい何かを意図的に試したのはいつですか?


  104. Deliberate Practice: What does it get us?
 質問
 最近、仕事で新しい何かを意図的に試したのはいつですか?
 


    例:探索的テスト
 • あなたはいつも同じテクニックを使っていますか?
 • 同じ道を辿っていますか?

  105. Deliberate Practice: What does it get us?
 観察スキルの練習
 • 周囲を歩く


    • ワークショップで参加者を観察する
 • チームMTGで
 • カンファレンスで
 
 観察することでフィードバックが得られる

  106. Deliberate Practice: What does it get us?
 協同するための10の要因
 • 意図的に行なう


    • 共有の目標を持つ
 • プロセスを定める
 • 共有の言語を構築する
 • 関係を築く(他のメンバーの意見に興味を持つ)

  107. Deliberate Practice: What does it get us?
 協同するための10の要因
 • 簡単に話す(権威者ぶって話さない)


    • 学ぶ意図で聞く(学習を受け入れないと創造できない)
 • 知らない場合は知らないことを表明する
 • 誰でも貢献する機会があることを確認する
 • 繰り返し行い調節する

  108. Deliberate Practice: What does it get us?
 協同するために、意図的な練習を適用する
 1. 基本から始める


    2. 練習
 3. 実験(学び、適応する)

  109. Deliberate Practice: What does it get us?
 立ち往生しない
 いつもそれをやっているからといっても。
 


    練習することは価値です。

  110. https://twitter.com/kev_barbe/status/1192030271614455810

  111. 開発とテスターのペアによる品質改善
 • 以前はチームが分割されていた
 ◦ コミュニケーションが無い
 ◦ 品質が悪い
 ◦ 時間もかかっていた
 •

    プロジェクトが大きかった
 • 私は新人だった
 • テスターと開発者の壁を乗り越えることをゴールにした

  112. 開発とテスターのペアによる品質改善
 施策1: カンバンボード
 • レーンは4つ
 ◦ TODO
 ◦ WIP(最大5アイテムまで)
 ◦

    TEST
 ◦ DONE
 • 良い実装物であればすぐにTEST→DONEにできるが…

  113. 開発とテスターのペアによる品質改善
 施策2: モブテスト
 • 前まではチケットの説明などに時間がかかった
 • Clean Codeを維持するのが簡単になった
 • インプットと情報をシェアしあった


    ◦ Whyの部分を伝えるのが簡単だった

  114. 開発とテスターのペアによる品質改善
 施策3: チェックリストの改善
 • 前までは「レビューをすること」ぐらいしか
 書かれていなかった。
 • 具体的に注意すべき点をチェックリスト化した


  115. 開発とテスターのペアによる品質改善
 施策4: チームビルディング
 • 毎週金曜日に1時間遊ぶ時間を設けた
 ◦ マリオカート、スマブラ…
 ◦ TVゲームをやらない人もいたので、
 アナログゲームもやった


    • みんなで朝食を食べるようになった

  116. 開発とテスターのペアによる品質改善
 良いコミュニケーションとは
 • メール上やSlack上のやり取りではない
 • 現在、ピンポンゲームは終わった
 • 開発完了したら、テスターの席に来て
 テストを一緒にやるようになった
 これらは5ヶ月間で変えることができた


  117. None
  118. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 推理小説(動画)
 https://www.youtube.com/watch?v=ubNF9QNEQLA 

  119. None
  120. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 1.検出する
 感情とは何か?
 • EmotionとFeelingはシグナルです。
 彼らが伝えようとしているシグナルを見てください。

  121. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 2.吸い上げる
 • 頭の中で関連情報を取得する方法を見つける
 • マインドマップなどを使う

  122. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 3.経験とスキル
 • ソフトスキル
 • 経験
 • 情報
 新しい経験を積むには
 • カンファレンスに行く
 • スキルを開発する

  123. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 4.推論する
 • 推論とは、あなたが真実であると知っている他のことによっ て、何かについて結論に達するプロセスのこと

  124. LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

    SKILLS
 テスターのための学び
 • バグや本番での障害を修正するだけでなく、
 引き続き本当の原因を見つけて修正する
 • 実際のユーザーから事実を収集して、
 品質を本当に向上させる

  125. https://twitter.com/a_bangser/status/1191669256330588162

  126. デプロイメントパイプラインの品質
 発表資料
 • https://noti.st/unremarkableqa/4IHAqK/turning-the-quality-of-your-deployment-pipeline-into-a-team-task#sTRvqo7


  127. デプロイメントパイプラインの品質
 • よくある問題
 ◦ パイプラインが失敗しているが、誰も調査して修正する責 任を追っていない
 ◦ テスターをセーフティネットとして扱う
 • 傍観者効果


    ◦ 周囲に多くの人がいると、介入して支援するのは
 自分の責任ではないと感じること

  128. デプロイメントパイプラインの品質
 • 「誰もが品質に責任を追う」は理解されている
 ◦ ただし、各人が追うべき個人的な責任が無くなりがち
 • 発表者がFailedのフォローをし始めたら、他の人は
 予防的になるのをやめ、通知を待つようになった。


  129. デプロイメントパイプラインの品質
 • デプロイパイプラインの品質責任を自分のタスクに。
 • 修正またはリバートに15分の制限を設けた。
 ◦ 「共有部分での障害発生を気にする
 プレッシャーによって多くのミスを犯す」を防ぐ
 ◦ 低ストレスの状況で必要なことに多くの時間をかける


    • パイプラインの品質オーナーはロイヤリティが無い。
 ◦ 改善点を強調することができる
 ◦ 仕組みやドキュメントなどで人々に力を与えられる

  130. デプロイメントパイプラインの品質
 • デプロイパイプラインの品質責任を
 チームに引き渡すためのロードマップも作成した。


  131. None
  132. デプロイメントパイプラインの品質
 私たちは持っていたもので最善を尽くしました。


  133. https://twitter.com/the_qa_guy/status/1191399393582301184

  134. Being-Lucky
 発表資料
 • https://seasidetesting.com/being-lucky/


  135. Being-Lucky
 • Luckyは幸せでもギャンブルでも偶然でもない。
 関連しているが異なるものである。
 • 努力や能力の結果としてでなく、
 何か良い機会を引き起こす力
 • 自動車事故によって、車に問題は無かったが、
 身体をチェックした結果、腫瘍が見つかった。


    • 私が癌に勝ったんじゃない。
 メディカルスタッフや周りが勝ったのだ。
 私はラッキーだ。

  136. Being-Lucky
 4つの原則
 • チャンスである機会を最大化しよう
 • ラッキーな予感に耳を澄ませよう
 • 幸運を期待しよう
 • 不運を良い方向に変化させよう


  137. https://twitter.com/Mondazzle87/status/1191635595505872896

  138. 自己紹介してください
 • 指名された人は自己紹介してください。
 • 挨拶を言われたら挨拶を返しましょう。


  139. More Than That
 • 人をラベル付けするのは、
 その人を分かりやすく表すことができる
 • I’m JUST tester.

    のJUSTに気をつけよう。
 「単なる」テスターでは無いはず。
 • 我々はT型人間でもπ型人間でもなく、櫛型人間
 ◦ それも壊れた櫛型人間
 ◦ その長短をチームで動くことで補い合うことが大事

  140. https://twitter.com/ghkero/status/1192484096099921921

  141. Let’s Talk about Men’s Mental Health
 発表資料
 • https://www.slideshare.net/KevinHarris145/mens-mental-health


  142. Let’s Talk about Men’s Mental Health
 • イギリスでは仕事をしている人の50%以上が
 メンタルヘルスに問題がある。
 •

    ストレスの原因は仕事と人生の2つに分けられる
 ◦ 長時間労働、自律性の欠如、管理の欠如、
 期待が不明確、仕事の不安定さ、差別やハラスメント
 ◦ 健康、子供、対人関係、家族、お金、引っ越しなど…

  143. Let’s Talk about Men’s Mental Health
 • イギリスでは仕事をしている人の50%以上が
 メンタルヘルスに問題がある。
 •

    ストレスの原因は仕事と人生の2つに分けられる
 ◦ 長時間労働、自律性の欠如、管理の欠如、
 期待が不明確、仕事の不安定さ、差別やハラスメント
 ◦ 健康、子供、対人関係、家族、お金、引っ越しなど…
 • 発表者は、3つのチームのテスターと
 1つのチームのスクラムマスターを兼務した。
 ◦ 病院に入院することになった。

  144. Let’s Talk about Men’s Mental Health
 ストレスになっていると気づくための10のサイン
 • 「スイッチを切る」のが難しい
 •

    感情を管理するのが難しい
 • 何をやってもやる気が出ない
 • しばしば具合が悪くなる。
 • 社交的でなくなる

  145. Let’s Talk about Men’s Mental Health
 ストレスになっていると気づくための10のサイン
 • 睡眠パターンが変わる
 •

    仕事に行きたくなくなる
 • 暴飲になる
 • 集中するのが難しい
 • 自分の面倒を見ない

  146. Let’s Talk about Men’s Mental Health
 あなたの助けになる9つの方法
 • 誰かと話す
 •

    食べたり飲んだりタバコを吸う
 • 睡眠習慣をつける
 • 何か運動する
 • 自分の時間を作る
 • 新鮮な空気と日差しを浴びる
 • 小さな変化をする
 • ヨガやヒーリングを試す
 • 誰かと話す

  147. Let’s Talk about Men’s Mental Health
 友人や家族から兆候がないか探してください
 • サインを探す
 •

    聞く準備をする
 自分自身についても探してください
 • 自分自身のサインを理解する
 • 自分自身のワークを見つける
 • 話すことを怖がらない

  148. https://twitter.com/jdiaz_berlin/status/1192717270558158853

  149. The Missing Piece
 • オリジナルをコピペするとおかしな結果になる
 • 木を切るのに忙しくてノコギリを研ぐ時間が取れない


  150. The Missing Piece
 
 欠けているのは文化です。
 • 文化とはどういう意味ですか?
 • 文化はどのように形成されますか?
 •

    文化を変えるには何が必要ですか?

  151. The Missing Piece
 • 文化(Culture)はラテン語の「Cultus」に由来し、
 「ケア」を意味します。
 • 共通の目標に向かって働く一連の生きた関係を示す。
 • 強い文化があると、


    10年間で純利益を750%まで増加させます。

  152. The Missing Piece
 • 我々は潜在意識レベルでは
 心理的および感情的な安全性を常に恐れています。
 • 野生動物や他の危険からの攻撃されていた時代では、我々 の脳は生存のために動いています。
 •

    心理的および感情的な安全はチームが成長するために
 非常に重要です。
 • 質問を提起し、プロセスを改善することができます。

  153. The Missing Piece
 • 企業のイノベーションは、破壊する抗体を作成することによっ て企業の免疫システムを刺激する。
 by ドラッカー


  154. The Missing Piece
 • 最初のフォロワーなしでは動きはない。
 • 勇気を持って始めてほしい。
 • First Follower


    ◦ https://www.youtube.com/watch?v=fW8amMCVAJQ

  155. https://twitter.com/the_qa_guy/status/1191649118210445312

  156. Test Strategy
 ウォーターフォールの頃を顧みて、
 テスト戦略とテスト計画についてどのように考えると
 実際にどのように役立つか話していた。


  157. Test Strategy
 • テスター/テストアーキテクトとして何をしているのかを
 マネージャーに説明する必要がある場合に役立つ
 • コンテキストに応じて異なる形式で示す
 ◦ 長いドキュメント
 ◦

    マインドマップ
 • 重要なことは形式ではなく、それを理解すること
 • 開発プロセスに関わる全ての人にメリットがある

  158. Test Strategy
 • テスト戦略は新しいドレスを手に入れるようなもの
 ◦ 通常の店でサイズとモデルを手に入れることができる
 ◦ テーラーモデルの服を手に入れると
 手袋のようにフィットする
 •

    テスト戦略はプロジェクト固有のものにする必要あり
 ◦ 「万能」なテンプレートは無い

  159. Test Strategy
 • マインドマップとしてのテスト戦略
 ◦ チームが順調に機能している場合は良い
 ◦ 新しいメンバーが素早く把握することができる
 • チーム全体でテスト戦略の構築に参加すべき


  160. None
  161. Influencing Without Power
 5つの原則
 • 明示的に物事を作る
 • レーダーの上か下のどちらを飛行するか選ぶ
 • 負のスペースを描く


    • 損失を得る
 • 光を恐れない

  162. Influencing Without Power
 • 明示的に物事を作る
 ◦ 「これをやろうと思う」と言うと
 人々は”Good Luck”と言うが、
 「これを◦日目にやる」と言うと


    「どうすれば手伝える?」と言ってくれる

  163. Influencing Without Power
 • 損失を得る
 ◦ 議論が白熱している場合、
 負けの状況になる可能性がある。
 ◦ 「今は同意できないと思うので、また明日」


    と言ってみましょう。
 ◦ 今すぐ損失を取ることで、
 あとで解決できる場合があります。

  164. Influencing Without Power
 • 光を恐れない
 ◦ 誰もが価値を付加できる。
 ◦ 私たちは皆異なっていて特別。
 ◦

    私たちは自分のスキルと能力を信頼すべき。
 ▪ これこそが私たちの力

  165. None
  166. Ready Tester One? Go!
 テスターのキャリアパス
 • テスター → 開発者
 •

    テスター → 製品マネージャ
 • テスター → 管理職
 テスターの役割を非技術領域と読んでいたりする。
 • 「コードの学習」と「技術的である」は別物
 • では、技術的なスキルとは?

  167. Ready Tester One? Go!
 コアキャリアスキル
 • コミュニケーション
 • リサーチ
 •

    テクニカルライティング
 • プロジェクト管理
 • 探索的テスト

  168. Ready Tester One? Go!
 コアキャリアスキル
 • コマンドラインの使用方法の理解
 • ペアリング
 •

    モビング
 • 自動化
 • ツール

  169. Ready Tester One? Go!
 専門分野別のスーパーテスタースキル
 • Web
 • モバイル
 •

    Ops
 • データ分析
 • パイプライン
 • 設計/ユーザビリティ

  170. Ready Tester One? Go!
 専門分野別のスーパーテスタースキル
 • モニタリング/ロギング
 • パフォーマンス
 •

    セキュリティ
 • アクセシビリティ
 • IoT
 • サービス(API、検索機能など…)

  171. https://twitter.com/darktelecom/status/1192736910730506240

  172. Bell Bottoms & Beyond
 テスターのスキルギャップ
 • バイナリの考え方や解析の手がかりを持っていません。
 • 解釈済みまたは高レベルのスクリプトを使用します。
 •

    スレッドセーフではないコードを記述します。
 • 思考プロセスが同期的な仕組みになっています。
 要するに、私たちは技術の変化に全く対応できていません。

  173. None
  174. Agile Testing Daysに行って
 感じたこと


  175. Agile Testing Daysの良いところ
 • 発表者と聴講者の関係に留まっていない
 ◦ 参加型の発表も多い
 • ホテルが会場なので、そのまま宿泊できるし
 夜中までみんなでお喋りできる


    ◦ 当日の雰囲気は11/26のイベント(座談会)で…
 ▪ https://wingarc1st-spqi.connpass.com/event/155552/
 • 研究発表や事例発表ではなく、
 もっとカジュアルな発表が多い

  176. そういうイベントって
 日本に無いのかな…


  177. None
  178. None
  179. https://twitter.com/_mirer/status/685832359166390272

  180. おしまい