従来型QAからアジャイルQAへの進化方法

JaSST'22 Tokyo Track02 B9 テクノロジーセッションでの発表資料になります。

イベントページ：http://jasst.jp/symposium/jasst22tokyo.html

Transcript

1. 従来型QAからアジャイルQAへの 進化方法 テクバン 舘石 光寛 mabl 藤原 大
2. 2 スポンサー企業紹介
3. 3 ・資料はDiscord上の「テクバン」チャンネル、 およびセッション用チャンネルにてURLを公開しています ・動画は後日公開予定です ・SNS共有OKです 「#jassttokyo.b9」でツイートしていただけると後から拾いやすいです ・質問や感想はDiscord上のセッション用チャンネルにてお待ちしています その他
4. 自己紹介
5. 5 自己紹介 所属： 経歴： ・新卒で入社 → テスター → TE → QA → TAE ・テスト自動化の導入/運用支援、推進活動 その他の活動： ・社内外向けテスト自動化研修の実施 ・各種イベント / セミナーでの発表 舘石 光寛(たていし みつひろ) tateishi(@mt3_set)
6. 6 自己紹介 『アジャイル開発とスクラム』 https://www.amazon.co.jp/dp/4798129704/ 、『リーン開発の現場』 https://www.amazon.co.jp/dp/427406932X 藤原 大 mabl Japan 株式会社せかい代表 • 現在： 独立してスーパーアジャイルコーチ 開発組織の技術顧問（プロセス、QA中心） CTOやEMへのコーチング mablの日本顧客向けサポート • メルカリ： エンジニアリングマネージャ（EM) Software Engineer in Test（SET) テスト自動化、QA組織立ち上げ • 楽天： EM、アジャイルコーチ • 某SIer： Javaエンジニア • 活動: ◦ 『アジャイル開発とスクラム』寄稿 ◦ 『リーン開発の現場』翻訳 ◦ Twitter: @daipresents ◦ Blog: https://daipresents.com/service/
7. 7 • セッションの概要 • 従来型・アジャイル型の比較 ◦ 開発プロセス ◦ QA組織・役割 • 「従来型」→「アジャイル型」へ ◦ 進化例 ◦ 立ちはだかる壁 ◦ 原則・実践方法 • まとめ 今日話すこと
8. セッションの概要
9. 9 昨今、スタートアップを中心にアジャイル型開発手法を採用する企業も増 えてきましたが、その一方で「ウォーターフォール」を代表とする従来型 の開発プロセスのプロジェクトが多く存在するのもまた事実です。 本セッションでは、「従来型の開発プロセスにおけるQA」と「アジャイ ル開発におけるQA」のプロセスの違いや、実際に現場で直面する課題を 整理し、アジャイルQAに進化する方法を探ります。 セッションの概要
10. 10 • QA ◦ 品質活動に関わる方をまとめてQAとしています • アジャイルQA ◦ アジャイル開発で活躍できるQAのことを指します • アジャイルテスティング ◦ アジャイル開発における品質活動全般を指します 用語の定義
11. 従来型・アジャイル型の比較
12. 12 従来型・アジャイル型の「開発プロセス」の比較 • 特徴 ◦ 要求分析～リリースまでが一方通行 ◦ 工程（フェーズ）を重視する ◦ 包括的で詳細なドキュメントを重視する • Good ◦ 作るものや期限が決まっているとやり やすい ◦ 大きなモノに対応しやすい ◦ フェーズによる担当範囲が明確 • いまいち ◦ ドキュメントなどのコストが大きい ◦ 手戻りのリスクが大きい ◦ チームに知識やノウハウがたまりにく い • 特徴 ◦ 短い期間で開発とリリースを繰り返す ◦ 動くソフトウェアを重視する ◦ 変化への対応を重視する • Good ◦ 期限なしで正しいものを作りやすい ◦ チームで一体感が出やすい ◦ 手戻りに早く気がつける • いまいち ◦ 全体的にコストは小さい分、仕様があいま いになりがち（大きなものが苦手） ◦ 完成していないものをテストしなければな らない 従来型 アジャイル型
13. 13 • 役割 ◦ QAフェーズにおけるテスト全般 ▪ テスト計画 ＞ テスト設計 ＞ テ スト実行 ＞ レポーティン グ・・・ ◦ 完成品のテスト ◦ QAフェーズですべてを終わらせる ◦ 網羅性重視 ▪ スクリプトテストやリグレッショ ンを手動テスト • 組織 ▪ 開発とは別のQA組織 従来型・アジャイル型の「QA組織・役割」の比較 • 役割 ◦ リリースサイクル全般での継 続的なQA活動を行う ◦ 小さな未完成品のテスト ◦ 繰り返し改善を続ける ◦ 効率性重視 ▪ 探索テストや自動テストな ど • 組織 ◦ 開発チーム内にQAという活動 が必要（QAという人が必要で はない） 従来型 アジャイル型
14. 14 開発がアジャイルなのに テストや品質はウォーターフォール
15. 「従来型」→「アジャイル型」へ
16. 16 アジャイルQAへの進化 スキルとマインドセットの変化が必要
17. 17 あなたは1週間の短いスプリントで 開発を行っているチームの一員です。 テストを担当するQAエンジニアはいません。 さて、あなたはどのように プロダクトの品質を守りますか？ マインドセットの変化を体験してみよう
18. 18 • 短いサイクルの中で開発サイクル全体に対してQA活動を行う ◦ 開発と同時にQA活動を開始しバグを作り込まないプロセスを整備する（作ってから確認し ていては遅い） ◦ 小さく作り小さくテストする（最後にまとめてテストするのはリスクが高い） • 速さに見合った品質を提供する（スピードと品質を両立する） ◦ やること、やらないことを定義してリスクを理解する（リスクが分かっていればびっくり しない） ◦ 広義で自動化を進める（CI、CD、テスト、運用手順など） • テストを通じたフィードバックサイクルを構築する ◦ テスト結果をプロダクトのためのフィードバックに変える（Verification → Validation） 「従来型」→「アジャイル型」への進化例
19. 19 • マインドセット ◦ 壁： 「テストをする」の優先度が高すぎる。受け身・マンパワーになりがち ◦ 対策例： アジャイルQAワークショップ（開発中、興味のある方はぜひご連絡を） を活用して、従来型でもアジャイル型でも活躍できる人材を育成していく • スピードと品質 ◦ 壁： マンパワーによる網羅性ではスピードに対応できない。一度やっているテス トをやめられない。自動化を進められない ◦ 対策例： インクリメンタルでイテレーティブに自動化も進めていく • フィードバック ◦ 壁： プロダクトに必要なフィードバックができていない ◦ 対策例： QAが仕様確認のテストをやらなくていい方法を考える 「従来型」→「アジャイル型」へ進化する際の壁
20. 20 • 開発チームの原則 ◦ 短いイテレーションやスプリントで品質 活動を継続的に行う ◦ テストとレビューを反復するプロセスを 確立する ◦ スプリントごとにアーキテクチャレビュ ーを行い、インクリメンタル、イテレー ティブにシステムを進化させる ◦ 継続的なフィードバックを通じてプロダ クトを検証し、さらに妥当性も確認する ◦ 変化に強いチーム、プロフェッショナル を育て鍛えていく アジャイルQAの実践方法 • 開発チームのプラクティス ◦ アジャイル開発向けテスト全体計画書 ◦ コードレビュー ◦ リファクタリング基準の定義 ◦ 新しいメトリクス ◦ 新しいバグ管理プロセス ◦ 単体テスト ◦ 探索テスト ◦ Mutation testing ◦ 本番テスト ◦ テストの自動化
21. 21 アジャイルQAトレーニング
22. まとめ
23. 23 • 従来型とアジャイル型の選択が必要 ◦ そのためにはそれぞれの特徴の理解が重要 • アジャイルQAの原則 ◦ 短いサイクルの中で開発サイクル全体に対してQA活動を行う ◦ 速さに見合った品質を提供する（スピードと品質を両立する） ◦ テストを通じたフィードバックサイクルを構築する セッションのまとめ
24. 24 月次ウェビナー開催中！ 「探索的テスト」「テスト自動化」「次世 代QA組織」といったテーマをもとに「ア ジャイル・DevOps時代のテストや品質保 証」を目指すウェビナーです。 今後も、さまざまなトピックや、その道の プロフェッショナルにご登壇いただく予定 です。 mablからのご案内 今すぐできる2週間の無料トライアル！ トライアルは無料。納得行くまで機能をお試し ください。 デモリクエストも大歓迎！ 技術トレンドや実事例をまじえたデモMTGもお 気軽にどうぞ！ https://mabl-japan.connpass.com https://www.mabl.com/japan
25. 25 テクバンのmabl・テスト自動化 導入/運用支援 テスト自動化・mablにおける 課題の解決をサポート ◆ サポート窓口 mabl-support@techvan.co.jp ◆ お問い合わせ https://biz.techvan.co.jp/tech-quality/contact/