アジャイル開発 QAチーム不要論

アジャイル開発で独立した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.

Transcript

1. QAチーム不要論 アジャイル開発 Need a Independent QA Team for Agile Development? @s_rhdoh
2. このテンプレートは © Presentation Design からお借りしています（テーマカラーは変えています） こ ん な ⼈ 向 け • アジャイル開発でQAを導⼊したけれど、スプリントを圧迫して  上⼿くいかなかった • ⾃動テスト、ノーコードで全部組みたい • ⾃分のPJではテストしている暇はないからテストを効率よく削り たいという気持ちがわいてる 取り扱わない話 ウォーターフォール開発ではQAチームは必要か そうじゃない⼈はブラウザバックでOK
3. 3 1. 現PJで困ったこと 2. 解決策（案）は４つ 3. どの解決策も「QAνʔϜ」はいらない Contents
4. 1. 現PJで困ったこと ECサイト ＋ 別サイト Hybrid Agile NEW •全体⼯程はウォーターフォール •スプリント管理と思想がアジャイル 因⼦⽔準の多い
5. 1. 現PJで困ったこと 別サイト NEW スプリントは2週間 10⽇だよ！
6. 1. 現PJで困ったこと 別サイト NEW ポイントギリギリ 設計1 設計2 設計3 レビュー バック修正 テスト 実施準備 ヨシッ
7. 1. 現PJで困ったこと 別サイト NEW 仕様未確定 設計1 設計2 設計4ʼ レビュー バック修正 テスト 実施準備 あふれる 臨時 リファイン メント 決まるはずの
8. 1. 現PJで困ったこと 別サイト NEW テスト対象間違い 設計1 設計2 設計3 レビュー バック修正 テスト 実施準備 あふれる mtgで詳細を詰め切らない / コミュニケーションエラー 設計１ (再設計)
9. 1. 現PJで困ったこと スピードが⾜りない コミュニケーション不⾜ 仕様が決まらない
10. 1. 現PJで困ったこと –DAN RADIGAN/ATLASSIAN 「アジャイルテストのプラクティスを通じてさらなる⾼品質を実現」 “੡඼͕େ͖͘ͳΔʹͭΕςετྔ͸ඈ༂తʹ૿Ճ͠ɺQA νʔϜ͸ৗʹ෇ ͍͍ͯ͘ͷʹඞࢮͰ͢ɻϓϩδΣΫτॴ༗ऀ͸ɺϦϦʔεΛ஗ΒͤΔ͔ɺ ςετΛεΩοϓ͢Δ͔ͱ͍͏๬·͘͠ͳ͍બ୒ʹ௚໘͠·͢ɻ(99% Ͳͪ Β͕উ͔ͭɺ͓Θ͔ΓͰ͠ΐ͏?) Ұํɺ։ൃνʔϜ͸͢Ͱʹଞͷ࡞ۀʹணख͍ͯ͠·͢ɻͭ·Γɺٕज़తෛ ࠴͕ੵ΋Δ͚ͩͰ͸ͳ͘ɺͦΕͧΕͷෆ۩߹ʹऔΓ૊Ή͜ͱʹΑΓɺίʔ υ ϕʔεͷ 2 ͔ॴͷؒͰίϯςΩετ੾Γସ͕͑ඞཁͱͳΓɺେ͖ͳ٘ਜ਼ ͕ͱ΋ͳ͍·͢ɻԿͱ΋͹͔͛ͨଛ֐Ͱ͢ɻ” 因⼦⽔準が多い現PJは まさにこんな状態
11. 1. 現PJで困ったこと コミュニケーションで解決は可能 ただ⼈は間違える 仕組み化・環境づくりが⼤事
12. • アジャイル開発事例 • AATDの良書 2. 解決策（案）
13. 2. 解決策（案）は４つある ‰アジャイル開発事例 ”アジャイルテストのプラクティスを通じ てさらなる⾼品質を実現” / 作成者 DAN RADIGAN ⼤規模アジャイルより （アジャイルに関するページが豊富） ATLASSIAN 「⼤規模アジャイル」トップページ (2023.01.16時点)
14. 2. 解決策（案）は４つある ‰ATDD良書 著者は10年くらいリーン⽣産⽅式やア ジャイル⽣産⽅式で開発するためのチー ムワークを実践。WIkiでの参照が多いか ら読んでみた。2010年の本だけど事例 ベースでめっちゃわかりやすい。TDDと ATDDとの違いがくっきりしている Amazon(Kindle) ¥3000以内で読める！ Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
15. 2. 解決策（案）は４つある 2 テスト⾃動化    導⼊しやすさ  ★★★ スピードアップ 事例）現PJ, メルペイ, ATLASSIANなど多数 3 探索的テストの活⽤    導⼊しやすさ  ★★☆ スピードアップ 事例）現PJ, ATLASSIAN など 1 QAを開発チームへ分散    導⼊しやすさ  ★★☆ コミュニケーション改善  仕様決定促進 事例）楽天, Base, ATLASSIANなど多数 4 受け⼊れテスト駆動開発    導⼊しやすさ  ★☆☆ コミュニケーション改善  仕様決定促進 スピードアップ 事例）Base, SmartHR など
16. 2. 解決策（案）は４つある 1 QAを開発チームへ分散 あなたが本当に欲しいものはQA組織ですか？ “もし、「開発者がテストをする時間がない」のであれば、QA組織を作っても同じこと が起きます。 開発もテストももともとは表裏⼀体、ひとつです。どちらかを減らすことはできませ ん。テストをする時間がなければ取ればいいはずです。開発者なら⾃動化も⽐較的楽に 進められます。開発量が少ないなら、開発者を採⽤すればいいはずです。” “アジャイル開発とQA（品質保証）は相性がバツグンに悪い” (accessed: 2023.01.16 ) / mablなどの スーパーアジャイルコーチ Dai FUJIHARA
17. 2. 解決策（案）は４つある 参考 ”QA組織が最後の砦から脱却するために”(2021) / Akatsuki Tomotaka Yamasaki スペシャリスト •テストアーキテクチャ設計 •メトリクスの可視化 •テストコードとカバレッジを理解 •ホワイトボックステストの精査 •探索的テストの設計 •テストプロセスの評価 そもそもQAが注⼒する領域ってなに マネージャ •テスト⽬的とリスクの整理 •テスト全体の活動計画の⽴案 •テストプロセス全体の最適化 •テストツールの選択と実装⽀援 •各組織へのQA活動の発信 客観性担保のため外部テストベンダーによるテスト実施とできるとBetter
18. アジャイルテストのプラクティスを通じてさらなる⾼品質を実現 / DAN RADIGAN 内の”Quality at Speed”の解説 ※フィーチャー：機能の⼩さな塊 2. 解決策（案）は４つある “開発者はコードに関する問題を解決する ことが得意である。 開発者は作成したテストが失敗した時 に、他の誰よりもそれを修正する能⼒が ある。 開発者はフィーチャー要件とテストの意 義を理解して、より良いコードを作成す るものである。” ATLASSIAN”Quality at Speed” / Penny Wyatt
19. 2. 解決策（案）は４つある “これは、開発者が単独で作業するという 意味ではありません。チームに QA エン ジニアがいるということも重要です。 フィーチャーの開発にとって QA エンジ ニアは重要な視点をもたらすうえ、優れ た QA エンジニアはバグが隠れていそう な場所を認識しているため、予測して開 発者にアドバイスできます。” ATLASSIAN”Quality at Speed” / Penny Wyatt アジャイルテストのプラクティスを通じてさらなる⾼品質を実現 / DAN RADIGAN 内の”Quality at Speed”の解説 ※フィーチャー：機能の⼩さな塊
20. 2. 解決策（案）は４つある QAチームいらないかな そして、QAはテストだけではなく 探索的テスト観点を コーチングする技術を学ぼう
21. 2. 解決策（案）は４つある 2 テスト⾃動化 すべて⾃動テストにするのはきついのでは？ “Do not automate everything.” ー なんでも⾃動化するんじゃない Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh
22. 2. 解決策（案）は４つある Trends in Agile Testing by Lisa Crispin (2009) /Lisa Crispin, Janet Gregory Agile Testing Quadrants アジャイルでのテストフレームワーク Test Matrix Lean Agile Acceptance Test-Driven-Development (2010) / Ken Pugh ⾃動化 スコープ ⾃動化 スコープ
23. “TDD is dead. Long live testing.”(2014) (TDDは死んだ。テスト万歳(万歳と持続可能なテストをかけて いるっぽい))/David Heinemeier Hansson 2. 解決策（案）は４つある 各テストボリュームの考え⽅ Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds • 基本機能のみが期待通りに動作すること • カバレッジに拘らない（諸説あり） • あまり細分化とモック化をやりすぎると TDDが死んでしまう Unit 単体テスト
24. 2. 解決策（案）は４つある 各テストボリュームの考え⽅ Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds • [Testing Trophy]の考えを採⽤するな ら、内結テストの⾃動化を充実させる • コードによる⾃動化が⼀般的 （JavascriptならJest + React Testing Libraryなど） Integration 内結テスト
25. 2. 解決策（案）は４つある 各テストボリュームの考え⽅ Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds • e 2 e テ ス ト は そ こ そ こ ( コ ー ド Playwright, Cypressなど、 ノーコード だとAutify, mablなど) • ノーコードは実装が早い！課⾦が⾼い。 フ レ イ キ ー に な り が ち （ 現 P J で は Autify → mabl乗り換えの結果フレイ キーさが減ったけれどまだフレイキー） End to End 総合テスト
26. 2. 解決策（案）は４つある QAはe2eテストならできる でもそんなに⼈数いらないかな
27. 2. 解決策（案）は４つある 3 探索的テストの活⽤ 探索的テストとは “探索的テストはリスクベースで、批判的思考によるアプローチです。リスクに関する ナレッジ、実装の詳細、カスタマーニーズを⽤いてテストを実施できます。 〜中略〜 開発者や QA エンジニアはテストケースのスクリプト、詳細なテストプラン、要件など を必要とせず、問題を早急に包括的に発⾒できます。” アジャイルテストのプラクティスを通じてさらなる⾼品質を実現/ DAN RADIGAN
28. 2. 解決策（案）は４つある ２ 派 あ る
29. 2. 解決策（案）は４つある 主要なテスト テストケース作成の上実施 条件が複雑なテスト 探索的テストにて担保
30. 2. 解決策（案）は４つある 主要なテスト 探索的テストにて担保 条件が複雑なテスト テストケース作成の上実施
31. 2. 解決策（案）は４つある 取 り ⼊ れ よ う と し て い ま す
32. 2. 解決策（案）は４つある 実施テンプレ（画⾯はだせないので概念のみ） その他汎⽤的な テスト観点を テンプレ化し、 準備時間はゼロ テスト観点 （ボタン特殊押下やテキストボックス特殊記⼊など） 該当テスト観点にて ⾏う操作をリストアップ •不具合があれば、フォーマットに記録を残す •なくても何をしたかの記録が残る
33. 2. 解決策（案）は４つある いつか開発だけで 探索的テストできるように なるんじゃないかな
34. 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
35. 2. 解決策（案）は４つある で 、 ど う す る の か
36. 仕様詳細が 未確定 2. 解決策（案）は４つある • QAはすぐ設計に着⼿できず、リードタイムが発⽣ • 仕様決定段階でテスタブルかどうか確認できていない、テスト設計可能 なレベルまで仕様詳細が未定といった要因で⼿戻りが発⽣する ATDDでないとき 仕様決定 開発・テスト設計 準備・テスト実施 リリース 開発可能 か検討
37. 仕様詳細が 未確定 2. 解決策（案）は４つある • 仕様ではなくテストを開発者、テスター、クライアント3⼈にて議論し 決める（兼任可） • テストが通れば仕様通りの実装ができている • 要件定義→テスト作成とはせず、テストが要件となる ATDDであるとき テスト設計（＝仕様） 開発・テスト準備 テスト実施 リリース 開発可能 か検討
38. 2. 解決策（案）は４つある • もちろん、いきなりテストをつくらない • PJ⼤⽅針 → ストーリー → シナリオを決めてからテスト（＝仕様）決 定というように、納得感のある⼤きな⼿戻りを防ぐプロセスを踏む ATDDであるとき Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh Fig. Projects Start with the Charter
39. 2. 解決策（案）は４つある みんなでテスト設計するなら QAが注⼒する領域にのみ QAの⼈数を割くことができるのでは？ （＝QAの⼈数は少なくできる）
40. 3. ということで
41. 3. どの解決策も「QAチーム」はいらない 爆速スピードのテスト コミュニケーションとりやすい体制 詳細な仕様決定
42. 3. どの解決策も「QAチーム」はいらない アジャイル開発での QAの独⽴チーム不要度を ★評価してみる
43. 3. どの解決策も「QAチーム」はいらない 2 テスト⾃動化   コードテストの壁  ★★☆ スピードアップ 事例）現PJ, メルペイ, ATLASSIANなど多数 1 QAを開発チームへ分散    もうチームない  ★★★ コミュニケーション改善  仕様決定促進 事例）楽天, Base, ATLASSIANなど多数 4 受け⼊れテスト駆動開発    もうチームない  ★★★ コミュニケーション改善  仕様決定促進 スピードアップ 事例）Base, SmartHR など 3 探索的テストの活⽤ 開発へのコーチング中  ★☆☆ 開発へのコーチング後  ★★☆ スピードアップ 事例）現PJ, ATLASSIAN など