いよいよテスト分析工程に取り掛かった中山君。でき上がったもの（前回参照）を大塚先輩に持っていいくと、またまた渋い顔をされてしまいました。

大塚先輩：

時間が掛かりそうだから、会議室に移動しようか。

中山君：

第3会議室が空いているみたいです。予約しておきます。

急いで自席に戻り会議室を予約してから第3会議室に向かうと、大塚先輩は既に座っています。

大塚先輩：

さて、早速だが指摘をしていこう。たくさんあるので覚悟すること。

中山君：

はい……。

Webを簡単に信じるな

大塚先輩：

まず一番根本的な質問をしよう。そもそもテスト分析という行為をどのように理解している？

中山君：

インターネットで調べると、『⁠仕様書を入手し、テスト設計を行うために仕様を理解すること。このとき、テスト分析結果を文書としてまとめる。』という解説でした。

大塚先輩：

それはウチでいうところのテスト分析かい？

中山君：

えっ？……　それは…　わかりません…。

中山君は調子よく「経験がある」と言っていましたが、実はそうではないことが大塚先輩にやすやすと見抜かれてしまいました。

大塚先輩：

この前のテスト計画のときにも言ったが、ウチではどうなのか確認しないとダメだ。

大塚先輩：

Webに落ちている情報は必ずしも正しいものではない。簡単にWebから情報を引っ張ってくる癖は、今のうちに直しておくほうがいい。

中山君：

すみません…。

大塚先輩：

それから、できることできないこと、経験があることないことはちゃんと言うことも必要だ。肝に銘じておきなさい。

社内の決まり事

わからないことがあったときに、それをそのままにせずに調べるのは非常に大切なことです。

Webが発達したことで、物事を調べることは非常に楽になりました。ところが、それが正しい情報であればよいのですが、出所不確かで誤っている情報や本来必要ない情報までもが手に入りやすくなってしまいました。

大切なのは、どこで必要な情報なのか、ということです。

中山君は知らないことを調べたところまでは良かったのですが、まずは所属する自社の情報をあたるべきでした。その上で、さらに調査が必要になる場合はWebでもいいですが、そのなかでも信頼に足る情報を入手します。できれば可能な限り、標準や規格、書籍や論文といった出所の確かなものを当たる事が必要です。

できること、できないこと

人間功名心から、本来できない事を「できる」と言ってしまうことがあります。また、やる気を表現するために「できる」と言ってしまうこともあります。そうでなくて、ついうっかり口がすべることもあります。

まだメンバとして振る舞っている場合には、できない事を「できる」と言っても、その前向きな姿勢ややる気を評価することもあります。しかし、中山君はリーダという立場です。できること・できないことを見極めて行動しなければ、メンバ全員に迷惑がかかるかもしれません。リーダは自分のみならずメンバのスキルも把握し、必要であれば様々な策を講じなければなりません。

今回の場合、中山君が事前に「テスト分析は経験がない」と申告しておけば、大塚先輩は何か手を打ったでしょう。

最新のドキュメントを入手しよう

大塚先輩：

気を取り直して、このQ＆Aシートを見ていこうか。幸いなことに、ウチの職場ではテスト分析の結果をQ＆Aシートにまとめるということは合っている。

※　大塚先輩たちの職場では、テスト分析工程のアウトプットとしてQ＆Aシートを作成するということになっています。

大塚先輩：

まず、基本的なところから指摘しよう。この分析に使用したドキュメントのリストがないね。

中山君：

えっ、仕様書はひとつなんですからリストは作る必要ないんじゃないですか？

大塚先輩：

いや、それは大きな間違いだ。仕様書は必須だ。でも分析のためにはその仕様書に関連する文書なども必要だよ。

大塚先輩：

それからこのテスト分析で使った仕様書はいつのものだい？

中山君：

たしか2週間前にもらったものだったと記憶しています。

大塚先輩：

ドキュメントのバージョンはちゃんと確認したのかい？

中山君：

いえ、それが最新の物だと思ってました。

大塚先輩：

いいかい、最初から完璧なドキュメントで作成後に変更がないならそれでもいい。だけど実際はドキュメントの変更は頻繁に起こるんだ。

中山君：

そうか、古いバージョンのドキュメントで分析を行ったとしても、それは最新の状況を反映したものではないということですね。

