テスト時の間違った品質分析
ソフトウェア開発における品質分析の手法は色々あれど、それらは確かに評価するために用いる…ものですけど、それは
「プロダクト品質の良し悪し」
を評価するものではありません。
案外そのことを理解せずに活用されている企業やＱＡが多い気がします。まぁ案外私の身の回りにもいるので、気がするというか事実なんですけど。そしてその分析の結果
「基準値内だから問題ない」
という評価の仕方を見ることがあるのですが、そこでまたﾓﾔｯとします。指摘やバグは出てるんだから問題がないわけがないんです。
ゾーン評価法
たとえば次のような方法を用いたとします。
こんな分析手法、ソフトウェア開発業界に長くいると何度か見かけることがある人も多いのではないかと思います。これは「ゾーン評価」「ゾーン分析」と言って作業を実施したボリュームと作業で得られた結果の組み合わせを評価するツールです。
で、多くの人は
ちょっとググれば出てきそうなこんな感じの評価方法を真に受けてそのまま流用しようとしていませんか？
ただ単にツールを活用するだけの人たちの多くはそれで正しいという『根拠』を持ち合わせていないことが多いのではないでしょうか。挙句の果てに
『どこかの誰かがそれでいいって言ったから』
という身も蓋もないプロらしからぬ他責の言い訳を用いてしまう人もいるかも知れません。
『山田くんがそれでいいって言ったからー』
『じゃあ、山田が死ねって言ったらお前は死ぬのか！？』
と嘉門達夫氏に言われてしまいそうです。
あれ、古い？いやまぁ私が小学生の頃のネタだった気もしますけど…小市民大全集だったかな？
ともあれ分析の仕組み自体は悪くありません。上限／下限の値をそれなりに適切に設定できれば、分析の下地は出来上がるでしょう。
問題は手法やその取り扱い方ではないんです。
問題は
「何を評価するために用いるものか」
がわかっていないまま使ってしまっていることなんです。医薬品に対して言うなら、用法・用量は正しく取り扱えているのに何に効く薬かわかっていないけどとにかく飲む…そんな感じです。そう、目的を正しく理解していないがゆえにまったく意味や価値を為さないことに問題があるのです。
たとえば、結果として上限／下限の基準値内に収まったとしましょう。
しかしバグはバグとして出ています。基準値内とはいえ、間違いなくバグは発生しています。バグが発生しているのに「品質は良い」と評価する理由は何ですか？
「もちろん、発生したバグはちゃんと対処するよ！」
という人もいるでしょう。実際ほぼ100%そう回答が返ってきそうです。そりゃまぁそうですよね。バグが未消化のまま残っていたら品質もへったくれもありませんから。
ではそのバグの内、半数以上が前工程で発見すべきバグだったらどうでしょうか。当該工程のテスト観点で発見できたのは半数以下。本来であれば前工程で発見していなければならなかったのに、その観点／ケースが抜け漏れしていて当該工程になるまで検出できなかった…というパターンです。
それは本当に『品質がいい』と言えるのでしょうか。
私なら、まず前工程の際に行われた品質評価を疑います。少なくともこの分析を用いたところで前工程では品質を正しく評価しきれず、次工程に進むまでまともに検出することもできなかったことのですから、そこは真摯に受け止める必要があります。
もし、前工程と同じメンバーが当該工程でもテスト観点やテストケースを作っているとすると同じ認識を持ったまま進めているでしょうから、同じように抜け漏れが発生している可能性を疑いますし、信用するにはあまりにも不安要素が大きすぎます。
あるいはその前工程で検出するべきバグは、似たようなアーキテクチャがいくつかの機能に分散されていて同じようにあちこちで見落とされており、潜在的にまだまだ同じバグが残っている可能性だってあります。検出されたバグだけ解決すればそれで終わりということにはならない…可能性だってあるわけです。
そう。
本来発見すべきタイミングで発見できずに見落としや抜け漏れとなった問題に対しては『類似』の潜在調査やその改修も当然必要になってくるのです。ひょっとしたらそうしてこれまで検出できなかったバグが10匹も出てくるかもしれません。それでもこのゾーン分析の結果だけをもって『プロダクトの品質が良い』と言えるのでしょうか。
そもそもゾーン評価は
「十分やれているか？」
「傾向から可能性が見えてこないか？」
を評価し、テストの充足度やテスト内容の傾向を非常におおざっぱに分析するためのもので、いきなりプロダクト品質を評価するためのものではありません。それに品質についても「その可能性がある」「その疑いがある」というだけで、これだけで何かが具体的にわかるというものじゃないんです。
これで大雑把な傾向を特定したうえで、その判断が正しかったかどうかを定性的に調べ尽くしていかなければ、何一つ確かなことは言えないようになっています。というか「定量的」な測定だけで詳細なことがわかる…ということは決してありません。分類や傾向などといったグルーピングをおこない、一つひとつを詳細化しなくなった時点で一段階～数段階抽象化しているのですから当然です。
さらにいえば、
このようにテストの結果、バグ密度が低く「品質良好？」のエリアに位置することができたとしましょう。
それは本当に『品質がいい』と言えるのでしょうか？
JSTQBの提唱するソフトウェアテストの７原則をご存じの方であればわかるかも知れませんが
ソフトウェアテストにおいては
「欠陥があることしか示せない」
「バグゼロの落とし穴」
というものがあります。バグが無いからと言って品質が高いと断じることはできません。そもそもテストケースとして抜け漏れがあり、不足している状態であれば、現存しているテストケースだけを消化してバグの密度が少なかったとしてもイコール「品質が高い」ということになりえないからです。あくまで
「実施したテストケースの範囲内においてのみバグが見つけられない」
というだけで、テストケースの不足分を補完し網羅しようとしない限り、本当にプロダクトの品質が良いことを証明するのは不可能です。
つまり、こうした分析を用いたところで、
プロダクトそれ自体の品質を評価することはできない
というのが結論です。「良好？」と書いていますが実際にはそれ以前の問題です。目先のバグ密度が低いというだけで、良好かどうかを測る根拠には１㍉もなりえません。逆に目を曇らせてしまうだけです。
まずはこのことを大前提として覚えておいて下さい。
この大前提に立てない人はこうした分析法を用いるべきではありません。思い込みによって濫用し、周囲を巻き込み、騙し、より大きな問題を誘発してしまうだけです。おそらくはほんの少し定性的な部分に対して質疑を受けた時点で何一つ事実を説明できず、個人的な意見ばかりになってしまって、相手の信用を失うことになるでしょう。
ここで『良好？』になっているのは、
「品質が良い可能性がゼロじゃない」
というだけで、その先に「品質が良い可能性があるのはなぜ？」「問題が無いと思われるのはなぜ？」という問いかけが待っています。これを論理的に証明するか、証拠（エビデンス）を提示するかしないと何の信憑性も得られません。というか信用を得る資格がありません。
そもそもモジュール構造のあり方をうまく調整すれば、規模に対してテスト密度をもっと下げるのはそんなに難しいことではありません。たとえばPOA（プロセス中心アプローチ）的なモジュール構造と、OOA（オブジェクト中心アプローチ）的なモジュール構造では、全く同じ機能や処理を構築したとしても実装規模はまったく異なります（（共通部品化できるものがなければ）OOAの方が規模が大きくなるはずで、しかもテストケース数はグッと減ることになるでしょう）。
同様にバグ密度でも似たようなことが言えるのは、先ほどの「どの工程で発見するべきバグなのか？」という一つの観点を加えただけで破綻するのはお判りいただけたかと思います。
結果、このゾーン分析だけしか用いなかった場合の分析結果からわかることといえば
「みんなと一緒くらいにテストしてるっぽいし
みんなと一緒くらいのバグ数になっているらしい」
というそれだけでしかありません。
とても企業や顧客にドヤ顔で説明できる報告内容ではありませんね。どんなに言葉を駆使しても、端的に言えばその程度にしかなりません。
私に言わせれば
「みんなって誰やねん」
「右に倣えしてたら、勝手に品質が上がるのか」
と言いたくなってしまいます。
そもそも発生したバグの対処法は妥当なのか
どんなにテスト密度やバグ密度からなんとかプロダクト品質の妥当性を導き出そうとしても無理なものは無理です。これはテスト工程自体の品質の妥当性に対しても同様です。
バグが０件で無いのであれば、そのバグの対処法一つひとつにも品質が問われます。
・バグの修正方法は正しいか
・その修正時の確認方法やケースパターンに不足はないか
・修正時の影響範囲は確認できているか
・同質の類似バグがまだ残っていないか
最低でもこの程度は確認しなければなりませんし、それらを評価しなければプロダクト全体の品質を語ることなんて不可能です。
さらに、その内容が前工程で発見するべきバグだったとすれば、
・なぜ前工程では抜け漏れさせてしまったのか
・他に抜け漏れさせてそうな観点漏れの可能性はないのか
と言った不信感の解消まで何とかしなくてはなりません。もうとてもじゃありませんけどゾーン分析だけでどうにかなるものではありませんよね。
ちなみにバグに対して「発見すべき工程はどこか？」を特定するのは難しくありません。過去の各工程で何をやってきたかにもよりますが端的に言えば
「修正しなければならない成果物のなかで最も古い工程のもの」
が作られた工程が本来の『発見すべき工程』です。
たとえば、バグによって
・ソースコード
・詳細設計書
を修正したのであれば、本来発見すべき工程は「詳細設計」です。詳細設計のレビュー時に検出できなかったことが一番の要因です。ここで誤った設計書になっているから、単体テストでも検出できなかった可能性が高いからです。
仮に設計工程でロクにレビューをしなかった…というプロジェクトも残念ながらあると思います。そんな時には「その設計書の検証をどのテスト工程で行うべく計画されているか」という観点によって、発見すべき工程をいずれかのテスト工程に紐づければいいのです。
一般的なＶ字モデルを前提にするなら詳細設計と対になる検証工程は「単体テスト」でしょうから、単体テストで検出できていなければならない…ということになります。まぁ設計のレビューもまともに行えていないなら、単体テストのテストケース内容の妥当性を評価することも困難になりますので、抜け漏れが出やすいのは間違いないと思います。その場合は「単体相当でありながら」結合テストが対象になることも視野に入れなければいけません。
ですが、後工程にずらせばずらすほど後々の手戻りやインパクトは大きくなっていきますので、レビューされない設計書…なんてプロセス／プロジェクトは作らないようにしておかないと後で痛い目に逢っても自業自得であることだけは覚悟しておいた方がいいでしょう。
テストの品質はテスト結果からは得られない
どんな手法のどんなテスト内容であっても、その結果やエビデンスから評価できるのは、設計や実装など作りこみ工程の品質です。
テスト工程自体の品質を問うのは
テストケースの網羅性（含 データパターン）
によってのみ実現可能です。テストケースさえ網羅されていればそのテストがすべて実施され、発生したバグがすべて正しく解消されていれば真の意味でプロダクトの品質は「完璧」であると言えるでしょう。
どんなに設計や実装時にバグを作りこんでいたとしても、テスト工程自体の品質が高ければ、当該テスト工程で検出するべくして用意された観点に関しては後工程に持ち越すことが無くなります。
であれば、設計や実装時に作りこまれたバグの件数や密度なんて、どうでもいい話になるのではないでしょうか。どんなに少なくても、どんなに多くても、それらをひっくるめて『網羅』されているわけですから何も心配する必要はなくなるはずです。
そこで本当の意味でテストの品質を問うのであれば、テスト結果から得られる定量的なバグ件数などを用いるのではなく、テストを実施するためのテストケースをいかにして「網羅できている」と言える状態にまで昇華させられるかにかかってくることになるわけです。
テスト実施自体は、あくまでその理想を「論理」的なもののままにしておくのではなく「物理」的に証明しようとしているにすぎません。
そのことに意識を向けず、テストの観点に対して充足しているか、網羅できているかもよくわかっていないままただ盲目的に実施したテスト結果を用いて実績に対し図や表、グラフで説明したところで何の品質も保証することはできないでしょう。
だから、私は「テストケースの網羅性」にいつも焦点をあてます。
まだフレームワークのようなものまでできてはいませんが、少なくともベースとなる仕組みは徐々に構築デキていますし、論理的にプロセス自体は説明ができます。あとは実践の中でブラッシュアップしていくだけかなー？と考えてはいますが…そんな役割をきちんと実施する日は来るのでしょうか。
片手間にできるようなものでもありませんし、きちんとそれだけに集中する必要もありますし、PoCのような検証も必要になってくると思います。
ヒントは「データの品質（ISO/IEC 25012）」の概念を応用すること。
ここに超論理的なアプローチを用いることで８割近い品質保証方法は確立できると思います。残り（利用時の品質関係）はどうしても超属人的になってしまいます。論理だけではどうしても証明しきれないテスト観点というものがあるからなわけですが、それでも一般的な「単体テスト」「結合テスト」「システムテスト（の一部）」相当の品質はほぼすべて網羅することができるのではないかと考えています。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。