DevQA （開発とQAからのテスト）

2018-03-23DevQA, テスト, マネージメント

テスト専門企業での事例から

・年間100件前後
・常時230人がテストにあたり、繁忙期にはアウトソースで100人。
・年間約17-8万件バグ発見

従来型テスト

従来型テストとは、

1.企画
↓
2.開発
↓
3.デバッグ

というフローの中でプロダクトの最後の工程でテストを実施するもの。
10年前は従来型の方法でやっていたがよくある問題が起こっていた。

・残業、休日出勤などデスマーチが常態化
・それでもチェック漏れが発生する
・(開発遅延 & 納期短めなど)開始の時点で終わらないことがわかる
・テストチームは動けるので始められるけどまだ機能未実装で開始できない
・仕様変更で再チェック
・仕様書がそもそも無い

という傾向がみられる。
これらを改善するために上流や開発チームに納期を守るようにお願いすればよいのか？
仕様書を作ってもらうようにお願いすればよいのか？
要件を変更しないようにお願いすればよいかのか？

そうではない。
根本は

・ハードの進化
・追加コンテンツ
・コンテンツのボリューム
・機能やシステムの複雑化

であり、開発側も手が回らない状況。

DevQA

ではデバッグ側で対応しよう。
できることは？？
近年では下記のフローに変わっている、

1.企画
↓
2.開発 + デバッグプランニング、プレデバッグ、開発補助
↓
3.本格デバッグ

デバッグプランニング

開発初期段階からデバッグを計画する。

・デバッグモードの追加提案
・余力があれば開発に常駐
・本格デバッグの計画、リスト作成
・デバッグの観点から仕様検討

プレデバッグ

小規模で最小限なデバッグを実施する。
・最小限とはクラッシュバグなど初期対応可能なもの
・バグの量や傾向を確認
・変更できるうちにモニターも実施
・その他潜在的なものを認識する

開発補助

・仕様書の作成
・デバッグ用資料作成
・パラメーター調整
・文言、画面設計
・テスト用スクリプト
・簡単な機能実装
・本格デバッグ時の窓口代行

本格デバッグ

従来の最後のテストを実施する。
・プランニング結果に応じて人員を増減
・最大投入目安は要件の9割の機能が実装されたとき

いつから開始するのがよいか

・要件のコアとなるものが実装されたタイミング
・断片的でもよい
・仕様書がそろっていなくてもよい

大規模プロダクト(開発者50人 80日)

→本格デバッグの3～6か月前

中規模プロダクト(開発者50人未満 80日未満)

→本格デバッグの1～2か月前

小規模プロダクト(開発者10人未満 20日)

→本格デバッグの2～3週前

DevQAの本当の狙いは

・開発者にしかできないことに集中してもらいたい
・デバッグチームのリソースの効率化
・コストは人員を計画的に分散させるので同等か従来以下になる

バグ報告を最適化する

報告内容を開発者間で共有する。
・報告先
・カテゴリ
・タグ
・テンプレ
・調査状況の報告

デバッグのオーダーメイド

報告の量が多いなら中断してもらうのがよい。
バグリストの修正を開発者が一括でやるのか個別でやるのかのスタイルは
デバッグチームは判断しないし、判断させない。

・バグ以外の情報(操作感や感想など)がほしいときはリクエストする。
・ほっとくとなにもいわない
・開発者は感想も言わないでくれという人はいない
・我々は感想についても議論いっぱいしてる

品質の見極め

・完了などのステータスやパーセンテージに縛られない
・テスターがどう感じているか
・「イレギュラーパターンでなければ大丈夫」とか「＊＊バグが無くなれば終わる」など具体的なコメントで
・終盤に基本的なバグが出てくるなどした場合デバッグチームの認識を確認する
→見逃した経緯の検討、再チェックの検討
・バグ発見に必要な情報が提供されていたから双方で振り返り必要なら情報共有を見直す

納期までにすべてのバグを修正できない場合

・修正判断同様にコントロールする
・ユーザー体験を損ねない軽微なバグ報告の終了を検討
・開発者がバグを修正するとデバッグチームは報告を求められていると判断する
・開発者にはすべて探そうとせず大事な仕様を協議の上ユーザー体験を重視してもらう
・マネージャーやリーダーはバグリストを完遂させたがる

まとめ

・従来型もDevQAもデバッグと開発が一体になれば多くの課題は解決できる
・開発とデバッグが離れていても目的を共有できれば課題解決可能
・プロダクトを横ぐしでみているデバッグチームもいる