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

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

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

  2. 4.
  3. 15.

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

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

  4. 16.

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


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

  5. 17.

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


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

  6. 18.

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


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

  7. 20.

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

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

  8. 21.

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

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

  9. 22.

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

    • 製品に依存している他の製品/機能/システムは何ですか? プラットフォーム • 製品の言語は何ですか? • どのサーバーとサービスが使用されていますか? ◦ ロードバランサー、スプーラー、ネットワークデバイスなど
  10. 23.

    チーム(Team) その1
 あなたのチームについて • あなたのチームには誰がいますか? ◦ 彼らの役割は何ですか? ◦ 彼らはあなたにどんなドキュメントを期待していますか? •

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

  11. 25.

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


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

  12. 34.
  13. 38.

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


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

  14. 39.

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


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

  15. 40.

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


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

  16. 41.

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


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

  17. 42.

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

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

  18. 43.

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

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

  19. 44.

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

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

  20. 45.

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

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

  21. 46.
  22. 47.

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

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

  23. 49.
  24. 50.

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

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

  25. 51.

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

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

  26. 53.

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


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

  27. 54.

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


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

  28. 56.
  29. 59.

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


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

  30. 60.

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


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

  31. 61.

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


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

  32. 62.

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

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

  33. 65.

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

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

  34. 67.

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

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

  35. 68.
  36. 69.

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

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

  37. 70.

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


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

  38. 71.
  39. 72.

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

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

  40. 73.

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


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

  41. 74.

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

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

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

  43. 77.

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

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

  44. 78.

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

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

  45. 79.

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

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

  46. 80.

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

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

  47. 81.

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

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

  48. 82.

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

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

  49. 83.

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

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

  50. 84.

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

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

  51. 85.

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

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

  52. 86.

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

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

  53. 87.

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

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

  54. 88.

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

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

  55. 89.

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

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

  56. 90.

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

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

  57. 92.

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

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

  58. 93.
  59. 94.
  60. 98.

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

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

  61. 104.

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


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

  62. 105.

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


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

  63. 106.

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


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

  64. 107.

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


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

  65. 111.

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

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

  66. 117.
  67. 118.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  68. 119.
  69. 120.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  70. 121.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  71. 122.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  72. 123.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  73. 124.

    LEARN FROM THE FAMOUS DETECTIVE DUO TO IMPROVE YOUR TESTING

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

  74. 131.
  75. 139.

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

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

  76. 142.

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

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

  77. 143.

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

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

  78. 144.

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

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

  79. 145.

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

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

  80. 146.

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

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

  81. 147.

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

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

  82. 152.

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

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

  83. 157.
  84. 160.
  85. 164.

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

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

  86. 165.
  87. 166.

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

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

  88. 167.

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

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

  89. 169.

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

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

  90. 170.

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

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

  91. 172.

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

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

  92. 173.
  93. 175.

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


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

  94. 177.
  95. 178.