リスクベースドアプローチで機能テストの方針を決めたのJaSST nano vol.2つとむ(@tsutomun1985121)
View Slide
自己紹介◇名前:つとむ (@tsutomun1985121)◇職業:QAエンジニア/テストエンジニア(B to B プロダクト)◇趣味:猫と遊ぶ/フットサル/読書◇今、頑張っていること:・JSTQB AL TMの学習・ブログ記事作成
目次1. はじめに2. 困っていたこと3. 何をしたか4. どうなったか5. まとめ
1. はじめに開発体制◆2つのフィーチャーチームでプロダクトを開発◆1チーム7名で構成
1. はじめに開発手法アジャイル開発◆タイムボックス1スプリント2週間◆QAの役割・各フィーチャーチームでQAエンジニアとして活動・詳細設計のレビュー・開発が完了したユーザストーリ、不具合のテスト設計/テスト実施・不具合分析を実施し、開発チームへのフィードバック
2. 困っていたこと課題 顕在化していたリスク開発者テストとQAのテスト内容が重複QAがボトルネックとなり、リリースできない機能改修が発生QAが全てのリリース対象に対して、手動で機能テストをする
開発チーム全体でテストをできるようにしたいなあ。。。
3. 何をしたか⚫リスク分析を用いて、機能テストにおけるQAの関わり方を定義⚫QAの役割を整理
リスク分析を用いて、機能テストにおけるQAの関わり方を定義⚫5段階(XL、L、M、S、XS)のリスクレベルを定義⚫ユーザストーリーや不具合の修正内容、影響範囲を確認し、欠陥によって引き起こされる問題の重大性を評価する⚫評価したリスクレベルを合意リスクレベルがXL:法要件を満たしていない/お金に関わる問題(未払い、過剰請求など)リスクレベルがL :エラーとなるべきデータが登録できるリスクレベルがM :画面が意図通り表示されないリスクレベルがS :英語のスペルミス/分かりにくいメッセージ
リスク分析を用いて、機能テストにおけるQAの関わり方を定義1.リスクが高い開発(リスクレベルがXL)に対して、QAがテスト設計を行うリスクレベルがXL:法要件を満たしていない/お金に関わる問題(未払い、過剰請求など)リスクレベルがL :エラーとなるべきデータが登録できるリスクレベルがM :画面が意図通り表示されないリスクレベルがS :英語のスペルミス/分かりにくいメッセージ
リスク分析を用いて、機能テストにおけるQAの関わり方を定義2.リスクが高くない開発(リスクレベルがXLではない)に対して、QAが開発者のテストを支援する• テストケースのレビュー• テスト技法のレクチャー
リスク分析を用いて、機能テストにおけるQAの関わり方を定義3.全てのリスクレベルの開発に対して、QAがアドホックテストを1~3時間実施目的• 開発チームに早く、簡単にフィードバックする• テスト対象の学習• テストケース作成にフィードバックする
リスク分析を用いて、機能テストにおけるQAの関わり方を定義⚫ まとめテストタイプ リスクレベル テスト設計 テスト設計レビューテスト実行機能テスト XS~S 開発担当者 開発レビュアー 開発担当者M~L 開発担当者 QAレビュアー 開発担当者機能テスト XL QA担当者 開発担当者 開発/QAチームアドホックテスト S~XL ー ー QA担当者
QAの役割を整理⚫ プロダクトの品質目標策定と遂行に向けた活動⚫ 組織のテストポリシー、テスト戦略の策定⚫ テストプロセスの定義と改善⚫ 機能性を除く品質特性のテストをリード⚫ 開発エンジニアへの検証技術・ドメイン知識の継承
4. どうなったか課題 顕在化していたリスク開発者テストとQAのテスト内容が重複QAがボトルネックとなり、リリースできない機能改修が発生QAが全てのリリース対象に対して、手動で機能テストをする
4. どうなったか⚫QAがボトルネックとなり、リリースできない状態がなくなった⚫QAがチーム全体の品質向上に向けた取組みに着手できた⚫リリース後バグがそれほど出ていない
4. どうなったか+αの効果⚫ 開発者自身で品質を確保する意識が高まった⚫ 開発者が品質に興味をもってくれた⚫ 開発者とQAがより積極的にコミュニケーションをとるようになった
5. まとめリスクという軸を使って、QAエンジニアと開発エンジニアで協力して、テストをする
参考資料リスクベースドテストを活用しよう 井芹 洋輝https://www.slideshare.net/goyoki/ss-29203311?next_slideshow=2リスク・ベース・テストの効果と限界http://www.aerith.net/design/risk-base-test-j.html
以上です。ご清聴ありがとうございましたつとむ(@tsutomun1985121)