>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

これまでテスト設計をしてこなかった組織がテスト設計をはじめると、なぜ一時的にバグが出せなくなるのか?

f:id:shinsuku:20140106102402p:plain

 わかります。これまったく同じ体験を7年ぐらい前にしました。もちろん「テスト設計」と自信を持っていえるような大層なものでは無かったのですが、それでも一応考えて、こうかな?こうかな?と仕上げたものでいざテストを実行!するとまあこれが出ない。びっくりするほどバグが出なくなり、自分の方針は間違っていたのかと懊悩したことがあります。もしかしたら同じ境遇にいるかもしれない新米テストマネージャのみなさまへ、そのカラクリをお届けいたします。

 端的には

1.テストを作る、行為自体が既にテストになっている
2.人間が書かれていることしかやらなくなった

からです。ほぼショートアンサーの裏返しですが、この現象が起こる現場はおそらく下記のような前提にあるはずです。

1.これまでテストケースが事前に準備されたことが無い
2.歩く製品知識かつ、ものすごく頭のいい、または観察力のあるテスターがいる

詳しく見て行きましょう。

1.これまでテストケースが事前に準備されたことが無い

 特別なテスト技法を活用しなくても、例えCPM (コピー・アンド・ペースト・アンド・モディファイ:要するに仕様書から仕様をコピーして、語尾を「〜すること」に変更するだけ) 法オンリーであったとしても、仕様書を別の文書で表す課程で「この仕様はあの仕様と衝突しないだろうか?」「この仕様記述は明らかにxxという標準や規約に違反している」という気付きが生まれます。この気付きを開発チームに確認するとその時点で誤りに気づき、ソフトウェアが正しく実装されます。このとき、テスト仕様書を変更せずにそのままテストを実行すると件のテストケースの結果は概ねPASSEDとなるはずです。バグ、出ませんね

 ただ、これでさえ課題管理システムが整備されていない組織であれば、うっかり修正するのを忘れていたというどうしようもないミステイクを検出することができますが、ともあれ仕様書のレベルが低ければ低いほど、テストを準備するだけで多数のバグが発見されるはずです。これは、品質コストの概念からすると凄まじいコスト対効果となります。なりますが、どう考えてもレベルが低すぎるところで活躍している、いうなればレベル10の勇者がスライムの群れを相手に無双している状態に過ぎません。このような状況にあるテストチームはテストを作るより仕様書の質の改善を手伝ったほうが大局的にはそのグループのためになると思われます。

仕様書 というとどうしても大仰なドキュメントを想像しがちですが、チラシの裏に書かれたログインフロー、ホワイトボードに殴り書かれた権限仕様、プロジェクトマネージャがよく覚えている機能仕様 すべて含みます。

 開発チームの成熟度が向上してくると、やはりまた検出率は落ちてくることでしょう。その時こそ、さまざまな網羅の方式を提供してくれるテスト技法や、ターンアラウンドタイムの速度を上げるテスト自動化、はたまたテスト分析の方式自体を変えてみる、など自分たちの方の技術を向上、拡大させることで、また検出率を向上させる。それに応じて開発チームがまた技術力を上げてくる、という正のスパイラルが起こるようになると、あとは放っておいても素晴らしいチームが出来上がると思います。楽しいですね。

2.歩く製品知識かつ、ものすごく頭のいい、または観察力のあるテスターがいる

 ソフトウェアテストの数ある(ありすぎ)分類方法の中に「スクリプトテスト」と「探索的テスト」という分け方があります。前者は(スクリプト:台本を)予め用意してからコトにあたる方針で、後者はテスターが頭の中でテスト設計を随時行う前提でいきなりテストを実行する方針をさします。どちらの方針もテスト分析だけは予め行なっておく事が多いようです。

 「探索的テスト」はテスト対象のリアクションを見ながら次にどんなデータを、あるいはどんな観点をあてて見ようかと考えながらテストを実行していくため、膨大な製品知識はもちろんのこと、そもそもそのソフトウェアがどのような前提で動作しているのか、という下回りの知識、ともすればセキュリティやユーザビリティなどといった非機能要件に列挙される分野の知識も要求される、非常に高度なスキルです。準備するコストがゼロに見えるので一見夢の様なテストと思われがちですが、テストマネジメントの観点から見ると「最初のひとつめのバグを見つける速度は最速だが、どこまで網羅したのか分からない」というレポートを書くときに困る性質を持っています。これをマネジメントする方法もいくつかあるのですがそれはまた別の話。

 閑話休題。なぜ掲題のような性質をもつテスターがいる状態ではじめてテスト設計をすると検出率が落ちるのでしょう。おそらく、テストを準備するという施策を打ち出す前は、製品をポンと渡して「少し見てくれない?」といったオーダーに対し、そのテスターは無意識に前述のような「探索的テスト」を行なっていたはずです。製品がポンと渡される、状況であればテスト分析など夢のまた夢、ということは探索する範囲も「基本的に無限」であったはずで、それこそ縦横無尽に製品を駆け回り、バグの匂いを天性の勘で嗅ぎつけ、それを検出していたことでしょう。こういうテスターに”順番に実行していく”タイプのテストを行わせると、これまで無制限に発揮されていた想像力がまさしく「台本」によって制限され、どうしても課された定量的なタスクをこなす方向に意識が行ってしまいます。

 ではどうすれば良いのでしょう。実はこのようなテスターはたとえどれだけスクリプトテストの技術が発達しても得がたい特性を持っていますので、そのまま「少し見てくれない?」型のテストを実行してもらったほうがテストチームにとっても幸せな結果となります。とはいえひたすら「少し見る」では飽きるはずですので、ついでに「なぜここを見ようと思ったか」「なぜそのようなデータを入れようと思ったか」という思考のリバースエンジニアリングとも呼べる課程を文書に起こしてもらい、それをスクリプトテストを開発する際の重要な資料として利用すると良いでしょう。また、その瞬発力を最大限活用できるよう、複数の製品を担当してもらう、のも有益かもしれません。

以上「なぜテスト設計をすると一時的にバグが出せなくなるのか?」の種明かしでした。後者の天然探索的テスターはどうしようもありませんが、前者は明らかに組織のレベルの低さに起因しており、気に入ったのでもう一度言いますが、レベル10の勇者がスライムの群れを相手に無双している状態です。まずは相手を育てて、心からゲームを楽しめるようにしたいところです。

本記事が、新たにテストマネージャになった方への何かのヒントになれば幸いです。


本記事は Software Testing ManiaX Vol.8 への寄稿記事を若干加筆修正したものです。