図1

ソフトウェアテストにまつわるよくある疑問　テスト工数はどうやったら減らせる？

Tsuyoshi Yumoto

前々々回、前々回、前回に続いて、2011年にSQiPのサイトで連載してた記事の第四話の再掲です。

t_wadaさんのこのツイートが痛いほど刺さりすぎて泣きそうです。この回のお題は、「テスト工数を減らす」ですが、要は、開発コストを安くしたいってことなんですね。これを「時間をかけても良いからひたすら安くしろ」とかでは世の中が悪い方向に進んでしまい、関わる人たちがみんなハッピーになれないです。

なんなら「テストをしなくても運用の段階でチェックする作業をルーチン業務に入れればテストしなくていいじゃん」とか、そういう信じられないことも起きてたります。その結果として運用の中のルーチン作業を低価格でやらされることになってしまうことになってしまうと、ほんとに精神衛生上よくないです。。。そういう、「そもそもテストをしたくない」って現場には、「逆にもっとテストしてください」って言いたいです。

今回の話は、そうではなくて、テストをちゃんとやってはいるが、余計に工数をかけすぎてる場合に、どう減らすかという話です。この記事はもう8年も前に書いたものですが、今の時代でも全て当てはまると考えています。特にテストマネジメント技術のところで書いたスコープと優先度の関係者間での調整と合意は開発スピードに合わせた速度でテストをしていくためにとても大事だと思っています。

----------------------------------------

1. はじめに


ソフトウェアテストはここ10年の間に多くの専門書籍が出版され、Web媒体やシンポジウムなどでも多くの情報が入手できるようになりました。筆者は、ソフトウェアテストのコンサルティングという仕事を通じて、記事を書いたり講演をさせていただくことがあるのですが、いろいろな方とお話をする機会を得るたびに、ソフトウェアテストに関して似たような質問を受ける事が多くあります。それらの質問は、書籍などに書いてある専門的な質問というより、もっと原点に戻るような質問であることが多くあります。


今コラムではそのような「ソフトウェアテストにまつわるよくある疑問」とそれに対する私の回答を四回に分けて紹介していきたいと思います。最終回は「テスト工数はどうやったら減らせるか？」という質問です。

2. テスト工数はどうやったら減らせるか？


 質問を受ける状況
この質問は、新規の開発ではなく、既存ソフトウェアのバージョンアップで差分のみ開発を行っているプロジェクトの方達から良く受ける質問です。差分を開発しているだけにもかかわらず開発コストが思ったように減らないため、工数の割合を調べていたら、実はそのコストの半分以上がテストであり、テストがボトルネックになっているというのです。開発は差分だけ作ればよいとしても、テストは単純にそうならないのですが、、、

「テストは結局、ソフトウェアにバグがないか、もしくは運用してもよい状態になっているのかを確認しているだけにすぎない。なのに、なぜそんなに工数がかかるのかわからない」とのことです。もっというと、テストにそれほど工数をかけたくないとのことです。

 テスト工数を増減させる要因は四つある
「テスト工数をかけたくない」といっても、まるでテストしないというわけにはいかないでしょう。開発したものが想定通りに出来ているかどうかは、動作させて確認する以外に方法が無いからです。確認をおろそかにするのは手抜きとしかいいようがありません。では、いかにしたら手抜きせずに、かつ工数を余計にかけないでその確認ができるかということを考えないといけません。筆者はテスト工数を増減させる要因は四つあり、それらを改善していくことがテスト工数削減への最も近道だと話しています。以降にその四つについて簡単に触れていきたいと思います。

 工数増減要因（１）：テスト対象ソフトウェアの品質
これは非常に当たり前かもしれませんが重要な要因です。要は、テスト対象となるソフトウェアに不具合がなければテストは一回で済みますが、欠陥があれば修正して再度テストをする必要があるために工数が増えてしまうということです。最初から欠陥が少なくなるように、要件を明確にして影響範囲をの調査をしっかり行ってからコーディングを行うということが重要です。

