********************************************************************** セッション S5-a 分科会3 テーマ：テストの戦略を立ててみるテストコーディネータ：片山徹郎（宮崎大学）講師：池田暁（日立情報通信エンジニアリング）森孝夫（三栄ハイテックス）西康晴（電気通信大学）参加者：32名ほど ********************************************************************** ■要旨携帯音楽プレイヤーの仕様書から個人でテスト項目を作成し、それをグループワークで１つのテスト戦略を練る。この過程でテスト戦略を立てることの難しさやテスト戦略を立てるのに必要なものを考える。またグループ発表会でほかのグループのノウハウを得る。内容：・携帯音楽プレイヤーの仕様書の配布・個人によるテスト項目の作成（マインドマップの形式）・グループでのテスト項目の議論とテスト戦略の作成・グループによるテスト戦略の発表 ■内容(時系列) 15:15 開始 #チュートリアルが５分伸びたため、繰上げ 15:20 15:30までテスト項目を作成する時間を延長 15:23 仕様書から得られる情報は限られているので違った観点から考えることが重要とアドバイス 15:33 近くの人ととっかえっこして書いた情報を見比べる。 15:40 グループ分け。グループワーク開始 15:42 チーム名をつける。グループ全体が合意するものを作ること。 16:10までグループワークとのアナウンス 16:13 16:30までグループワーク延長 16:34 完成版の写真撮影と発表者の決定 16:41 グループ発表の開始（以下は発表の応答内容） 17:07 終了 # G:グループの発表者 C:司会者 P:質問者 ----1つ目のグループ---- チーム名：きめてない G1：テスト環境をどうしようか。専用の試験機で行うのか？入力データの妥当性を調べる。イリーガルなデータの入力。ボタンの長押し、短いなどまたは同時押し。機能要件を状態遷移表で動かして網羅する。 PC接続時のチェック。 USB、WINのバージョン。音、表示の出力のチェック。それらを基準をきめてチェック。最終的にはいろいろな項目はあがったが、戦略としてまとめるとあまりあがらない。 C:質問等はありますか？ P：図の形にまとめなかったのはなぜか？ G1：項目を挙げていくうちに仕様ヌケがおおく、仕様のバグとかを指摘する場ではないので、細かいことよりはできることを列挙していったほうがよいと考えた。 P:この後に状態遷移表を書こうとしていたんですよね？ G1:そうです。 C:この形の一覧表は一番ファンダメンタルな形である。比較的とっつきやすい形である。良いところは入力データの下にイリーガルデータの項目がある。よくあるのは異常系のデータがもっと上にある。ほかの人が何を考えているかわかった？ G1:聞けば聞くほどわからないというのを実感 C:テスト作成はすごく簡単そうに見えてすごく難しい。こうやって書き出すことによってみんなが違うことを考えていて、相手の考えていることはなかなか理解できないというのがわかったのが大きい。これは非常に重要です。テストを考えると目の前の細かいことつっこんでしまう。テスト戦略を考えるときは深さ優先探索してはいけない。全体的なテストを作らなければならない。 G1：細かいところに何度もいきそうになった。マインドマップで拡散してしまった。 C:そうですね。ファンダメンタルなやりかたを採用して共通理解度がそんなになくてもできるようなやりかたを示してくれた。戦略を立てるときの難しいところを示してくれたところがいいところである。 ----16:51 2つめのグループ---- チーム名：ザ・スーパー？テスターズ G2:戦略になかなかいきつけない。考えの共有が難しい。戦略をまとめるためにユーザからの観点からはじめる。仕様書に短押し、長押しの時間が書いてない。全体として、マインドマップとしてまとめ。それをもとにここから戦略としてまとめられるようにした。 C：何か質問等はありますでしょうか？はい、イケメンテスターズのかたどうぞ。 I:マインドマップをつくるとどんどん増えていくパターンかなぁとお見受けしました。ここから戦略を立てるときはここからどのカテゴリーに入るのか、抽象化、階層化することが必要。思考経路としては、項目をたくさんを出したあとにカテゴライズの順番であると思いました。 C:仕様理解と仕様制御の場所と、非機能要件がある。全体としてユーザという方面から PC接続と操作と非機能の３つで捕らえている。その意味で見やすいマインドマップである。仕様理解に重きを置いてる。その点がいい。 ----16:57 3つめのグループ---- チーム名：きめてない G3:まずみんなのマインドマップを見比べて一番よく書かれていたものをベースにしてまとめる。（渡された仕様書の）携帯音楽プレイヤーを使うにあたって一番重要なことをあげてみた。そこから具体的にはどんなことがあるのか下の階層であげた。最終的には基本的にユーザーが使うのに何が大切なのか考え、音楽が聴けることを重点にまとめた。非機能要件にメンテナンスのしやすさをいれた。簡単にバージョンアップできるように。 C:みなさんから質問がありますでしょうか？ P:大項目が多いが、ある意味バランスが取れている。 C:テスト設計としてみたときに全体のバランスがよい。その後から考えやすい。 ----17:01 4つめのグループ---- チーム名：セロテープ G4:お客さまの視点でどういうことに問題があるか考えた。たとえばノイズがでるとかデータ消えるとかは非常にまずい。回収騒ぎになる、企業としてまずいところを考えた。充電ができないとか、 PCと接続できないとか、ひとつエラーがあったために全体がダメになってしまうというとこの視点。メンバーのなかで補強したんですが、ユーザビリティの視点。応答性、性能とか。あとユニバーサルデザインの視点、たとえば左ききの人でも使えるのか。環境要因として温度、湿度その他いろいろ。最後に機能として抑えておくところ。 C:みなさんから質問とかありますでしょうか？ P:ユーザビリティの視点はおもしろいのですけど、データ異常とか充電できないとかテスト作る人はどういったアプローチをするのか想定されているのか？ G4:視点としてどういったところをやるべきか。非機能をまとめた。 C:お客様が困るという視点からどんどんブレークダウンしているところ。ユーザビリティなどのソフトウェアが何が満たしてないといけないかが分析されていてよい。今までのチームはテストとしてどんな操作をしないといけないのか、どんな条件にしないといけないのかが多かった。このチームは製品の非機能特性が十分分析されていて良かった。 ----17:06 まとめ---- C:時間が短かったのでなかなか突っ込めなかった。しかし、それぞれのチームで特徴のあるいいテスト戦略を立てていた。グループワークでは一人ひとりの意見を一枚に集約した。次にグループごとに発表会をすることでほかのグループのいいノウハウが出てきた。会社に帰って自分のチームでテスト戦略を書き出してほかのチームと比べたり、楽しんで褒めあう会を持つといいと思います。 17:07 終了以上議事録。