FORTRANから始まって41年（８）

テスト設計能力

今までの41年間を振り返って、十分に学習して実践できていないと思うのは、ソフトウェアのテスト設計です。もちろん、テスト駆動開発を行っていますので、テストコードを書いていないということはありません。

ソフトウェアのテスト設計は、品質工学的な視点を持って行う必要があるのですが、あまりきちんと学んで実践して来なかったというのが正直なところです。組み合わせ爆発を回避して効率よくテストを行うということに関しては、Hayst法がありますが、それもきちんと経験・実践することなく今日に至っています。

ソフトウェアテストHAYST法入門 品質と生産性がアップする直交表の使い方

• 作者: 吉澤 正孝/秋山浩一/仙石太郎
• 出版社/メーカー: 日科技連出版社
• 発売日: 2007/07/26
• メディア: 単行本

書いたコードの品質を担保するために、経験のある先輩にレビューしてもらうように、テスト設計もきちんと経験がある専門家に指導を受けるのが、自己流になるのを避けるのによいと思っています。

10年以上前のことですが、当時マルチスレッドプログラミングによる複雑なシステムをテスト駆動開発で開発していたのですが、テスト設計として正しいのか、何か問題がないかという視点で助言をもらうために、私が部門長だった開発部で、秋山さん（上記の本の共著者）に指導を受けたことがあります。そして、行っているテストを説明したら、テスト設計が間違っているし、使うべきテスト設計手法が違っているという指摘を受けたことがあります。そして、指導に従ってテストを修正したらバグが見つかったという経験があります。

障害分析

テスト設計に加えて、障害を分析する活動も重要です。障害ごとなぜ発生したのかを分析して、どのような原因で発生している障害が多いかを整理して、対策を検討する必要があります。

障害分析というと、プロジェクトが終わった後に、振り返り的に行う組織が多いと思います。しかし、そのような障害分析では、効果的な改善はできないことが多いです。主な理由は以下の通りです。

• 障害の真の原因を知るには、障害対応した担当者からヒアリングする必要があるが、以前に行った障害対応なので、担当者が思い出せないことがある。
• 担当者は次のプロジェクトにすでに従事しており、障害分析のために時間を割り当てることができない。

障害分析は、開発中に始める必要があります。そして、開発組織（あるいは、開発チームやグループ）自身が行う必要があります。そうでなければ、上記の問題で、きちんとした障害分析ができないし、対策の検討を行い、開発中に対策の実施までを行って効果を見るというサイクルを回すことができません。障害分析は、プロジェクトの最初から行う必要はありません。障害がある程度の数、発生してから始めてよいです。そして、実際に分析を始めると、分析に必要な情報が不足していることに気づくことがあり、次に障害が発生したときに追加の情報を収集して分析に加えるというサイクルになります。

残念ながらこのように障害分析を行っている開発組織は少ないと思います。障害分析もきちんとできるようになるまでは、それなりのレビューや指導を受ける必要があります。幸い、私自身は、10年以上前に、上記の書籍の共著者である吉澤さん（現在は、品質工学会の副会長）から指導を受ける機会があり、私が部門長をしていた開発部で一年ほど指導を受けていました。