従来型QAからアジャイルQAへの 進化方法 テクバン 舘石 光寛 mabl 藤原 大

2 スポンサー企業紹介

3 ・資料はDiscord上の「テクバン」チャンネル、 およびセッション用チャンネルにてURLを公開しています ・動画は後日公開予定です ・SNS共有OKです 「#jassttokyo.b9」でツイートしていただけると後から拾いやすいです ・質問や感想はDiscord上のセッション用チャンネルにてお待ちしています その他

自己紹介

5 自己紹介 所属： 経歴： ・新卒で入社 → テスター → TE → QA → TAE ・テスト自動化の導入/運用支援、推進活動 その他の活動： ・社内外向けテスト自動化研修の実施 ・各種イベント / セミナーでの発表 舘石 光寛(たていし みつひろ) tateishi(@mt3_set)

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 ● セッションの概要 ● 従来型・アジャイル型の比較 ○ 開発プロセス ○ QA組織・役割 ● 「従来型」→「アジャイル型」へ ○ 進化例 ○ 立ちはだかる壁 ○ 原則・実践方法 ● まとめ 今日話すこと

セッションの概要

9 昨今、スタートアップを中心にアジャイル型開発手法を採用する企業も増 えてきましたが、その一方で「ウォーターフォール」を代表とする従来型 の開発プロセスのプロジェクトが多く存在するのもまた事実です。 本セッションでは、「従来型の開発プロセスにおけるQA」と「アジャイ ル開発におけるQA」のプロセスの違いや、実際に現場で直面する課題を 整理し、アジャイルQAに進化する方法を探ります。 セッションの概要

10 ● QA ○ 品質活動に関わる方をまとめてQAとしています ● アジャイルQA ○ アジャイル開発で活躍できるQAのことを指します ● アジャイルテスティング ○ アジャイル開発における品質活動全般を指します 用語の定義

従来型・アジャイル型の比較

12 従来型・アジャイル型の「開発プロセス」の比較 ● 特徴 ○ 要求分析～リリースまでが一方通行 ○ 工程（フェーズ）を重視する ○ 包括的で詳細なドキュメントを重視する ● Good ○ 作るものや期限が決まっているとやり やすい ○ 大きなモノに対応しやすい ○ フェーズによる担当範囲が明確 ● いまいち ○ ドキュメントなどのコストが大きい ○ 手戻りのリスクが大きい ○ チームに知識やノウハウがたまりにく い ● 特徴 ○ 短い期間で開発とリリースを繰り返す ○ 動くソフトウェアを重視する ○ 変化への対応を重視する ● Good ○ 期限なしで正しいものを作りやすい ○ チームで一体感が出やすい ○ 手戻りに早く気がつける ● いまいち ○ 全体的にコストは小さい分、仕様があいま いになりがち（大きなものが苦手） ○ 完成していないものをテストしなければな らない 従来型 アジャイル型

13 ● 役割 ○ QAフェーズにおけるテスト全般 ■ テスト計画 ＞ テスト設計 ＞ テ スト実行 ＞ レポーティン グ・・・ ○ 完成品のテスト ○ QAフェーズですべてを終わらせる ○ 網羅性重視 ■ スクリプトテストやリグレッショ ンを手動テスト ● 組織 ■ 開発とは別のQA組織 従来型・アジャイル型の「QA組織・役割」の比較 ● 役割 ○ リリースサイクル全般での継 続的なQA活動を行う ○ 小さな未完成品のテスト ○ 繰り返し改善を続ける ○ 効率性重視 ■ 探索テストや自動テストな ど ● 組織 ○ 開発チーム内にQAという活動 が必要（QAという人が必要で はない） 従来型 アジャイル型

14 開発がアジャイルなのに テストや品質はウォーターフォール

「従来型」→「アジャイル型」へ

16 アジャイルQAへの進化 スキルとマインドセットの変化が必要

17 あなたは1週間の短いスプリントで 開発を行っているチームの一員です。 テストを担当するQAエンジニアはいません。 さて、あなたはどのように プロダクトの品質を守りますか？ マインドセットの変化を体験してみよう

18 ● 短いサイクルの中で開発サイクル全体に対してQA活動を行う ○ 開発と同時にQA活動を開始しバグを作り込まないプロセスを整備する（作ってから確認し ていては遅い） ○ 小さく作り小さくテストする（最後にまとめてテストするのはリスクが高い） ● 速さに見合った品質を提供する（スピードと品質を両立する） ○ やること、やらないことを定義してリスクを理解する（リスクが分かっていればびっくり しない） ○ 広義で自動化を進める（CI、CD、テスト、運用手順など） ● テストを通じたフィードバックサイクルを構築する ○ テスト結果をプロダクトのためのフィードバックに変える（Verification → Validation） 「従来型」→「アジャイル型」への進化例

19 ● マインドセット ○ 壁： 「テストをする」の優先度が高すぎる。受け身・マンパワーになりがち ○ 対策例： アジャイルQAワークショップ（開発中、興味のある方はぜひご連絡を） を活用して、従来型でもアジャイル型でも活躍できる人材を育成していく ● スピードと品質 ○ 壁： マンパワーによる網羅性ではスピードに対応できない。一度やっているテス トをやめられない。自動化を進められない ○ 対策例： インクリメンタルでイテレーティブに自動化も進めていく ● フィードバック ○ 壁： プロダクトに必要なフィードバックができていない ○ 対策例： QAが仕様確認のテストをやらなくていい方法を考える 「従来型」→「アジャイル型」へ進化する際の壁

20 ● 開発チームの原則 ○ 短いイテレーションやスプリントで品質 活動を継続的に行う ○ テストとレビューを反復するプロセスを 確立する ○ スプリントごとにアーキテクチャレビュ ーを行い、インクリメンタル、イテレー ティブにシステムを進化させる ○ 継続的なフィードバックを通じてプロダ クトを検証し、さらに妥当性も確認する ○ 変化に強いチーム、プロフェッショナル を育て鍛えていく アジャイルQAの実践方法 ● 開発チームのプラクティス ○ アジャイル開発向けテスト全体計画書 ○ コードレビュー ○ リファクタリング基準の定義 ○ 新しいメトリクス ○ 新しいバグ管理プロセス ○ 単体テスト ○ 探索テスト ○ Mutation testing ○ 本番テスト ○ テストの自動化

21 アジャイルQAトレーニング

まとめ

23 ● 従来型とアジャイル型の選択が必要 ○ そのためにはそれぞれの特徴の理解が重要 ● アジャイルQAの原則 ○ 短いサイクルの中で開発サイクル全体に対してQA活動を行う ○ 速さに見合った品質を提供する（スピードと品質を両立する） ○ テストを通じたフィードバックサイクルを構築する セッションのまとめ

24 月次ウェビナー開催中！ 「探索的テスト」「テスト自動化」「次世 代QA組織」といったテーマをもとに「ア ジャイル・DevOps時代のテストや品質保 証」を目指すウェビナーです。 今後も、さまざまなトピックや、その道の プロフェッショナルにご登壇いただく予定 です。 mablからのご案内 今すぐできる2週間の無料トライアル！ トライアルは無料。納得行くまで機能をお試し ください。 デモリクエストも大歓迎！ 技術トレンドや実事例をまじえたデモMTGもお 気軽にどうぞ！ https://mabl-japan.connpass.com https://www.mabl.com/japan

25 テクバンのmabl・テスト自動化 導入/運用支援 テスト自動化・mablにおける 課題の解決をサポート ◆ サポート窓口 [email protected] ◆ お問い合わせ https://biz.techvan.co.jp/tech-quality/contact/