タイトルはUVERworldの「在るべき形」を聞いていたらこうなりました。影響されやすいタイプ。
お仕事でテストの品質分析をして報告書を書く、ということを始めてさせてもらったので、やってみて感じたこととかを書きます。
品質分析のセオリー
-
定量分析⇒定性分析の順で分析
まずは確実に出せる数字を見て、それを根拠に定性的に問題の有無を判断していきます。異常な数値が出ているものをピックアップして深堀りしていき、問題の有無を調査します。 -
ステップ数は厳密な数字が出せるものではない
ステップ数をカウントするツールによってばらつきがあるし、空行を含めるとかコメントを含めるとかによっても変化します。
また共通的な部品のステップ数をどう扱うかによっても変わってくるので、完璧に数字を出すのは、よほど事前の準備をしておかないと不可能。
規模感が把握できれば、正確さはおおよそで問題ないです。
自分は実行ステップ数でカウントしているが、それに限らず何らかの一定の基準で算出していればそれでいいと思っています。
算出の基準があれば、他と比べて異常なテスト密度、バグ密度の機能を素直に「怪しい」と言えるようになります。 -
ソースファイル⇔機能のステップ数の振り分け
機能へのステップ数の振り分けは、機能ごとにソースの正しい役割分担ができていれば、そんなに苦労しない気がします。
自分が担当している案件は、かなりレガシー&フレームワークなし&設計思想もよくわからないって感じなので、これでかなり苦労しました。手作業で集計してコミットログを見ながら適度に割り振るというパワープレイをおよそ4時間も。。。
そもそも、ステップ数を基準に品質を判定する作業には、批判が多い(そんな単純化しても難易度が違いすぎて根拠のある数字になるわけがないetc...)。
なおさら、ステップ数にこだわりすぎるのは良くない。というかそこにこだわる意味はあまりありません。
あくまで客観的事実から取得できる情報(テスト密度、バグ密度など)は、根拠にはなるが品質を証明するまでの力はありません。この値を軸に、しっかり問題を洗い出し、(テスト仕様書などを)目で見る、(テスト担当者の声を)耳で聞くなどして、品質を証明していく作業が重要です。
そんな定性的な分析ほど経験や知見、勘所が重要に。まだまだ精進しなければ。。。
※PMからは定性分析良くできてるって褒められた、嬉しい。。。！
指標値と定量⇔定性分析のつながり
テスト密度
テスト密度(件/KS) = テスト項目数(件) / ステップ数(KS)
対象のステップ数あたりのテスト項目数を割合として算出します。
バグ密度
バグ密度(件/KS) = バグ検出数(件) / ステップ数(KS)
対象のステップ数あたりのバグ検出数を割合として算出します。
これら指標値の評価には、水準となる値が必要です。
結合テスト以降のフェーズであれば、IPAのソフトウェア白書に載っている数値が使えます。
単体テストは、公式な水準値というものはないと思う。企業ごとに内部で持っているものを使うような感じかな？
続いて、指標値の解釈の仕方も簡単に書きます。
-
テスト密度が高く、バグ密度も高い場合
単純にバグが多い状態である可能性が高いです。設計、製造の品質面を疑う必要があります。 -
テスト密度が低く、バグ密度が高い場合
テストが不十分なのにバグが多いということは、十分なテストをしたらさらに大量のバグが検出されるかもしれません。
かなりマズい状態です。早急に原因を突き止めましょう。 -
テスト密度が高く、バグ密度が低い場合
高品質の状態であるか、テストの観点がずれているかのパターンが考えられます。実施されたテストの網羅性を確認しましょう。
十分にパターンを網羅したテストを実施してバグ密度が低いのであれば、高品質であると結論付けて問題ないです。 -
テスト密度が低く、バグ密度も低い場合
単純にテストが足りていない状態である可能性が高いです。十分なテストを実施させてから、再度品質を判定しましょう。
品質分析の観点から見た「こんなテストはいやだ」
懐かしいネタをオマージュしていきます。
-
テストの粒度のばらつきが激しい
担当者によってテストの粒度がバラバラになると、何が正しいのかわからなくなって全体的に深堀りしなくちゃいけなくて大変。プロジェクト内でテストフェーズごとの観点が共有されておらず、個人の知識、経験にゆだねられてしまうことなどが原因として考えられます。
テストを作るときにマトリクスを作るが、このマトリクスが人によってやっていることがバラバラ(よもやマトリクスなしでケースを作っている担当者もいた)。モデルを見せるなりマトリクスを作った段階でレビューをすることで、この段階から属人性を排除していかなければいけない。 -
検出したバグの詳細を担当者しか知らない
テストのマトリクスであったり、障害一覧であったり、もちろんテスト仕様書も、テストをしている自分だけがわかればいいというものではありません。読み手に情報が過不足なく伝わるように資料の情報を記入する必要があります。これをおざなりにすると、後に品質分析の際にはバグの内容までチェックされることがあるので、そこで「何だこれは？」となってしまいます。問い詰められちゃうかもね。
ちゃんと情報が伝わるように資料が書けないのであれば、早いフェーズからでもエビデンスの取得を省かないほうがいいです。
何も情報が残っていないよりは、画面キャプチャが残っていたほうがまだ事象の確認ができます。(取る側も見る側もめんどくさいけど) -
担当者によって品質にばらつきがある
担当者の熟練度によって製造段階での品質に違いがあるというのはまあわかるが、テストの密度なんかはばらついてはいけないと思います。
「仕方ない」を乗り越えて、プロジェクト全体としての品質の向上を目指していく必要があります。属人化してはいけません。
⇒たとえば、熟練者が若手とペアとなり、品質面のサポートをする関係を組む(ライトなペアプログラミング的な)。熟練者同士でテストの粒度などについて合意を取り、ペアの若手にその意図を説明して、テストの序盤には多めにレビューを実施する。
テストをする側として意識しておきたいこと
- マトリクスを作った段階で周囲と粒度を合わせる。レビューを受けたり、軽い相談のレベルでも誰かにそのマトリクスを見せる。
- 文章を書くときは、伝わりやすく簡潔に、情報が漏れなくダブりなく伝達できるように書く。そして客観的に振り返る。
- おおよその自分の担当した機能のステップ数を把握し、テスト密度、バグ密度などを自分で評価する癖をつけておく。
標準的な指標値を控えておき、それと照らし合わせて、「自分、テスト足りてなくない？」とか「ちょっとバグ出すぎじゃない？」とかの視点でテストができるようにしておく。 - 障害一覧は品質についての情報の宝庫にできるように、バグが出たらすぐに、ありありと情報を書いていこう。原因の区分などはしっかり考えて、最適なものを選択するようにしよう。適当にしない！
感じたことを感じたままに書いてみました。駄文もいいところ。
これからもこんな観点を持ち続けながら、テスト頑張っていこうと思います。