テスト設計の方針は千差万別ソフトウェアテスト・エンジニアの本音(5)(1/3 ページ)

 今回は2005年1月24、25日の2日間に行われたJaSST'05「ソフトウェアテストシンポジウム」の模様を通して、ソフトウェアテストに対するエンジニアの意識や認識などを浮き彫りにしていきたいと思います。

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

 JaSST'03から始まり、はや3回目となったこのシンポジウムについて少し紹介します。本シンポジウムは「ソフトウェアテスト」をキーワードに参加者、協賛団体、そしてスポンサーなどさまざまな方より、ご支援とご協力を得て開催しています。回を重ねるごとに、テストに対する参加者の意識も高くなり、その重要性が着実に認知されてきていることを実感しています。今回のJaSST'05では2日間で延べ900人を超えるエンジニアが参加しました。参加者は、現場のエンジニアからQA部門やSEPGの担当から管理層まで参加しており、層にかかわらずテストへの感心が高いことが分かります。職種についても情報システムの開発や組み込みシステム、市販アプリケーションとさまざまな分野から参加があります。「ソフトウェア品質」をまじめにとらえなければならないという意識はもはや「当たり前」になってきているからでしょう。

 補足:JaSSTについてご興味を持たれた方は、発表者より許諾が得られた論文や発表資料を掲載しておりますので、ぜひ本シンポジウムのWebサイトをのぞいてみてください。

バグを見つけるためのそれぞれの戦略

 普段テスト技法を使ったテスト設計をしていますか。テスト技法について興味がないという声はあまり聞いたことがありません。ですが、実際に技法を使うことで「どれくらい効果的なテスト設計ができて、効率良く不具合を見つけることができるのか」ということについては、テストのプロが身近にいない限り、良い事例そのものを見ることも知ることさえもできないのではないでしょうか。JaSSTでは「テスティングライブ」というプログラムで腕っこきのテストのプロを集め、事前にテスト設計したテストケースをベースにテストを実施する模様を紹介する企画を立てました。

 どのような企画なのか? その模様を実行委員の宮崎大学の片山徹郎がお届けします。

 「テストライブ」とは、テストのプロフェッショナルたちが、開発側を向こうに回して、自前のテストケースを武器に、テスト対象のバグを聴衆の前でその場で見つけていくという企画です。昨年のJaSST'04にて初めて開催し、大きな盛り上がりを見せたため、今年も実施することとなりました。

 テスト技術者代表チームとして、国内ベンダ、外資系ベンダ、第3者検証会社に所属する3名のエキスパートに今年も参画していただきました。また開発側として、SESSAME(組み込みソフトウェア管理者・技術者育成研究会)の方々に今年も協力していただきました。

選手:

太田健一郎/日本IBM(テストエンジニア担当)

野村准一/NEC (テストエンジニア担当)

山崎太郎/ベリサーブ (テストエンジニア担当)