仕様書以外の重要な文書（設計関連）

テスト分析でよく使う、そして一番重要なインプットは設計仕様書であることは確かですが、果たしてそれだけでいいでしょうか？

答えは「No」です。

設計仕様書にすべてが記載されていればよいのですが、現実にはそのような設計仕様書にはなかなか出会えません。仕様書に書かれていない設計情報や仕様は他のドキュメントを参照したり、また、新たに関係者にヒアリングしたものをまとめた資料を参照する必要がでてきます。

最新の文書

テスト分析の結果は、その後のテスト設計やテスト実装に大きな影響を与えます。単に情報を収集するだけではなく、それが最新の情報なのかを確認する必要があります。古い情報を元に最新の分析結果を作ることはできないのは、皆さんもすぐご理解いただけるのではないでしょうか。

特に設計者とテスト担当者の距離が離れている場合、バージョンの齟齬が発生する可能性が高まります。密に連絡をとり、テストの情報源となるドキュメントが最新なのか、また何時作成されたものなのかを抑えましょう。また、それらドキュメントとそのバージョンは一覧表にして、分析結果のドキュメントに付けておきます。

できれば要件定義書も入手しよう

大塚先輩：

ところで、中山君はV字モデルを知っているかな？

中山君：

知っています。

大塚先輩：

システムテストは、どの工程と対応していただろう？

中山君：

要件定義です。

大塚先輩：

正解。そこまで言えばわかるだろう、次に俺が何を言おうとしていると思う？

中山君：

え～と、要件定義書を見ろということでしょうか？

大塚先輩：

そういうこと。

仕様書以外の重要な文書（要求関連）

今回、中山君が担当するテストは「システムテスト」です。V字モデルでは、システムテストに対応する工程は、要件定義工程にあたります。

単に設計仕様書からテストを考えるだけではなく、仕様が要件を満たしているかどうかのテストも必要になります。

システムテストで要件のテストするかどうかは、組織によって異なりますので、今回は、⁠”できれば⁠”と書きましたが、必須の組織もあります。

一度、自社の決まり事を調べて確認してください。この解説も、ご自分の組織では工程名など異なる場合があります。

ドキュメントを使う人を考えてみよう

大塚先輩：

このQ＆Aシートは誰が使うのかな？

中山君：

僕らテストチームです。あとは開発者ですね。

大塚先輩：

この表紙でそれがわかるかい？　「⁠SEPIAシステム」としか書いていないだろう。どこの部署が書いた方がいいと思うな。

中山君：

よくわからないのですが…。

大塚先輩：

SAKIGAKEプロジェクトは開発もテストも当社が請け負っているだろう。だから、テスト部門が書いたドキュメントなのか、開発部門が書いたドキュメントなのか、わかったほうがいいだろうな。

中山君：

なるほど。言われてみればそうですね。

大塚先輩：

それから押印欄があるけれども、Q＆Aシートで使うの？

中山君：

いえ、フォーマットがこのようになっていたので、そのままにしています。

大塚先輩：

ということは、中山君はこの押印欄は使うつもりは無いのかな？

中山君：

ごめんなさい。深く考えていませんでした。

誰のためのドキュメントなのか確認する

標準化が進んでいる組織では、さまざまなドキュメントのテンプレートが用意されています。一から書式を考えるよりも楽ですし、組織のノウハウがその書式に込められていますから大いに使うべきです。しかし、そのドキュメントを使うときには、誰が読者なのか誰のために書くのかを意識する必要があります。

読者・利用者が明確になることによって、書くべき内容が変わっていきます。自分たちだけで使うドキュメントであれば、細かい説明はいらないかもしれません。しかし、お客様や開発者が利用する文書ならば、言葉遣いを変えなくてはいけないかもしれません。

表紙をおろそかにしない

大塚先輩は中山君の今までの言動と表紙から、読者・利用者を考えていないのだろうと推測しました。表紙がおろそかにされているドキュメントは、中身もたいていの場合おろそかになっているものです。

もしお客様が「ちゃんと作っていないな」と読み取ってしまったらどうなってしまうでしょうか。表紙は決しておろそかにしてはいけません。

テスト設計の大方針について

大塚先輩：

では、中身を見てみよう。まずはじめに『一般的』ってあるね。一般的って何？

