JaSST'22 Tokyo Track02 B9 テクノロジーセッションでの発表資料になります。
イベントページ：http://jasst.jp/symposium/jasst22tokyo.html
従来型QAからアジャイルQAへの進化方法テクバン 舘石 光寛 mabl 藤原 大
View Slide
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/
mt3_set
miyakemito
regonn
asazutaiga
drumath2237
takashiinui
hirokiotsuka
visional_engineering_and_design
devops_vtj
stefafafan
tgalopin
iwashi86
tomohisa
samanthasiow
marcelosomers
samlambert
rocio
searls
keathley
productmarketing
paulrobertlloyd
cassininazir
jrom
gr2m
deanohume