「なんとなく」から脱出しよう：必要十分なテスト項目の作り方 ―― テスト設計コンテストの最優秀チーム「めいしゅ館」に聞く

　2011年1月25日～26日に開催された「ソフトウェアテストシンポジウム 2011東京（JaSST'11 Tokyo）」では，テスト設計に関するコンテストが開催された．これは，与えられた要求仕様書に基づいて，その製品に対するシステム・テストのテスト設計内容を競うコンテストである．みごと大賞を受賞したのは，「チーム・めいしゅ館」（名野 響氏，酒井 郁子氏，舘 伸幸氏）．彼らはテストの専門家ではなく，テストを勉強中のソフトウェア設計者である．彼らがどのように課題に取り組み，テストを設計したのかを聞いた（写真1）．

写真1　「チーム・めいしゅ館」のメンバ（左から，名野 響氏，酒井 郁子氏，舘 伸幸氏）

―― どのような経緯でコンテストに参加したのでしょうか？

酒井氏：年明けに，JaSSTの実行委員の方から「出ない？」と誘いを受けました．テストの勉強をしたかったので興味はあったのですが，コンテストの提出締め切りまで日にちがなかったので1人では間に合いそうにありませんでした．そこで，エンジニア仲間である舘さんに声をかけたわけです．

舘氏：ちょうど，部下の名野くんがテスト技術に興味をもって勉強してくれていたので，それを試してみる良い機会だと考えました．実績がないものを本業にいきなり投入するわけにはなかなかいきませんので，まずはコンテストに挑戦してみようと．

酒井氏：「やりましょう」ということで話がまとまり，まずは3人で集まって戦略作りの打ち合わせを行いました．最初は「テスト設計って何をするんだろう？」というところから議論し，方向性を決めた後はメールのやりとりで設計を進めました．

―― テスト設計とは，何をするのでしょうか？

名野氏：一言で言うと，「どうやってテストするのかを考える」のです．テストを行うときに，なんとなくテスト項目やテスト・パターンを作るのではなく，テストの目的やスケジュールを検討し，どのようなテストをどの程度行うべきかなどの方針を定めて，それらの結果としてテスト項目などを作成します．そうすることにより，テスト・ケースに漏れや無駄がなくなり，より少ないテストでより多くのバグが見つかるようになります．

―― 最初の打ち合わせで，話はどこまで進みましたか？

酒井氏：みな要求仕様書は頭に入れてきていたので，テストの目的や，どんな手法を使ってテスト設計を進めるかを決めました．名野さんが，既に「三色ボールペン方式」^{注1（1）（2）}で要求仕様書に書き込んだものを持参していたので，話はどんどん進みました（図1）．たまたま，課題として取り上げられた要求仕様書「話題沸騰ポット要求仕様書（GOMA-1015型）第7版」が，私たちの参加している技術コミュニティ「組込みソフトウェア管理者・技術者育成研究会（SESSAME）」（http://www.sessame.jp/）で作成したものだったので，既に仕様を把握できていたということも好都合でした．

注1：齋藤 孝氏が提唱している，青，赤，緑のボールペンで文書などに書き込みを行う方式．「客観的に見て，最も重要な個所」には赤で，「客観的に見て，まあ重要な個所」には青で，「主観的に見て，自分がおもしろいと感じたり，興味を抱いたりした個所」には緑で書き込みを行う．また，ソフトウェア・テストのコンサルテーションを行っている鈴木 三紀夫氏が，この方式を仕様書の分析に応用する方法について提唱している．同氏は，テスト設計に用いる場合には緑の定義を「主観的に見て，おかしいと感じた個所」に拡張するとよいと主張する．この緑がポイントであり，読んでいて感じた違和感をその場でメモすることにより，疑問やアイディアが次々と生まれてくるという．名野氏らは，この鈴木氏の提唱する方法に従って分析を行った．

図1　三色ボールペン法で要求仕様書を分析した様子

―― どのように役割を分担したのですか？

酒井氏：私が「設計者」の立場から設計情報をインプットし，名野さんが「テスト担当者（テスタ）」としてテストを設計しました．舘さんは，組み込みシステムの専門家としてアドバイスしてくれました．