中山君：

普通のテストです。

大塚先輩：

普通のテストというのは、どんなテストなんだい。

中山君：

…………。

大塚先輩：

中山君が答えられなければ、これを読んだ人も困ってしまうよ。

大塚先輩：

次にいこうか。構成テストが必要だと書いてあるけれども、根拠はあるのかい？

中山君：

BtoCのサイトなんで、さまざまな環境のテストが必要だと思ったのですが。

大塚先輩：

このプロジェクトは、リニューアル案件だろう。今のサイトに来ている人の環境は調べている？

中山君：

いえ、調べていません。

大塚先輩：

開発の前提はどうなっている？

中山君：

………すみません。聞いていません。

大塚先輩：

これだけはわかって欲しいんだけど、中山君が書いた構成テストが必要だというのは間違いじゃない。必要なテストだ。でも、根拠が必要なんだ。わかるかい？

中山君：

はい。

抽象度の高い言葉は注意して使う

組織の中でよく行われるテストというのはありますが、「⁠一般的」なテストというのはありません。「⁠一般的なテスト」と書くことにより、どんなテストを行えばよいのか、読者全員がイメージできるのであれば問題ありません。しかし、そのようなケースはまれです。

「一般的なテスト」と書くことによって中山君はわかったつもりになってしまい、これ以上深く考えなかったのかもしれません。または、今まで経験してきたテストが、どの組織でも行われているものと思っていたのかもしれません。どちらにせよ、テスト方針を読んだ人が何をするのか理解できるように書かなければなりません。

方針の根拠を明らかにする

過去のテスト経験に基づいて方針を決めることは多いと思います。リーダに期待されていることのひとつでもあります。しかし、経験だけで決めてしまってはいけません。その方針を導き出せる根拠があるのであれば、それを確認しておきます。

重視するテストについて

大塚先輩：

画面ベースのテスト観点を重視するって方針に書いてあるけれども、重視するテストの中に画面のテストが書いてないね。画面のテストではなくて、非機能のテストが中心になっているよね。

中山君：

システムテストなので、非機能を重視しました。

大塚先輩：

それは間違っちゃいないよ。負荷テストやセキュリティテストは重要だ。これらのテストは実施する。気になるのは、方針と違う内容が書かれていることだ。どうするつもりだい。

中山君：

画面のテストはやります。

大塚先輩：

だったら重視するテストに入れなくちゃいけないな。でも、画面のテストは統合テストでもやっているだろう。同じテストをやるのかい？

中山君：

いえ、同じテストじゃありません。業務シナリオにあわせて画面のテストをやります。

大塚先輩：

その内容を反映させてね。

大塚先輩：

次に、ネットワーク復旧テストってあるけれども、何でネットワーク限定なの？

中山君：

ネットワークが止まったら大変だからです。

大塚先輩：

サーバ止まってもいいの？

中山君：

いえ、よくありません。

大塚先輩：

障害復旧テストの中にサーバ復旧やネットワーク復旧があるんだろう。だったら障害復旧テストでいいんじゃないのかな。

中山君：

そうですね。

方針とのつながりを大切にする

テストの方針と実際に実施するテストの種類が異なってはいけません。方針は方針、実際にやるテストはテストと分けてしまっては、読む人が混乱してしまいます。実際にやるテストは方針から降りてこなくていけません。

もし、実施しようと考えているテストと方針が異なるのであれば、方針が間違っている可能性があります。この時点で方針を見直すべきでしょう。

今回のケースでは、方針と重視するテストが同じ一枚に書かれていたため気づきやすいのですが、ページをまたがると見逃してしまうこともあります。

他のものより具体的である場合には理由が必要

負荷テスト・セキュリティテストとネットワーク復旧テストは詳細さが異なります。ネットワーク復旧テストのほうがより具体的です。そのため、何か理由があると考えられます。

復旧テストではなく、「⁠ネットワークの」復旧テストとテストの範囲を限定しています。限定している理由があるはずです。

理由が無いのであれば、他のテストとレベルをあわせておいたほうがよいでしょう。

分析結果をフィードバックしよう

大塚先輩：

ずいぶんと疑問が多いね。

中山君：

はい、中には間違いなんじゃないかってものも多くて疑問にしたんです。

