新しいメンバー

テスト設計の成果物をテストケースの雛形と解釈した中山君。でき上がったもの（前回参照）を大塚先輩に持って行くと……。

大塚先輩：

中山君のチームに今年2年目の小川君を入れようと思っているけど、小川君を知ってるかい？

中山君：

いえ、知りません。今までどのチームにいたんですか？

大塚先輩：

お客様先常駐のSUBARUプロジェクトだよ。

中山君：

あの噂に聞く……。大変なプロジェクトにいたんですね。

大塚先輩：

そうだ。いろいろと経験してきたみたいだけど、中山君もしっかりと小川君を指導して欲しい。

中山君：

わかりました。

リーダとして部下を指導するのは、初めてです。身が引き締まる思いです。

大塚先輩は内線電話で小川君を呼びました。3分程度して、コンコンとドアを叩く音が聞こえました。その後に爽やかな青年が入ってきました。さっそく大塚先輩が小川君を紹介してくれます。

話によると、その年の新人では特に優秀で、新人研修が終わったらすぐに最前線に駆り出されたとのこと。そういえば、どことなく若々しさの中に自信があふれているように見えます。

小川君：

小川です。今までSUBARUプロジェクトにいました。詳細設計からシステムテストまで一通り経験いたしました。よろしくお願いします。

中山君：

中山です。SAKIGAKEプロジェクトのテストリーダをやっています。こちらこそよろしくお願いします。

大塚先輩：

小川君、急ぎの仕事を抱えている？

小川君：

いえ、今は引き継ぎ中なので大丈夫です。

大塚先輩：

これからテスト設計のレビューなんだ。せっかくだから一緒にいてもらおう。

小川君：

わかりました。ではノートなど用意する必要がありますね。一旦席にもどって準備してきますのでしばらくお待ちいただけますか？

テスト計画を見直す

小川君は5分程度で戻ってきました。大塚先輩は外部の意見を取り入れるという狙いで、まず小川君に話を振ることにしました。

大塚先輩：

さっそくだけど、小川君。このテスト設計を見て欲しいんだけど。

小川君：

はい、わかりました。え～と、このホワイトボードを使ってもいいですか？

小川君はすっと立ち上がり、自前のマーカーを手に持ち、ホワイトボードの前にたちました。

小川君：

中山さんは、今回のシステムテスト全体をこのように考えているんですよね。

と、図1のマインドマップを書き始めました。

大塚先輩：

ほお、小川君はマインドマップを描けるのかね。

小川君：

はい、前のプロジェクトで使っていました。

中山君は目を白黒しています。マインドマップという言葉を聞いたことはあっても、読書記録をつけるものだと思っていて、仕事に使うとは考えたこともありませんでした。

小川君：

システムテストを大きく分けると3つになりますね。この3つで十分ですか？

中山君：

大塚先輩がレビューしていていただいたテスト計画では、業務シナリオテスト・性能テスト・セキュリティテストの3つをやることにしてます。

大塚先輩：

テスト分析が終わった段階で見直す必要は無いかな？

中山君：

えっ、どういうことですか？

大塚先輩：

テスト計画を書くときに、すべての情報を持っているわけではないよね。限られた情報に基づいて書いているわけだ。当然、工程が進むにつれ情報量が増えてくると、見なさなければいけないだろう。

中山君：

確かにそうですね。

テスト計画の見直し

テスト計画を作るときには、さまざまな情報を収集し検討を尽くして書きます。ですから、それほど後になって見直す必要はないと考えてしまうかもしれません。しかし、スケジュールが進むにつれ、プロジェクトの実態が見えてきて、さまざまな情報が入ってくると、見直しが必要になる場合があります。もし、見直しが必要ないとしても、見直しが必要ないことを確認するために、見直しという作業自体は行う必要があります。

特にテストは開発の最終工程にあたり、プロジェクトの歪みをすべて引き取る工程になります。計画段階では知らされていなかった実態を知ることにより、方向修正が必要になることも少なくありません。

テスト計画を見直さなければならない可能性が常にあることを、リーダは意識しておくべきです。

テストカテゴリを見直す

大塚先輩：

画面遷移のテストは終わっているの？

中山君：

結合テストで終わっていると思っているのですが……。

大塚先輩：

確認した？

中山君：

いえ、していません。

少し大塚先輩の顔が暗くなってきました。何か良くない兆候です。

大塚先輩：

中山君、前回の新規開発時のバグ一覧を確認したかい？

