テスト計画が失敗する原因、その回避策ソフトウェアテスト・エンジニアの本音(3)(1/2 ページ)

» 2005年01月12日 12時00分 公開
[大西建児,株式会社豆蔵]

 第2回「テスト設計の基本とさまざまなテスト技法」より引き続き、ソフトウェアテストに関心の高いエンジニア達が集まって主催する「JaSST:ソフトウェアテストシンポジウム」実行委員会のメンバー(以降JaSSTメンバー)が、テストに関する議論をお届けします。本記事執筆時点の12月上旬は、1月24日、25日に開催予定の「JaSST'05(東京コンファレンスセンター品川で実施)の開催準備で、実行委員会は「てんやわんや」の状態でした。今回も、聞き慣れない用語や表現にはできるだけ解説を加えつつ話を進めていきます。

議論パート

 11月某日、都内某所にて。JaSST実行委員会のてんやわんやの議論で疲れつつ、いつものようにテスト談議で盛り上がるべく居酒屋の席に着きました。今回は、取りあえずのどの渇きと空腹を満たしてからテストの議論に移ったため、盛り上がり方がいつもとは少し違うかもしれません。タダの雑談になりそうな流れを変えようと、今回は和田(富士通)が話を切り出しました。


和田 これまで技術的なアプローチからテストの話題を議論してきましたけど、そろそろ管理系の話をしたいなぁと考えていたんですよ。管理系といっても幅が広いので、まずはおのおの、テストを実施するに当たってどんな計画を立てているか、それとも立てていないのか、そんなところから話を始めませんか。

大野(SKサポートサービス) 「計画せずに何のテストぞ」と思いますよ。無計画に突き進んでもろくなことにならないのは開発プロジェクトもテストも同じことでしょう。

西(電気通信大学) テストの計画を一生懸命に立てたとしても、最初から計画どおりに進まないなんてことの方が実際問題多いんじゃありませんか。そこのところは、どう取り組むべきなんでしょうね。

大野 プロジェクトの計画もままならないようなら、テストだって計画どおりにとはならないでしょう。だとしても、テストフェイズも含めて「きちんと」計画を立てるところから始めないと、ぐちゃぐちゃのプロジェクトになってしまうでしょうね。

和田 うーん。確かにうまくいかないプロジェクトには計画は不在ですよね。

湯本(サイクス) わたしが知っている範囲でも、プロジェクト計画を立てていないことはよくあります。

西 計画ばかりにこだわる、決められたことを粛々とやるモデルではなくて、状況の変化にうまく適応して進める「アダプティブなテスト」を目指したいですよね。テストフェイズはほかの開発フェイズに比べても、リスクについて感度の高いアダプティブな対応が求められるでしょうし。

大野 QAの世界では極論をいってしまうと、理屈的に品質を保証できるのなら、例えばシステムテストを実施せずに出荷するというのもあり得るんですね。ただし、これが成り立つのは静的(注1)/動的(注2)両面での検証を計画立てて実施したうえで、品質の見極めができたらという話ではありますけど。


【注1】 [静的] ドキュメントやコードのレビューといったプログラムの動作を伴わない検証アプローチ

【注2】 [動的] プログラムを実際に動かす、テスト実施による検証アプローチ


大野 ただ、そんなことをいっている本人が、品質保証もあったもんじゃないデイリービルドで来週は泣いているかもしれないんですが。

一同 (笑)。

榊原(日本IBM) 要求を定義したら、それをベースにテスト設計するっていうテストドリブンな開発アプローチを取るとするならば、無計画ではうまくいかないですね。

西 テストドリブンの開発スタイルをうまく回すためには、上流できちんと要求を決めつつ、要件を固めていかないと駄目ですね。どのようにシステムのディテールを固めていくか検討しないと、派生仕様のトラッキングが難しくなりますから。トラッキングができるように、ある程度、計画立てが必要でしょう。

