先週行ってきたソフトウェアテスト勉強会の感想。
今回はテスト技法ではなく、メトリクスの分析。
やってみた感想としては、これだけのデータがあっても、数字見ただけでは実際のところは分からないもんだな、というのが大きな感想。
自分が仕事でやったことあるのは、自分が担当するプロジェクトで、メンバーも知ってて、それぞれのメンバーの作成した設計書やソースを見ているというバックボーンがある上でメトリクス分析してたので、それなりの対策が出来てた(と思う)けど、プロジェクトの状況も分からなければメンバーも分からないという状況での分析だと、仮説は立てても推測にしかならないな、という風に感じた。
とは書いてみたものの、まずい点はそれなりに気づけるわけで、自分が気になった点を列挙してみる。
- 機能テストで出たバグをシステムテスト期間中に修正しているものがあるけど、修正部分に対する機能テスト、システムテストは出来ているのか？
- 5/7～5/10は消化した試験数の割にはバグが１件も検出されてないが、進捗遅れ挽回のために、仕様よく分かってない人投入してテストさせるとかしてないか？
- 試験外で見つかったバグが多い機能(特に沸騰機能)は試験項目の抽出には問題なかったのか？
- バグのオープン日が長い機能の修正に時間掛かった理由は？大幅な改修が必要だったのであれば機能テスト、システムテストのやり直しが必要になるのでは？
- システムテストで見つかったバグに、機能テストレベルのバグが含まれていないか確認した方がよいのでは？(機能テストの抽出が十分に行われているかの確認のため)
色々と怪しいところはあるものの、机上分析結果なので、実際に問題なのかは分からない。
そもそも分析した数値がどれくらい正しいものなのかも分からない。今回の演習のメトリクスも、休日出勤を誤魔化と思われる数値だったし。
自分の経験としても、炎上してるプロジェクトほどメトリクスの数値を誤魔化したり適当に付けてることが多い気がする。そもそも取ってないところもあるし。このあたりは、問題が発生してからメトリクス確認するんじゃなく、小まめに問題がないかをチェックしていく必要があるんだろうと思う。
勉強会の中で@nemorineさんも言ってたけど、出来る限り、実際の現場に足を運んで状況を確認した方がいいんだろうな。
メトリクスって、取得するデータが増えるほど現場には負担になる。最近は短納期の開発やアジャイルな開発が増えてきていて、あれもこれも取ってると、メトリクス取得の負荷が大きすぎる。
なので、開発どんなメトリクスを取れば品質確保出来るんだろうなーと思ってたところに、ちょうどよいイベントが。
アジャイル×テスト
まだ空きがあるようなので、興味がある方はどうぞー。