中山君：

いえ、していません。

大塚先輩：

そうか……。ちゃんと確認しないと何とも言えないけれど、たしか、前のプロジェクトは性能テスト・負荷テストばかり重視して、画面遷移がぼろぼろだったって聞いているんだよ。そんな噂、聞いていない？

中山君：

いえ、特に聞いていません。

大塚先輩：

何かイヤな予感がするんだよね。

窮地に陥っている中山君を見かねて、小川君が間に入りました。

小川君：

ところで、外部設計書の中に画面遷移図はあるんですか？

中山君：

無かったよ。あったのは画面階層図だけだね。

小川君：

じゃあ、画面遷移のテストはやっていない可能性が高いですね。図面がないならやらないでしょう。

中山君：

そうかなぁ。普通、画面遷移のテストぐらいやらない？

小川君：

私がいたプロジェクトでは、結合テストで画面遷移のテストはやっていませんでした。システムテストに入ってバグが多発して、急遽、追加で画面遷移テストを入れました。

中山君：

マジ？

小川君：

どうやら、このプロジェクトでは、最初から準備しておいた方がよさそうですね。

小川君はそう言うと、ホワイトボードに描いてたマインドマップに画面遷移テストを追加しました。

前工程で実施したテストの確認

中山君のチームはシステムテストを担当しています。そのため、前工程である結合テストでどんなテストを実施したのか確認する必要があります。同じテストを繰り返すのは無駄ですし、同じようなテストを実施するとしてもテスト観点を変えて実施するはずです。

前工程で実施しなかったテストを、本工程で実施するかどうかの判断はテスト戦略で行います。

今回のケースでは、テスト計画で漏れているテストを行うかどうかの判断です。特別に必要だと認められなければやらない可能性があります。

過去情報、類似プロジェクト情報の確認

大塚先輩はこの判断をするために、新規開発時のバグ情報に当たりをつけています。小川君は自分の経験から怪しいところを探っています。このように過去の情報や類似プロジェクトの情報を確認して、テスト戦略に活かします。

モデルとテスト設計の関係

大塚先輩：

画面遷移テストはやっていない可能性が高いから、こちらでも準備しておこう。何をすればいいと思う？

中山君：

画面遷移のパスをいくつか挙げておくことでしょうか？

大塚先輩：

今はテスト設計を行っているんだけれども、テスト設計という観点でも同じ答えになる？

中山君：

テスト設計の観点と言われましても……。

大塚先輩：

小川君はどう思う？

小川君：

時間に余裕があるとすれば、画面遷移を状態遷移と見なした状態遷移テストをやりたいですね。

中山君：

状態遷移テスト？

小川君：

はい、画面を状態と見なして、状態遷移図を作成します。その状態遷移図からテストケースを作成すると良いと思います。

中山君：

開発チームが作っていない設計書を作るの？　それはテストチームの仕事じゃないでしょう。

小川君：

いえ、そうではありません。テストに必要なモデルを作るんです。

中山君：

それはテストケースじゃないんだよね？

モデルを書く

システムテストは業務シナリオに基づいたテストをすることが多いようです。ですから、中山君の反応は普通です。本来はモデルを使ったテストを行うことは少ないからです。

しかし、今回は結合テストで行われなかった画面遷移テストを実施しようとしています。結合テストでつぶしておきたいバグが残っている可能性があり、そのバグを効率的に除きたいという意図があります。その方法の一つとして、画面遷移を状態遷移とみなす状態遷移テストがあります。

状態遷移テストは、状態遷移図または状態遷移表をもとにテストケースを挙げていきます。状態遷移図など文書が開発チームかから回ってこない場合、テストチームでモデルを書かなければならないこともあります。

テスト設計としてのモデリング

テストリーダは、テスト設計の一つとしてこのモデルを書く作業があることを知っておかなければなりません。知らなければ、工数を見積もるときにも、担当者にモデルを書く役割を割り当てるときにも漏れてしまいます。

また、テスト設計で用いられるモデルにどんなものがあるかを知っておいたほうがよいでしょう。自分で全部知っておいた方がよいのですが、「⁠知っている人」を知るというやり方もあります。物知りな人に聞けばよいからです。

テスト観点とテスト設計の関係

大塚先輩：

これはテストケースのたたき台だよね。

中山君：

はい、そうです。

大塚先輩：

このテストケースはどうやって挙げたの？

中山君：

どうって……。

大塚先輩：

