約3ヶ月前に「ソフトウェアテスト293の鉄則」の記事を書きました。

• http://dev.ariel-networks.com/Members/inoue/software-testing

この本で最も感銘を受けた部分は、テスト多様性の重要さです。様々なテスト技法を組み合わせること、ひとつの機能のテストを複数の人の視点でテストすること、ひとりの人に長期間同じ機能のテストを続けさせないこと、などです。

自分なら、テストチームをこう管理する、という例を具体的に示してみたいと思います。ちなみに、自動化できる部分(単体テストなど)は別枠で実施されていると仮定します(これから話すことの範囲外です)。

テスト期間は2週間、チームのメンバーは7人と仮定します。メンバーの技量は高い人もいれば低い人もいるとします(現実的な仮定だと思います)。

2週間を平日で数えると10日間です。まず期間を分割します。最後の二日は予備として空けます。残りは8日間です。中間チェックポイントを設けたいので、これを2分割します。前半4日、後半4日です。結果として、4:4:2の3つに分割されました。この3つの期間にどういうテストを割り振るかを考えます。

前半4日間には重点項目をテストします。この4日間の目的は、怪しい箇所はテストした、と思えることです。怪しい箇所は、機能として重要であることと、バグが多そう、という条件(のどちらか)を満たす箇所です。テスト期間は2週間なので、どこが怪しいかを特定するのに時間はかけられません。ぼくであれば、次の基準で選びます(重視する順)。

1. 開発者(コードを書いた人)が危険だと感じている箇所
2. 最近(半月から1ヶ月)、コードが変わった箇所
3. 最近(1,2週間)にバグが多く見つかっている箇所
4. 以前からバグが多く見つかっている箇所(あまりに遠い昔の情報は意味を失っている可能性があるので、ここ半年ぐらい)
5. 普段使われない機能
6. テストが面倒な機能(テストのための準備が大変な機能)

上の基準で挙がる箇所はそれなりに強い相関が現れるのが普通です。

この中でも最も重視するのは、コードを書いた人間が自ら危ないと感じている箇所です。開発者に聞いて、怪しい箇所を思いつかないと答えたとしても、敢えて挙げさせてみるべきです。コードを書いた人間の悪い予感というのは、無視するには惜しい情報です。もちろん、盲点はあります。と言うか、普通は盲点があるのでバグが生まれます。それを補完する客観的な事実として、2から4の基準で怪しい箇所を特定します。 5と6の基準は少し違う視点です。普段使われない機能の一例は、インストールおよびセットアップです。特権ユーザでの操作も盲点になりやすい箇所です。例えば、AirOneの場合であれば、ルームの招待は一度やってしまうとあまりやる機会がなくなるので、リリース直前までバグに気づかないことがよくあります。

こうして怪しい箇所を特定した後、テストを割り振ります。その前に、7人のうち2人には特定機能のテストではなく特別なアサインを行います。7人のうち、最もスキルの高い人間と最もスキルの低い人間を選別します。「ソフトウェアテスト293の鉄則」によれば、モンキーテストという用語には、スキルの高い人が経験と直観で探索的に行うテストという意味と、スキルの低い人がメチャクチャに行うテストのふたつの意味があるようです。用語を区別するために、前者の意味をスーパーモンキーテストと呼ぶことにします。

選別したふたりのうち、スキルが高い人にはスーパーモンキーテストをアサインします。基本的に、スーパーモンキーの役割は2週間固定です。バグの収束具合やソフトウェアの安定度を量る上で、スーパーモンキーの報告バグ数と印象は重要な尺度となります。 選別したもうひとりには、スモークテスト(を兼ねた基本テスト)をアサインします。スモークテストのテスト項目はきちんと文書化されている必要があります(対照的に、スーパーモンキーテストは文書化よりも創造性が鍵です)。スモークテストは、決まったテスト手順を地道に繰り返す作業です。このアサインをした人をただのモンキーと呼びます。名手が正面のゴロをトンネルしたり、好打者に限って真ん中の直球を打ち損じたりするように、スーパーモンキーは高スキルゆえに、意外な盲点を抱えることがあります。モンキーはこのような危険を補完します。モンキーが挙げるバグの報告件数は、ソフトウェアの安定度を量る尺度のもうひとつの柱です。

残り5人には怪しい箇所のテストを割り振ります。4日間をフルに活用するため、様々な工夫を組み合わせます。特に怪しい箇所には複数の人の視点でテストするために4日間の中でテストする人を交代します。(既知であれば)ユーザの環境を模倣したシナリオテストを行います。

前半4日間のテスト終了後、全員で集まります。そこで、後半4日間の戦略を練り直します。次の重点テスト箇所の基準は、前半4日間で報告されたバグを元に決めます。また、前半4日間でコードに修正が入った場合、そこに副作用があることを前提にします。報告されたバグをネタに、改めて、開発者の悪い予感を引き出す努力をします。

状況によりますが、後半は5人のうち、1人か2人をスーパーモンキーに配置替えしても良いでしょう。前半のテストと後半のテストで同じ機能をテストする場合、テスト実施者は変えます。テスト実施者の視点を変えることは、数あるプラクティスの中でも最も効果が高いと感じています。2週間のテスト期間の中で、可能な限り行うべきです。しかし、機械的に実施者を入れ替えるのは意味がありません。バグがありそうな箇所に適切に人を送り込むことが重要です。後半は残り日数も少ないので、バグの出方やスーパーモンキーの印象を随時聞きながら、テストのアサインを見直します。

予備の2日は、全員モンキー化します。特定の機能のテストをアサインするより、ここまでのバグ報告の状況を全員で認識した上で、各自に探索的なテストをしてもらいます。数人には、テスト手順書に沿った基本テストをアサインして、回帰テストを兼ねて、基本的なミスがないことを確認してもらいます。

理想的には、最後の2日間にコードの修正は入らず、事実上、RC(Release Candidate)ビルドであるべきです(つまり、最後の2日間にテストしたビルドがそのままリリースされます)。不幸なことにコードの修正が入った場合、速やかにビルドを作り、テスト対象ビルドを更新します。そのビルドをRC2と呼び、RCビルドは無かったことにします。不幸なことにRC3ができてしまった場合、RC2は無かったことにします。RC4ぐらいになると、無かったことにすることがごく自然に行えるようになります(RCがあった現実を受け入れなくなります)。