←prev entry Top next entry→
第3回

現在アジャイル開発※の現場に携わっています。
その現場で、クリティカルなバグを効率よく検出するために
リスクベーステストをしているので、そのステップの一例を記載します。
※反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで
リスクを最小化しようとする開発手法

 

■STEP1:イテレーション初期段階でのリスク抽出
イテレーションの初期段階でミーティングを実施し
リリース予定の新規機能、機能改修のリリースによるリスクの抽出を行います。
例として新たに「顧客検索機能を実装する」機能をリリースする場合のリスクを

以下に記載しました。
 

プロジェクトリスク
まだ機能仕様書がない
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある
プロダクトリスク
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある
共有モジュールに修正が入るため、元々ある他の検索機能(商品データ、店舗)への影響がある
顧客数が多い場合、検索結果が表示されるまで時間がかかる可能性がある
検索テキストボックス新規追加の影響による他UIの使用性の低下

 

企画、エンジニア、QAのステークホルダ間でミーティングを実施し多角的に抽出するポイント。
例えば内部的な影響範囲などはエンジニアにヒアリングをかけないとわからないためテスト実施漏れにつながりやすい。
また各リスクに優先順位をつけることも忘れない。

 

■STEP2:対策の立案
次にリスクに対して施策を立案します。

これもステークホルダ間でレビューをした上で合意を得る必要がある。
抽出したリスクに対しの対策例を赤字で記載しました。

 

プロジェクトリスク

対策

(プロジェクトリスク)

まだ機能仕様書がない ・エンジニア、QAにデッドラインを確認したうえで担当者に仕様書の作成依頼を出す。
・作成する時間がない場合、仕様共有ミーティングを設定する。
・それぞれ締め切りを設け、スケジュール、進捗管理を必ず行う
別案件と業務が重なるためリソースの確保が必要、網羅性のあるテストができない可能性がある 他案件とリソースの調整を実施する
プロダクトリスク

対策

(プロダクトリスク)

共有モジュールに修正が入るため、元々ある他の検索機能(商品データ、店舗)への影響がある クリティカルなバグの流出やデグレードの発生を抑止するため、商品検索、店舗検索の機能テストもスコープに含める
顧客数が多い場合、検索結果が表示されるまで時間がかかり、サービスの正常利用ができなくなる可能性がある 検索処理の性能テストを実施する(目標速度はエンジニアと別途相談)
検索テキストボックス新規追加の影響による他UIの使用性の低下 運用上他機能の使用性が担保されているかUIテストを実施する

 

プロダクトリスクはテスト設計、実行フェーズに落とし込み
プロジェクトリスクは初期段階でつぶす必要があるため締切日を設定しています。
 

簡単なステップを工程に作りこんだだけですが
以前に比べ、テストの抜け漏れ(本番障害流出)が減少し
効率のよい品質の積み上げの実現を肌で感じています。
今後もPDCAしながら最適化を目指します。

| QMD Editors | - | - | pookmark |