和田 いきあたりばったりだと当然うまくいかないということですよね。

西 「いけー! やれー!」と勢いだけでテストしているという現実を知らないわけではありませんが、やはりそういった組織のテストはうまくいってないですし、プロジェクト全体としても問題を抱えているんじゃないかな。

大西(豆蔵) 皆さん先ほどから「テスト計画」といってますが、そもそもテスト計画をどのように定義してますか。IEEE 829(注3)のようにきれいに規定されてます?


【注3】 [IEEE 829] IEEE(米国電気電子学会)Standard 829-1998 for Software Test Documentation。テスト計画やテスト設計仕様、テスト手順書などテストに関するドキュメントについて規定した標準


鈴木(三)(TIS) 多くの場合、テスト計画段階で決めているのはスケジュールだけだったりしますね。開始日と終了日が決まっているだけのものです。経験上、テストにおける開始日というのは、守られませんから、スケジュールが押した場合の対策が注釈で書いてあったりします。「納期を厳守するために、非常時には3直体制で行う」ということが書いてあったというのを知人から聞いたこともありますよ。

西 一方ではテスト計画書というドキュメントに、どんなテストするのかを含め詳細な項目まで全部記載しているものもありますね。

大野 そういったドキュメントの形式を取った場合、プロジェクト計画段階でテスト計画書をFIXできなくなるでしょう。

西 そもそもテストに対して、きちんとした管理だとか計画の概念がないままに作成すると、形だけのテスト計画になりかねませんね。

大野 すべてアドホックテスト(注4)ということになると計画以前の話かもしれませんし。


【注4】 [アドホックテスト] テスト設計せずに思い付いた項目をテストするため、テスト実施記録が残らない場合も多い


榊原 テストをマネジメントするためテスト計画をしっかり立てなくちゃということだけど、案外それに携わるテスト担当者自身は管理されるの嫌いなんじゃないですか。

大野 だいたい、プロジェクトって計画どおりに進まないことが多いですよね。例えば、最後(出荷前の段階)にまとまり切っていないシステムを、テストと称するフェイズで動くことを確認するところまで強引に持っていかなきゃならなくなったとしましょう。こうなると、抽象的な表現だと、ぐちゃぐちゃ〜と作業しなくちゃならなくなることが多いんですよ。そういう状態だと、管理なんかされたらテストそのものをやり切れないし、気分的にもやってられなくなるという現実があるからじゃないですか。

榊原 それは要求定義しているときも同じですよ。上流段階からすでにプロジェクトメンバみんなが、計画どおりにいかないと思っていることもあるわけだし。

大西 うーん。何か計画どおりにいかなくて困ってしまうという話になってきていますが、実現可能な計画とするための斬新かつアカデミックなテスト計画のアプローチを考えられませんか?

西 前提として、計画が絶対だって考えるのを止めればいいんです。変化を受容できるような計画でないと、結局「仏作って魂入れず」になりますし。

榊原 テストドリブン計画って考えられない?

西 何でも言葉付ければよいと思っていません?

榊原 いやいや、まじめに考えていますよ〜。サービス・オリエンティッド・テスティング(SOT)じゃどう? エンタープライズ・テスティングとかも何かアイデアがわいてきそうだし。

西 テスト計画を導くということなら、「テストナビ」というキーワードで何か考えられるかも。

大野 何か商品名のよう。だったら流行で「テストナビ ダッシュボード付き」というのはどう?


 いつものように、最後の方は何だか分からない方向に話が流れてしまったようです。面白いことに、メソドロジというものは案外こういった話し合いから原型のアイデアが生まれることもあるようです。上記のアイデアには半ば冗談も含まれているかもしれませんが、肩の力を抜いた議論は時にブレイクスルーを生んでいる「かも」しれません。では次のパートでは、テスト計画について一般的な見解も含めて解説しましょう。以下の解説は和田と本記事取りまとめ担当大西がまとめました。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.