実況・解説・問題作成(協力:SESSAME

吉澤智美/NECエレクトロニクス(題材作成アドバイス&当日運営担当)

二上貴夫/東陽テクニカ(総合プロデュース担当)

大月美佳/佐賀大学(テスト題材作成取りまとめ担当)

大西建児/豆蔵(企画提案&シナリオ担当)

片山徹郎/宮崎大学(本ライブ企画取りまとめ担当)

 今年のテスト対象には、佐賀大学の大月先生が開発した通称「100人システム」を利用しました。これは、初日のJaSST'05「100人ライブ」にて使用したものです。この「100人システム」にバグをわざと仕込む、いわゆるエラーシーディング(*1)手法を使い、ツールを開発していた大月先生に依頼して、テストライブ用に「100人システム エラーシーディング版」を作成してもらいました。


*1:エラーシーディング-テスト対象のプログラム内に、あらかじめ人為的なエラーを埋め込み、テストを行った結果、埋め込んだエラーを摘出できたかどうかでテストの効果や妥当性を検証する手法


 埋め込むバグは、実際のツールの開発段階で見つかったものを中心に、SESSAMEの方々からアドバイスをいただき、厳選してもらいました。つまり、テストライブは、この開発チームが埋め込んだバグに対して、制限時間内にテスト技術者チームがどれだけ見つけられるのかを競う企画です。

 なお昨年(2004年)は、開発チームが埋め込んだバグの数11個に対して、テストチームは15分間に約半数の5個を検出できました。短い時間にもかかわらず立派な結果といえるでしょう。しかし、検出したバグの数が約半分という点に、引き分け感を感じた人も少なくありませんでした。そこで、今年のテストライブでは、テスト技術者チームに、この1年間の成長の結果を存分に見せ付けてもらおうということで「テストエンジニアの成長はいかに?」とタイトルを付けました。



 今回テストチームの3人のメンバーはそれぞれ各自が立てたテスト戦略を基にテスト設計を行いました。どのようなものか簡単に紹介しましょう。


 A氏は異常系のテストケースに注力すべく、「遷移が存在しない、誤っている」「本来存在しない遷移」「不正な入力に反応」というようにテスト設計方針を立てました。


 B氏は「今回のテスト対象はプログラム規模が小さいし、テスト実施時間が短い」ことから「今回は不具合をたくさん見つけるのが命題」としてテスト設計をしました。


 C氏は画面入出力項目に対して、各項目の設定可能項目と設定値の組み合わせをマトリクスにて抽出しました。そこでは、最大値/最小値や境界値また異常値を考慮し組み合わせを合理的に少なくするという工夫がなされました。



 まずは、ライブ当日までの流れを簡単に報告します。「100人システム」そのものの開発はシンポジウムの開催に間に合うように進めていました。そのため、ライブの1カ月前に、まずテスト技術者チームには、ラフな仕様(ユースケースと画面仕様書)とツールのα版を渡し、ツールの機能についてまずは理解してもらいました。

 そして、ライブの2週間前(!)に、正式な仕様書をテスト技術者チームに渡しました。その際、テスト技術者チームからは「仕様がアバウトな個所があり、テストケース設計が難しい」という声も出ましたが、「テストをやる人間は、仕様に文句をいってはいけない」といった名言(?)も出たりで、そのまま当日に使用するテストケース設計に取り掛かってもらいました。念のため書いておきますが、テスト技術者チームが触ったのはツールのα版のみであり、当日のライブ開始まで一切、実際のツールには触れていません。



 仕様書の記述があいまいであったり、抽象度が高いことは決して珍しくありません。テスト設計のポイントとしては、完ぺきではない仕様からもテスト設計を試みることで整合性の問題を見つけ出したり、ウイークポイントをあらかじめ知っておいたり、テスト工数のボリューム(概算)を見積もることなどが挙げられます。



 ちなみに開発チームの方はというと、ライブ前日の深夜まで、バグをどうするかのメールが飛び交っていました(これは、ライブ当日よりライブ感があったような気もします……)。

 当日のライブですが、まずは、テストライブの進め方について、司会からの説明で幕を開けました。次に、開発チームから今回テスト対象の「100人システム」の仕様についての簡単な説明をしていただきました。それから、テスト技術者チームのメンバーから、それぞれが設計したテストケースの設計方針と内容の概略について説明してもらいました。

 そして、いよいよ試合開始です。テスト技術者チームには、約25分間でテストを実施してもらいました。バグを見つけるとテスト技術者はブザーを押して内容を説明し、それを聞いて開発チームがバグかどうかを判定するという流れです。

 テスト開始早々、テスト技術者チームは次々とバグを発見! 最初の10分で、なんと7個ものバグを指摘しました。その後は苦戦している様子でしたが、最終的な結果は、テスト技術者チームは8個のバグと2件の仕様漏れを検出しました。

 試合終了後の種明かし時に開発チームから明かされたバグの数は全部で14個でした。そのうち、半数以上の8個(+仕様漏れ2件)を指摘したのですから、短い時間にもかかわらず立派な結果であり、テストエンジニアの成長を大いに見せ付けたライブだった、といえるでしょう。開発チームとテスト技術者チームはお互いの健闘をたたえ合い、今年のテストライブは終了しました。



 実際、エラーシーディングされた不具合の中で発見する難易度が高いものは、今回のライブ中には検出されませんでした。どれも難易度が低いか中程度に位置付けられたものが検出されました。これはテスト戦略が「できるだけ数多くの不具合を摘出する」ためだったからであり、「深刻なバグを見つける」という観点ではなかったことが理由といえるでしょう。

  ちなみに、難易度が低・中程度に位置付けられたエラーは、仕様確定があいまいな場合に混入するものが大半でした。実際の開発現場でも低・中程度の不具合が多くを占めるでしょうから、仕様があいまいなまま開発することの問題としてもとらえることができるでしょう。



 テスト実施中は、リアルタイムでテスト技術者のテスト作業中の画面をスクリーンに表示し、実況中継を行いました。聴衆として参加していただいた方には、テスト技術者のさまざまな技を生で見ることができたと思います。また、開始早々バグがバタバタと多く見つかって、その後収束していく様子は、まさにソフトウェア信頼度成長曲線(*2)そのものだった、という指摘もいただきました。



*2:信頼度成長曲線とはテストに掛けた工数と発見したバグ数から、プログラムに残っているであろう、バグの総数を推定するために用いる曲線


 今年のテストライブは、テスト対象ツールの提供、エラーシーディングのアドバイス、そして何より、テスト技術者として参加いただいた方々のスキルの高さにより、支えられたと思います。


       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.