皆さんはシステム障害のニュースを耳にしたとき、どのように思われるでしょうか。私はこれまで何度もソフトウェアのテストを行ってきましたが、それでもシステム障害のニュースを聞くとつい「本当にテストしたの？」と思ってしまいます。これは本書の前文に紹介されているエピソードと丁度重なります。そしてその反応は「テストをすれば完璧な製品ができる」という誤解からくるのだと指摘されています。実際、全くテストをせずにリリースされるソフトウェアというのは存在しないでしょう。しかし、テストの結果を正しく使えていないソフトウェアというのはそこそこあるかも知れません。本書はそんなソフトウェアのテストについての誤解を解き、ソフトウェアのテストについて様々な示唆を与える著作です。
本書に何度か出てくるテクニックとして、バグの分類が挙げられます。実際の開発現場ではバグ（障害）をどのように分類するかということがしばしば議論になります。（もっとも何も議論せずに決められているパターンも残念ながら多いです）よくある分類は重要度や優先度でしょう。ところが重要度や優先度はどちらかというと主観的な基準であるため、誰かが統一的な判定を下すのでなければ基準が曖昧になり、せっかくの分類が機能しなくなってしまいます。そこで弊社では本書で薦められているバグレベルによる分類を次のようにアレンジして現場に適用しています。
- レベル0 ・・・他テストを妨害
- レベル1 ・・・業務遂行不可
- レベル2 ・・・作業効率低下
- レベル3 ・・・頻発すれば問題
この分類のメリットは基準がどちらかというと客観的だということです。それでも最初は迷うこともありますが、それぞれどういうケースかということを考えていけば自ずと分類は決まってきます。例えばログのメッセージが不適切というケースでは、障害時の原因究明に余計な時間がかかってしまうということで「作業効率低下」に分類できます。例えばサイズ0のファイルをDBに登録できてしまうというケースでは、通常の操作ではサイズ0のファイルを扱うことがないと考えれば「頻発すれば問題」に分類できます。このバグレベルのおかげで分類作業の効率が上がりました。これは一種の優先度による分類ですが、紛れもなくレベル0のバグは優先して対応すべきものです。極端な話、レベル3のバグであれば状況により対応を見送るという判断もあるでしょう。
本書でも紹介されているように、ソフトウェアの開発に理解がない（あるいは理解があると自認している）管理者や営業担当者が、開発者に対してバグゼロを要求するケースを何度も見てきました。しかし、何がバグであるかが自明なケースもあれば、ビジネス環境に応じてバグの基準は変化することもあり、仮にリリース時点でバグがゼロであったとしても（それもあり得ないのですが）それを将来に亘って保障することはできないのです。本書はテストを担当する技術者のみならず、開発チームに関わる管理者や営業担当者の方にも読んでいただきたい一冊です。
――――
書名：パーフェクトソフトウェア
副題：テストにまつわる幻想
著者：ジェラルド・M・ワインバーグ
発行：日経BP社／2010年5月31日
ISBN：978-4-8222-8429-9
関連記事
プロマネの右腕
プロジェクトマネジメントの支援を行っています。
新サービスの企画を任されたけど どう進めていいか悩んでいる担当者、
部下に新しい企画を任せたけど このままで大丈夫か不安な管理職の方、
以下のサイトをご参照ください。
https://www.crossidea.co.jp/services/right-hand-pmo.html
YouTubeにて動画配信中！
プロジェクトマネジメントのノウハウをYouTubeで配信しています。
ブログと併せてご活用ください。