大塚先輩：

よし、それはいいね。仕様バグの恐れがあるものをリストすることは必要だ。それにしてもこの量はすごいね。

中山君：

頑張ったつもりです！

大塚先輩：

うん、これだけ見つけられたらいいね。それで、仕様書の見直しは依頼したかい？

中山君：

見直し依頼…　ですか？

大塚先輩：

高品質な仕様書であればあるほど、分析結果も高品質になる。逆はどうだ？

中山君：

低品質な仕様書であればあるほど、分析結果も低品質になります！

大塚先輩：

そういうことだ。だからテストリーダとしてしっかりと見直し依頼をする必要がある。

中山君：

調整とか大変そうですね…。

大塚先輩：

そう、大変だね。だけど、それをやらないといいテストはできない。調整を行うのもリーダの大切な仕事なんだ。

疑問点は必ず担当者に確認する

分析作業を進めていく中で、さまざまな疑問が生じてきます。

ですが、それはそのままにしてはいけません。Q＆Aシートは用意されていますので、開発者に問い合わせることを会社の仕掛けとして組み込まれています。しかし、あまりに仕様バグが多いようであれば、その際はテストリーダとして設計担当部門に「仕様書の見直し」を依頼する必要があります。

中山君：

そうすると、見直しの結果、仕様書が新しくなったらまた分析する必要がありませんか？

大塚先輩：

そのとおり。最初に中山君が、分析作業は複数回行うことを考えて5日と言ったとき、これは単なる作業遅延のリスクしか考えてないなと思って心配したよ。

中山君：

すみません…。 えぇと、Q＆Aシートそのものも履歴管理しないといけないのかな？

大塚先輩：

そのとおり。分析結果自体もバージョンが存在する事を意識する必要があるんだよ。

分析作業は1回で終わらない

多くの場合、分析作業が1回で終わることはありません。それはテスト担当者の理解がまだ深まっていないこともありますが、先に説明したように仕様バグが含まれることがほとんどです。

視点を変えると、実はこれは仕様書に対する静的テストのような効果をもたらしています。高品質なテストベースからは高品質なテストケースが作成できます。この観点を是非意識するとよいでしょう。

また、当然ながら、複数回分析が行われる場合、どの時点での分析かちゃんと識別できるようにバージョンなどをつけておく必要があります。

分析サマリについて

大塚先輩：

質問の一番目がわかりづらいな。ネットワークの記述の多さと負荷テストとの間にどんな関係があるんだ。

中山君：

関係があると思って書いたんですが、そうではないんですか？

大塚先輩：

負荷テストでどんなテストをやるのかわかっている？

中山君：

負荷テストツール使って、負荷をかければいいんですよね。

大塚先輩：

ツールを使って負荷をかけて、どんな種類のテストをやるんだい。

中山君：

………

大塚先輩：

そもそも一番目の質問は、六番目の疑問『ネットワーク図がない』と矛盾していないかい？

……

大塚先輩の指摘はまだまだ続きそうです。

これから先の指摘内容は、分析そのものというよりもプロジェクト独自のものになりますので、このあたりで止めておきます。

おわりに

さて、皆さんいかがだったでしょうか。

今回は、テスト分析そのものの話とはまた別の指導もありました。ですが、これらの指導はテスト実施担当者からのステップアップの際に躓きそうなものです。現在テストリーダを目指している方は、参考にしていただければと思います。

なお、すでにお気づきかと思いますが、本稿では連載の範囲から外れてしまうため、分析手法そのものについては触れてはいません。分析手法については筆者らの『マインドマップからはじめるソフトウェアテスト』や関連する記事、専門書や論文をあたっていただければと思います。

大切なことはテスト分析という作業をちゃんと理解しているかどうかです。組織がどのように定義しているかを確認し、メンバに指導し、そして結果を確認することがリーダの主な仕事の仕事のひとつになります。しかしながら、案外このテスト分析という作業工程で何を行うべきかは組織で規定されていません。もしその場合は、何をインプットとして、どういう作業を行い、どういうアウトプットを出すのかという観点で現在の業務を整理される事をおすすめします（本稿の場合はアウトプットがQ＆Aシートでした⁠）⁠。

さて、次回は読者の皆さんにも耳なじみのよい「テスト設計」を取り上げます。