いくらなんでも闇雲に書き上げたわけじゃないだろう。

中山君：

考え抜いて書きました。

中山君、また自分で自分を追い込んでいます。確か中山君はテスト設計で何をするのかをよく知らずに、「⁠テスト設計」＝「テストケースの雛形」と勝手に判断していました。

大塚先輩は、この中山君の判断をすぐに怒らずに、テストケースの雛形を書く過程でどのようなテスト設計を行ったかを聞き出そうとしています。

大塚先輩：

最初に書いてあるシナリオテストを取り上げてみようか。中項目や小項目に書かれている項目はどうやって考えたんだ？

中山君：

ユーザの操作をイメージして書きました。書籍購入サイトですから、本を購入するところからスタートして書きました。

大塚先輩：

それはいいんだけど、「⁠1冊／複数購入」「⁠ギフト有無」などがあがっているね。これらは何から挙げたんだ？

中山君：

自分がこのサイトの顧客だと想像していろいろと挙げました。後は通常の購入パターンではない顧客の購入パターンを考えました。

大塚先輩：

そうそう。その購入パターンというのは、どんな組み合わせで考えたんだ？

中山君：

組み合わせですか？　これはシナリオテストです。組み合わせテストじゃありませんよ。ですから、組み合わせなんて考えていません。

大塚先輩：

シナリオを考えるとき、適当に考えるんじゃなくて、テストすべき観点を挙げていって、その組合せを考えたほうがいいんだ。

中山君：

観点を列挙しようとしても、テストケース表は大項目、中項目、小項目の3つしかありません。全部は書けませんよね。

大塚先輩：

だから、いきなりテストケース表を考えてはいけないんだ。俺は別の用紙でまとめてから、テストケース表に落としていくよ。

中山君：

別の用紙ですか？　別の表に書くんですか？

小川君：

私はマインドマップを使っています。

中山君：

えっ、マインドマップ？

作業内容を曖昧にしない

中山君は、テスト設計で何をすべきかを知らないまま作業を進めてしまいました。今回は個人作業でしたので、影響は中山君一人でしたが、チームで作業していたとすると、背筋が寒くなります。リーダの行動がメンバ全員に影響を与えるということを意識しなければいけません。

テスト観点を洗い出す。

テスト設計という言葉は、最近よく聞くようになりましたが、まだ知らない人も多いでしょう。また、会社のプロセスの中に「テスト設計」という活動が含まれているのもまれかもしれません。

この連載では、

• テストで確認したい項目を列挙し、その観点間の関係を考えること
• 各種図表を作成して、テスト観点を導き出すこと
• テスト観点間の関係や組合せを考えること
• 組み合わせの中で、今回のテストから省くものを考えること

などをテスト設計と呼んでいます。

各種文書からテスト観点を導き出し、テスト観点間の関係を考えていきます。慣れてくれば、Excelで作成した表に書き込むだけで良いのですが、慣れないうちは、マインドマップにテスト観点を書き込み、それぞれの関係を考えていくと、全体像を見えやすくなります。

作業の振り分けを考えておく

小川君：

ときに、テスト実装は何人で行うのですか？

中山君：

小川さんと…　予定ではもう一人にやってもらうことになっています。

小川君：

なるほど。であれば、ある程度どのように作業を担当するのか、テスト設計の時点で作業分割のイメージが見えるようにしておいた方がいいですね。

大塚先輩：

それにね。実際にどの程度のテストケースを作る必要があるのかも、見えていた方が良いね。中山君、そこは考えていたかい？

中山君：

…いえ、そこはあまり考えていませんでした。

次の作業の分担イメージをもっておく

このご時世、一人でテストケースを作成するということはなかなかありません。テスト設計の結果から、複数のメンバで手分けしてテストケースを作成します。

テスト設計はテスト観点をモデリングすることも大切ですが、そこから実際のテストケースの規模や作成にかかる工数などを見積もり、作業をどう振り分けるのか、どれだけの人員をそろえる必要があるかを検討する必要があります。

おわりに

さて、皆さんいかがだったでしょうか。今回は、テスト設計は耳馴染みがよい工程ですが、その実、何をやっているかのイメージを持てていない方も多いのではないでしょうか。

それは、テスト分析やテスト実装と一緒に考えられてしまうことが多いからです。プロセスの定義は組織によってさまざまですが、一度確認してみると良いでしょう。

さて、次回はいよいよテストケースを作成する工程「テスト実装」です。