しかし、開発者にとって初めて経験するタイプのソフトウェアには、作ってみないとわからない（つまり、そこにはプロダクトリスクがある）こともたくさんあります。その場合、テストで欠陥をたたき出すといったことも必要です。欠陥が出ないとしても、しっかり作れていることが確証できます。

あとは、一度欠陥を見つけて直した後に、また作り壊すということをしない工夫が大切です。欠陥を修正していくたびに品質がだんだん作りこまれていき、積み重ねるように品質が確保されていれば問題ありません。工数増になる大きな問題は、一度テストを行って問題なかったと思われた部分に欠陥が入ることです。つまり、いつまでたっても品質の作り込みが積み重なっていかない状態におちいることです。

注釈：直したところがまた壊れる件に関して、ちょうど良いツイートをしたので貼り付けときます。


 工数増減要因（２）：テスト設計技術
テスト設計に関して前回のコラムで触れましたのでそちらを見ていただければと思います。一言でいうと、テスト設計の技術は「的を絞る」技術です。的を絞れないとテスト量が乗算で増加してしまいます。

 工数増加要因（３）：テスト実行技術
テスト実行にも効率よく、手戻りをおこなさないよう行うための技術が必要です。まずは、テスト実行担当者の見落としをどう減らすかです。人間は意識していないと、視界に入っていることでも見落としをします。それは、私たちが人間である以上いたしかたないことです。人間が見落としをしないようにするために、例えば製造業の現場では、「指さし確認」や「声だし確認」といった工夫をしています。また、作業漏れがなくなるように作業順番を見直していき、手戻りを起こさないといった工夫をします。ソフトウェアテストにおいても、「見なければいけないことだけを見る」や「テスト実施順番を最適化させる」ようにする仕掛けや訓練が必要です。

人間の見落としを減らすためには、人間を介在させないで間違いを減らす、つまりテスト実行を自動化する技術を利用する方法もあります。その場合、テストを自動化しやすいソフトウェアを意識して作ることや、自動化のための活用できるように技術を意識してテスト設計を行うなどの工夫が必要になります。（自動化に関しては、小井土さんのコラムがとても的を射た事が書かれているので見ていただければと思います。）

 工数増加要因（４）：テストマネジメント技術
テストマネジメントの技術としては、大きく言って以下の四つが該当します。

・スコープと優先度の関係者間での調整と合意（テスト戦略、テスト計画）
・資産の再利用に関する効率化（構成管理、トレーサビリティ管理）
・バグ発見時のやりとりの効率化（正しい情報のやりとり）
・テスト結果の見える化に関する効率化（モニタリング、報告書作成）

テスト設計技術を身につけたり、自動化を推進したりしてもテスト工数が減らない理由は、実は適切な情報収集が行えていないことに起因している場合が少なくありません。具体的には、テスト状況や欠陥の検出状況の全体像が常に見えるように情報収集と整理をしていないため、テストを進める中でコミュニケーションロスが起きてしまい、状況が見えない不安から本来必要のないところまでテストを行ってしまったり、同じような情報のやりとりを何度も繰り返してしまうといったことが該当します。このような状況になると、どのような手立てを打ってもテストのコストはかさんでいきます。一方、全体像が常に見えるようにするための工夫を怠ると、情報収集や整理の工数、つまりテストマネジメントの工数がかさんでしまい、テスト実行のような本来のテスト業務を圧迫してしまうと言う問題もあります。

3. 最後に

今回の質問の回答は、「テスト工数を削減するには、テスト工数が増加する要因を突き止めて、その要因を改善する」となります。やり方をよくしていき、問題点を取り除き、今までよりも上手にできるようにすることを目指しましょう。単に工数を削減して、仕事の仕方をめちゃめちゃにしてはいけません。

以上で四回にわたった「ソフトウェアテストにまつわる良くある疑問」のコラムは終了となります。このコラムが皆さんの現場の改善のヒントになれば幸いです。


サポートありがとうございます。これをカテにこれからも頑張ります。