はじめに
この記事は、12月のアドベントカレンダーに向けて1件くらい寄稿してほしいと言われて書きました。提出したら、早く仕上がったので開発者ブログに使うと言われました。12月が近付いてきたら「あれ？アドベントカレンダーの記事お願いしましたよね？」って言われるのだと思います。こういう交渉術をフット・イン・ザ・ドア・テクニックと言います。悪用していきましょう。
私は現在『弥生会計オンライン』『やよいの青色申告/白色申告オンライン』チームのQL（QualityLeader）を務めさせていただいています。私はプログラマー出身なので、品質保証については日々勉強している状況です。よりよい手法を取り入れられるところから取り入れて、仕事を楽にしていっています。
今回は、会計OL/青白OLのバージョン2.8.1（令和2年分確定申告対応）で取り入れた、テストマトリックスについて紹介いたします。
テストマトリックスとは
探索的テストの弱点を補う探索的テストで、以下のようなマトリックスを作成することにより実施します。
縦軸がテスト対象（機能）、横軸がテスト観点です。
凡例は自由に決めて構いません。画像の例では、「○：バグは発見されなかった」「×：障害報告済」「－：テスト対象なし」となっていますが、最近では次の探索箇所を決定する材料として「件数」を記載するようにしています。
導入した経緯
担当プロジェクトで終盤に実施した統合テストにおいて、複数のバグが検出されました。品質に懸念が生じ、ピンポイントなバグ修正だけでなく、網羅的な再テストを行う必要に迫られました。もちろん、リリース日は決まっている中で。
それまでプロジェクトでは、該当機能の結合テストをもう一巡やり直す（リグレッションテスト）という対策が一般的でした。ところが、旧バージョン2.7.1（令和元年分確定申告対応）で行ったリグレッションテストは、工数がかかり過ぎる上に効果が上がらなかったという実績が残っていました。そもそも、結合テストをすり抜けて統合テストの網にかかったバグなので、もう一巡やり直してどの程度効果があるのかという疑問がありました。
結合テストをすべてメンテナンスし、もう一巡やり直すのが最も正式なのですが、前述の通り既にプロジェクト終盤のためその時間はありませんでした。そこで、短時間で網羅的にテストできる手法として、テストマトリックスを使った探索的テストを導入しました。
手順
- 縦軸（テスト対象）と横軸（テスト観点）を完成させる
- 横軸の手順と期待結果を明確にする
例： [保存]
目的 ：（バグの識別子）の類似バグ確認
手順 ：入力項目を可能な限り入力し、[保存]ボタンを押す
期待結果：入力したとおりに保存されていること - テストを実施し、凡例に従って結果を書き込む
- ×のマスに着目し、次の横軸を追加する
縦軸で×が多ければ類似障害を、横軸で×が多ければその機能を疑う
新たな観点が見つかった場合、単純に横軸に追加 - 類似障害混入の疑い、新たな観点が無くなるまで、(2)～(4)を繰り返す
結果
2.8.1（令和2年分確定申告対応）での実施結果としては、23件のバグ報告が挙がりました。内訳としては、19件がソフトウェア障害、2件が設計書誤り、2件がテスト結果判定ミスでした。
テスト専門のエンジニアは統合テストにかかりきりだったので、製造工程を終えたエンジニア10名に実施していただきました。前述のとおり期限が迫っている中で、人海戦術での実施です。おそらくテストマトリックスなしでは、誰がどこまでやったのか混乱したと思いますが、スムーズに完了することができました。
該当機能の結合テストをもう一巡実施するとしたらざっと700～800時間程度かかる見積もりでしたが、150時間程度で必要なテストを終えることができました。テスト準備は、テスト観点とテスト対象を洗い出して手順を明確にするだけですので、無視していいくらいのオーバーヘッドです。早いだけでなく、十分にバグを検出することができ、安心してリリースできました。
まとめ
テストマトリックスについて紹介いたしました。
担当プロジェクトでは、終盤においてバグを潰し切るために使っています。まずTDDによるテストを行います。そこで漏れてしまったテストは、成果物変更によってテストスクリプトを修正し、再テストを行います。その上で、スクリプト作成からやり直すのはコストに見合わない、類似バグを網羅的に探したい、そんなときにテストマトリックスを使うようにしています。
感想としては、とても便利です。
探索的テストはエビデンスが残らず、第三者にも説明しづらいですが、テストマトリックスはそれを解決してくれます。導入コストも学習コストも限りなくゼロです。良い技を覚えたなぁと思う一方、便利だからとなんでもかんでもスクリプトを省略しないように肝に銘じているところです。
なお、テストマトリックスばかりを褒めてしまいましたが、テストエンジニアが十分な知識をお持ちの場合、手順を指定しない探索的テストも有効な場合があります。誰も見つけられないバグをなぜか見つける人（いわゆるゴッドハンド系）もいらっしゃるので、そういう方には別途、手順を指定しない探索的テストをお願いするようにしています。
従来の探索的テストとの比較
| 比較内容 | テストマトリックスを用いない 探索的テスト |
テストマトリックスを用いた 探索的テスト |
|---|---|---|
| 属人性 | 実施者によって検出率が大幅に変わる ただのモンキーテストになる場合がある |
実施者に依存しない 観点や再現手順を明確にしているため |
| 網羅性 | 基本的に保証できない。誰がどこまで実施したのか不明 | 実施漏れが無い テストマトリックスがチェックリストの役割を果たすため |
| 再現性 | 偶然により検出した場合、再現できない場合がある | 保証されている 再現手順を明確にしているため |
| 偶然性 | 高い 観点から漏れているバグを見付けることがある |
低い 手順を指定しているため、横道に何かありそうでも打ち切ってしまう |
参考にしたテスト手法
探索的テストを対象とする機械学習(SOM) を利用した進行中プロジェクトにおける探索箇所推測手法 「FaRSeT-# / ファルセットシャープ」の提案
https://www.juse.jp/sqip/library/shousai/?id=481
SONAR Testing 効率と客観性を両立した新たなテスト手法
https://www.juse.jp/sqip/library/shousai/?id=450
「FaRSeT-#」「SONAR Testing」は専用のツールも使用した、より高度なテスト手法なのですが、私のチームではすぐに取り入れられる点を参考にさせていただきました。