舘氏：酒井さんと名野くんは，仕様と設計の面からテストの観点を抽出していたのですが，それだけでは組み込み特有の観点が出てきにくいと感じて口をはさみました．組み込みシステムというのは物理現象を扱うので，物理法則に反したことはあってはなりません．また，今回の対象システムは電子ポットですが，センサやアクチュエータを扱うということは，それらの性質に反したこともあってはなりません．そこで，抽出されたテスト観点に，物理現象やデバイス制御，ユーザビリティという観点を追加し，組み込みシステムの信頼性，安全性を損なわないための項目を追加しました．

―― 「テスト設計」といっても，どうやって進めていけばよいのか戸惑うことはありませんでしたか？

名野氏：そこは，「ゆもつよメソッド」^注2（3）と呼ばれているテストの上流設計の実践方法がありまして，その方法を参考にしながらテストの分析・設計を進めました．具体的には，全体のテスト計画を立て，確認したい品質から典型的なテスト・タイプ（どんな種類のテストを行うか）を選び，テスト・カテゴリ（どんな観点でテストを行うか）を抽出しました．また，テスト分析マトリクス（横軸にテスト・カテゴリ，縦軸に機能を並べた表）を作成し，各機能をどのような観点でテストするのかを整理しました（図2）．参考にできる実践方法があったおかげで，それほど迷わずにテスト設計を進められました．

注2：湯本 剛氏が提唱している，テストの上流設計（テスト目的の設定，テスト分析，テスト設計）の方法．

図2　テスト分析マトリクスの例

―― ほかのコンテスト参加チームと比較して特徴的だったのはどのあたりでしょうか？

酒井氏：思い入れはメンバそれぞれで異なると思いますが，私は，システムの分析モデルをテスト担当者向けに作成したことだと思います．実は以前から，「テスト担当者が欲している情報と，設計者が出している情報にはギャップがあるのではないか」と感じていました．設計資料をテストで使っているという話をあまり聞かないので，設計者とテスト担当者が連携するには何か問題があるのではないかと思ったのです．そこで今回は，設計側が出す情報として，要求仕様書を基に「システム分析モデル」を作成してみました（図3）．このモデルは，システムを設計できるレベルの詳細さではなく，テスト担当者が状態遷移図を作り，テストするのに十分なレベルをねらいました．

図3　テストのための分析モデル

名野氏：後は，先ほど出てきたように，物理現象や安全性，信頼性といったテストの観点を出せたことでしょうか．

―― テスト設計をしてみて，いかがでしたか？

名野氏：これまではなんとなくテスト項目を作っていたのが，いろいろな観点を整理できて，テスト設計をやっておくと良さそうだというのが見えてきました．何をテストしたいのか，というテストの目的と，テストの観点のつながりが頭の中で整理でき，成果物になったのが大きいです．

酒井氏：テストって，目的志向の一点突破だなあと思いました．開発の作業は，要求仕様をいったん理解し，飲み込んでから，どうやって作ろうか？ と考え方を90度くらい変えて展開していきますよね．その中で，あ，これはもれそうだな，と思ったものは拾い上げていく．

名野氏：テストもそれは同じだと思いますよ．テストは目的を決めて，コンセプトを決めて，最終的にはテスト・ケースに落として実施します．でも，リソースが有限である中で，すべてを網羅できるわけではない．テスト項目を最小限に抑えつつ，テストのもれは出さないように判断してやっていかなくてはなりません．

舘氏：設計者は「ちゃんと動く」ことを意識して設計するけれど，テスト担当者は「使える」ことを意識してテストする．その意識の違いはあると思います．「とりあえず動く」ものを作るのではなく，ソフトウェア工学によって「使えるもの」を作れるようにしたいですね．

参照・引用*文献
（1）*齋藤 孝；『三色ボールペン情報活用術』，角川書店，2003年6月．
（2）鈴木 三紀夫；第10章 三色ボールペンで読む仕様書，『ソフトウェアテスト入門』，技術評論社，2008年5月．
（3）湯本 剛；特集1 今こそ聞きたいテストの上流設計，『ソフトウェア・テストPRESS Vol.10』，技術評論社，2010年9月．