アジャイル開発 QAチーム不要論
29K Views
January 29, 23
スライド概要
アジャイル開発で独立したQA組織は必要でしょうか？
アジャイル開発でのQAの役割って何？
QAが直面する課題と解決策を、例示を交えてご紹介します。
※引用文献の記載がない箇所、および、参考文献のみの箇所は、個人の意見です
Do we need a Independent QA Team for Agile Development?
What's the role of QA during agile development?
There are some examples of the problems faced by QA and their solutions also.
And notes that all of these solutions suggest that an independent QA team is not necessary.
As it's just my opinion, this slide is in Japanese language only.
web制作会社でQAしてます。守秘義務や社内規則が厳しいので、会社名が明かしにくい＋概念系の話が多いかも！
関連スライド
各ページのテキスト
アジャイル開発 QAチーム不要論 Need a Independent QA Team for Agile Development? @s_rhdoh
こんな⼈向け ● アジャイル開発でQAを導⼊したけれど、スプリントを圧迫して 上⼿くいかなかった ● ⾃動テスト、ノーコードで全部組みたい ● ⾃分のPJではテストしている暇はないからテストを効率よく削り たいという気持ちがわいてる 取り扱わない話 ウォーターフォール開発ではQAチームは必要か そうじゃない⼈はブラウザバックでOK このテンプレートは © Presentation Design からお借りしています（テーマカラーは変えています）
Contents 1. 現PJで困ったこと 2. 解決策（案）は４つ 3. どの解決策も「QAチーム」はいらない 3
1. 現PJで困ったこと 因⼦⽔準の多い NEW ECサイト ＋ 別サイト Hybrid Agile • 全体⼯程はウォーターフォール • スプリント管理と思想がアジャイル
1. 現PJで困ったこと NEW 別サイト スプリントは2週間 10⽇だよ！
1. 現PJで困ったこと NEW 別サイト ポイントギリギリ ヨシッ 設計1 設計2 設計3 レビュー テスト バック修正 実施準備
1. 現PJで困ったこと NEW 別サイト 決まるはずの 仕様未確定 あふれる 設計1 設計2 臨時 リファイン メント 設計4ʼ テスト レビュー バック修正 実施準備
1. 現PJで困ったこと NEW 別サイト mtgで詳細を詰め切らない / コミュニケーションエラー テスト対象間違い あふれる 設計1 設計2 設計１ (再設計) 設計3 テスト レビュー バック修正 実施準備
1. 現PJで困ったこと スピードが⾜りない コミュニケーション不⾜ 仕様が決まらない
1. 現PJで困ったこと 現PJは まさにこんな状態 因⼦⽔準が多い “製品が大きくなるにつれテスト量は飛躍的に増加し、QA チームは常に付 いていくのに必死です。プロジェクト所有者は、リリースを遅らせるか、 テストをスキップするかという望ましくない選択に直面します。(99% どち らが勝つか、おわかりでしょう?) 一方、開発チームはすでに他の作業に着手しています。つまり、技術的負 債が積もるだけではなく、それぞれの不具合に取り組むことにより、コー ド ベースの 2 か所の間でコンテキスト切り替えが必要となり、大きな犠牲 がともないます。何ともばかげた損害です。” –DAN RADIGAN/ATLASSIAN 「アジャイルテストのプラクティスを通じてさらなる⾼品質を実現」
1. 現PJで困ったこと コミュニケーションで解決は可能 ただ⼈は間違える 仕組み化・環境づくりが⼤事
2. 解決策（案） • アジャイル開発事例 • AATDの良書
2. 解決策（案）は４つある ▍アジャイル開発事例 ”アジャイルテストのプラクティスを通じ てさらなる⾼品質を実現” / 作成者 DAN RADIGAN ⼤規模アジャイルより （アジャイルに関するページが豊富） ATLASSIAN 「⼤規模アジャイル」トップページ (2023.01.16時点)
2. 解決策（案）は４つある ▍ATDD良書 著者は10年くらいリーン⽣産⽅式やア ジャイル⽣産⽅式で開発するためのチー ムワークを実践。WIkiでの参照が多いか ら読んでみた。2010年の本だけど事例 ベースでめっちゃわかりやすい。TDDと ATDDとの違いがくっきりしている Amazon(Kindle) ¥3000以内で読める！ Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
2. 解決策（案）は４つある 1 QAを開発チームへ分散 導⼊しやすさ ★★☆ コミュニケーション改善 仕様決定促進 事例）楽天, Base, ATLASSIANなど多数 3 探索的テストの活⽤ 導⼊しやすさ ★★☆ スピードアップ 事例）現PJ, ATLASSIAN など 2 テスト⾃動化 導⼊しやすさ ★★★ スピードアップ 事例）現PJ, メルペイ, ATLASSIANなど多数 4 受け⼊れテスト駆動開発 導⼊しやすさ コミュニケーション改善 ★☆☆ 仕様決定促進 スピードアップ 事例）Base, SmartHR など
2. 解決策（案）は４つある 1 QAを開発チームへ分散 あなたが本当に欲しいものはQA組織ですか？ “もし、「開発者がテストをする時間がない」のであれば、QA組織を作っても同じこと が起きます。 開発もテストももともとは表裏⼀体、ひとつです。どちらかを減らすことはできませ ん。テストをする時間がなければ取ればいいはずです。開発者なら⾃動化も⽐較的楽に 進められます。開発量が少ないなら、開発者を採⽤すればいいはずです。” “アジャイル開発とQA（品質保証）は相性がバツグンに悪い” (accessed: 2023.01.16 ) / mablなどの スーパーアジャイルコーチ Dai FUJIHARA
2. 解決策（案）は４つある そもそもQAが注⼒する領域ってなに スペシャリスト • テストアーキテクチャ設計 • メトリクスの可視化 • テストコードとカバレッジを理解 • ホワイトボックステストの精査 • 探索的テストの設計 • テストプロセスの評価 マネージャ • テスト⽬的とリスクの整理 • テスト全体の活動計画の⽴案 • テストプロセス全体の最適化 • テストツールの選択と実装⽀援 • 各組織へのQA活動の発信 客観性担保のため外部テストベンダーによるテスト実施とできるとBetter 参考 ”QA組織が最後の砦から脱却するために”(2021) / Akatsuki Tomotaka Yamasaki
2. 解決策（案）は４つある “開発者はコードに関する問題を解決する ことが得意である。 開発者は作成したテストが失敗した時 に、他の誰よりもそれを修正する能⼒が ある。 開発者はフィーチャー要件とテストの意 義を理解して、より良いコードを作成す るものである。” アジャイルテストのプラクティスを通じてさらなる⾼品質を実現 / DAN RADIGAN 内の”Quality at Speed”の解説 ※フィーチャー：機能の⼩さな塊 ATLASSIAN”Quality at Speed” / Penny Wyatt
2. 解決策（案）は４つある “これは、開発者が単独で作業するという 意味ではありません。チームに QA エン ジニアがいるということも重要です。 フィーチャーの開発にとって QA エンジ ニアは重要な視点をもたらすうえ、優れ た QA エンジニアはバグが隠れていそう な場所を認識しているため、予測して開 発者にアドバイスできます。” アジャイルテストのプラクティスを通じてさらなる⾼品質を実現 / DAN RADIGAN 内の”Quality at Speed”の解説 ※フィーチャー：機能の⼩さな塊 ATLASSIAN”Quality at Speed” / Penny Wyatt
2. 解決策（案）は４つある QAチームいらないかな そして、QAはテストだけではなく 探索的テスト観点を コーチングする技術を学ぼう
2. 解決策（案）は４つある 2 テスト⾃動化 すべて⾃動テストにするのはきついのでは？ “Do not automate everything.” ー なんでも⾃動化するんじゃない Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
2. 解決策（案）は４つある アジャイルでのテストフレームワーク Agile Testing Quadrants ⾃動化 スコープ Trends in Agile Testing by Lisa Crispin (2009) /Lisa Crispin, Janet Gregory Test Matrix ⾃動化 スコープ Lean Agile Acceptance Test-Driven-Development (2010) / Ken Pugh
2. 解決策（案）は４つある 各テストボリュームの考え⽅ Unit 単体テスト • 基本機能のみが期待通りに動作すること • カバレッジに拘らない（諸説あり） • あまり細分化とモック化をやりすぎると TDDが死んでしまう “TDD is dead. Long live testing.”(2014) (TDDは死んだ。テスト万歳(万歳と持続可能なテストをかけて いるっぽい))/David Heinemeier Hansson Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds
2. 解決策（案）は４つある 各テストボリュームの考え⽅ Integration 内結テスト • [Testing Trophy]の考えを採⽤するな ら、内結テストの⾃動化を充実させる • コードによる⾃動化が⼀般的 （JavascriptならJest + React Testing Libraryなど） Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds
2. 解決策（案）は４つある 各テストボリュームの考え⽅ End to End 総合テスト •e 2 e テ ス ト は そ こ そ こ ( コ ー ド Playwright, Cypressなど、 ノーコード だとAutify, mablなど) • ノーコードは実装が早い！課⾦が⾼い。 フレイキーになりがち（現PJでは Autify → mabl乗り換えの結果フレイ キーさが減ったけれどまだフレイキー） Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds
2. 解決策（案）は４つある QAはe2eテストならできる でもそんなに⼈数いらないかな
2. 解決策（案）は４つある 3 探索的テストの活⽤ 探索的テストとは “探索的テストはリスクベースで、批判的思考によるアプローチです。リスクに関する ナレッジ、実装の詳細、カスタマーニーズを⽤いてテストを実施できます。 〜中略〜 開発者や QA エンジニアはテストケースのスクリプト、詳細なテストプラン、要件など を必要とせず、問題を早急に包括的に発⾒できます。” アジャイルテストのプラクティスを通じてさらなる⾼品質を実現/ DAN RADIGAN
2. 解決策（案）は４つある ２派ある
2. 解決策（案）は４つある 主要なテスト テストケース作成の上実施 条件が複雑なテスト 探索的テストにて担保
2. 解決策（案）は４つある 主要なテスト 探索的テストにて担保 条件が複雑なテスト テストケース作成の上実施
2. 解決策（案）は４つある 取り⼊れようとしています
2. 解決策（案）は４つある テスト観点 （ボタン特殊押下やテキストボックス特殊記⼊など） その他汎⽤的な テスト観点を テンプレ化し、 準備時間はゼロ 該当テスト観点にて ⾏う操作をリストアップ • 不具合があれば、フォーマットに記録を残す • なくても何をしたかの記録が残る 実施テンプレ（画⾯はだせないので概念のみ）
2. 解決策（案）は４つある いつか開発だけで 探索的テストできるように なるんじゃないかな
2. 解決策（案）は４つある 4 受け⼊れテスト駆動設計(ATDD) 受け⼊れテスト駆動設計とは “ Jeff Sutherland, the cocreator of Scrum, has metrics on software productivity [Sutherland01]. He has found that adding a quality assurance person to the team and creating acceptance tests prior to implementation doubles the team's productivity. ” ジェフ スクラムの共同開発者であるサザーランドは、ソフトウエアの⽣産性に関する指 標を持っている[Sutherland01]。彼は、品質保証の担当者をチームに加え、実装前に受 け⼊れテストを作成することで、チームの⽣産性が倍増することを実感しているそうで す” Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
2. 解決策（案）は４つある で、どうするのか
2. 解決策（案）は４つある ATDDでないとき • QAはすぐ設計に着⼿できず、リードタイムが発⽣ • 仕様決定段階でテスタブルかどうか確認できていない、テスト設計可能 なレベルまで仕様詳細が未定といった要因で⼿戻りが発⽣する 仕様決定 開発・テスト設計 開発可能 か検討 仕様詳細が 未確定 準備・テスト実施 リリース
2. 解決策（案）は４つある ATDDであるとき • 仕様ではなくテストを開発者、テスター、クライアント3⼈にて議論し 決める（兼任可） • テストが通れば仕様通りの実装ができている • 要件定義→テスト作成とはせず、テストが要件となる テスト設計（＝仕様） 開発・テスト準備 開発可能 か検討 仕様詳細が 未確定 テスト実施 リリース
2. 解決策（案）は４つある ATDDであるとき • もちろん、いきなりテストをつくらない • PJ⼤⽅針 → ストーリー → シナリオを決めてからテスト（＝仕様）決 定というように、納得感のある⼤きな⼿戻りを防ぐプロセスを踏む Fig. Projects Start with the Charter Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
2. 解決策（案）は４つある みんなでテスト設計するなら QAが注⼒する領域にのみ QAの⼈数を割くことができるのでは？ （＝QAの⼈数は少なくできる）
3. ということで
3. どの解決策も「QAチーム」はいらない 爆速スピードのテスト コミュニケーションとりやすい体制 詳細な仕様決定
3. どの解決策も「QAチーム」はいらない アジャイル開発での QAの独⽴チーム不要度を ★評価してみる
3. どの解決策も「QAチーム」はいらない 1 QAを開発チームへ分散 もうチームない コミュニケーション改善 ★★★ 仕様決定促進 事例）楽天, Base, ATLASSIANなど多数 3 探索的テストの活⽤ 開発へのコーチング中 開発へのコーチング後 ★☆☆ ★★☆ スピードアップ 事例）現PJ, ATLASSIAN など 2 テスト⾃動化 コードテストの壁 ★★☆ スピードアップ 事例）現PJ, メルペイ, ATLASSIANなど多数 4 受け⼊れテスト駆動開発 もうチームない コミュニケーション改善 ★★★ 仕様決定促進 スピードアップ 事例）Base, SmartHR など