********************************************************************** セッション S5-b テーマ:テストの戦略を立ててみるテスト Returns! コーディネータ:片山 徹郎(宮崎大学) 講師:池田 暁(日立情報通信エンジニアリング) 森 孝夫(三栄ハイテックス) 日時:2008/9/5 15:00〜17:00 参加者:約20名 ********************************************************************** ◆ 概要 グループに分かれて次の1.〜4.を行う。なお、1グループ当たりの人数は4〜5名。 1. 自己紹介の内容をマインドマップで作成し、それを基に、グループのメンバ に対して自己紹介を行う。。 2. 配布された仕様書(簡易携帯型シリコンオーディオ : tPod nano)を基に、 テストの設計を、マインドマップを用いて個人で行う。 3. 上記の2.で作成したマインドマップを各グループで集約し、1つのマインド マップを作成してテスト設計を行う。 4. 上記の3.の結果を各グループ毎に発表する。 ◆ 内容 ============================== 1. 自己紹介 ============================== ・司会の方による説明 > マインドマップを実際に作成してもらいます。 > グループ内には色々な立場の人がいますが、フェアな立場で行って下さい。 > まず、自己紹介の内容をマインドマップで書いて下さい。 ----- マインドマップの作成開始 ----- ・作業の様子 > 自己紹介の内容を、マインドマップを書いて考える。 > 作業時間は5分程度。 ・司会の方によるアドバイス > 右ばかりが埋まってスペースがなくなってしまった人は、線を左の方に持って きて空いた所を使って下さい。空いてる所は全て使う。線でつながっていれば 別に問題ないです。 > 右ばかり使っていると思ったら左を使うようにして下さい。四方八方にという ことを意識して下さい。 > ある程度書きあがった人は、書きあがったもの全体を見回して、この中でこれ は時間をとってしゃべろうかな、というように簡単な優先順位を意識してみて 下さい。 > 別々のブランチから出ている内容が、これとこれは一緒に喋るといいんじゃない かと思うものもあるかもしれません。そういったものは矢印でつないであげる、 といったことをして下さい。 ----- マインドマップの作成終了 ----- ・司会の方による説明 > 最初にグループでジャンケンをやって一番強い人を決めて下さい。その人から 始めます。 > 一番勝った人から時計回りに進めていきます。 > 自分の今書いたマインドマップを話のネタにしながら、一人1分から2分を目処 に自己紹介をして下さい。 > 一人喋り終わったら、全員でその度に拍手をしてあげて下さいね。 ----- 自己紹介開始 ----- ・作業の様子 > ジャンケンをして一番勝った人から時計回りに自己紹介を行う。 > 作成したマインドマップをもとに自己紹介。 > 自己紹介の内容は、出身、経歴、現状、趣味 など。 > 一人自己紹介が終わる度にグループ内の全員で拍手。 > 一人当たり2分か3分程度。 > 自己紹介が一通り終わったら他のグループが終了するまでフリートーク。 ----- 自己紹介終了 ----- ・司会の方によるコメント > 結構皆さん打ち解けて、いい感じの雰囲気になってきましたね。 > マインドマップはこんな感じで書くんだな、と実感してもらえたと思います。 > 書いたことで説明がしやすくなったんじゃないかなと思います。 > 必ずしもマインドマップを見ずとも、こういう順番で確か考えたな、という ようなことが、メモ帳などにリストして書いたときよりも残っているんじゃない かなと思います。 > 自己紹介のマインドマップをやってみると、この人がこれを喋るときにどういった 思考で喋っているんだろうな、ということが絵として見れるので、より深く頭に 入ってくる、すんなり心に入ってくるという効果もあるんじゃないかなと思います。 新しくつくったチームのキックオフなどでこういう取り組みをされるのもいいんじゃ ないかなと思います。 ============================== 2. テスト設計(個人) ============================== ・司会の方による説明 > それでは分析と設計をマインドマップでやってみましょう。 > いまから仕様を皆さんにお配りします。 ----- 仕様が書かれた紙の配布 ----- > 皆さん、仕様が一部ずつ配られたかと思いますが、それを基に分析・設計をやって いただこうと思います。 > 渡された紙の情報のみでテストを行わなければならず、その紙について聞くことが 出来る人が誰もいないという状況だと思ってください。 > ですから、この仕様の紙のみを情報源としてテストを行っていかなければなりません。 > 講師などに、この仕様おかしくないですか、といっても一切答えません。そういう 質問は一切受け付けません。 > その、おかしくないですか、といったところもテスト観点である可能性があるので、 それをどんどん整理していくようなかたちで進めていってください。 > これも優劣をつけるわけではありません。観点はそれぞれ違います。たくさん出して 下さい。 > 失敗を恐れずに気楽にやって下さい。途中で、これ間違ってるかもしれないなと 思って書いたことでも、あとで実は重要な意味を持っていたりする場合があります。 > 思いついたことは全て捨てない、これを徹底して下さい。 > 皆さん、それぞれ個人ですよ。隣の人に聞いたり、隣の人の紙を覗いて書いたり しないで下さい。 ----- マインドマップの作成開始 ----- ・作業の様子 > 仕様書を読み、マインドマップを使ってテストを考える。 > 個人で行う。 > 作業時間は15分程度。 ・司会の方によるアドバイス > ある程度まで書いたら、一旦自分が書いたもの全体を眺めてみて、そこから他に ないだろうかと考えてみて下さい。 > ある程度まで書いたら、仕様書は見ずに全体を見直してみるといいです。 ----- マインドマップの作成終了 ----- ・司会の方によるコメント > 問題を見ながら、分析しつつ設計も行うプロセスを体験してもらいました。 ============================== 3. テスト設計(グループ) ============================== ・司会の方による説明 > 今度はグループでテスト設計をやってもらいます。 > 今みなさんが書いたマインドマップをひとつに集約してください。 > グループとしてのテスト設計の結果として、1つの巨大なマインドマップをかいて 下さい。 > できあがったマインドマップはグループの全員の合意がとれたものとしてください。 > 書いたものは最後に発表してもらいます。 > ジャンケンなどでランダムに発表者を決めるので、合意をとっておかないと自分が 当たったときに説明できません。 > 人の話をちゃんと聴き、話し合いに自分も参加して意見をまとめていって下さい。 > 自分の書いたマップをメンバーに説明するといいと思います。 ----- マインドマップの作成開始 ----- ・作業の様子 > 個人で書いたマインドマップをグループごとに話し合いながら1つのマインドマップ に集約する。 > まず、自分の書いたマインドマップを基に、どのようなテストを考えたかを一人ずつ 説明。 > その後、話し合いながらグループとしてのマインドマップを作成していく。 > 最後に、できたマインドマップについて、書いたことや足りないことを全員で確認。 > 作業時間は30分程度。 ・司会の方によるアドバイス > 必ずしも深いところまで落ちていく必要はありません。 > すごいハイレベルな抽象度でも思いついたことは書いてください。 -----マインドマップの作成終了 ----- ・司会の方によるコメント > 他の人の意見を考慮しながらひとつのマップにまとめていくのは難しいところ なんですが、各自がどういうテスト設計をして自分がどう考えたのかがマップとして 書かれているため、他の人のマップを読んで、その人がどう書いたかがわかり、調整 しやすくなるといったところがあります。 ============================== 4. 発表 ============================== ・司会の方による説明 > 各グループでジャンケンをして発表者を決めてください。 > 一番勝った人が発表者ということにしましょう。各班決めてください。 ----- ジャンケンをして発表者を決める。一番勝った人が発表者。----- > 各グループごとに順番に発表してもらいます。 > 前に作成したマップを貼り出しますので、他の班の方たちは前あたりに集まって 発表を聴いてください。 ----- 発表開始 ----- ・発表の様子 > 各グループで作成したマインドマップは前に貼りだす。 > 各グループの発表者が前に出て発表。 > 作成したマインドマップを示しながら発表。 > 発表時間は1グループあたり4〜5分程度。 ----- 1グループ目 ----- ・発表内容 > ユーザが使うことを大前提に考え、操作、表示に重点を置いた。 > 操作、画面の表示、ハード、データ構造というように分けた。 > 操作についてはボタンとスライダ。ボタンについてのテストは、物理的な破損が あるか、耐久性、長押し、チャタリングといったことについて。 > 表示について。液晶についてのテストは、照明の明るさ、照明でうまく見えるのか、 耐久性といったことについて。画面表示についてのテストは、画面が表示されている ときにボタン操作をした結果の画面表示が間違っていないかといったことについて。 > ハードについてはUSB、メモリ、ジャック。ハードについてのテストは、物理的な 抜き差しをする回数、落下に対する耐久性といったことについて。 > データについてのテストは、ファイル名に関して長さ・文字の種類・拡張子、 ファイルサイズ、アーティスト名・曲名・アルバム名の画面表示が正しいかといった ことについて。 ・司会の方や講師の方々によるコメント > あとで考えようとしているところについて、枝だけでも残しておくのはよい。 > 重要なところは色を変えるとあとで目立って見えるのでよい。 > ソフトのテストと出荷時のテストをするのはよい。 > テストの枝が独立しているので、この部分を整理するともっとすっきりした図に なっていた。 ----- 2グループ目 ----- ・発表内容 > まず仕様書ベースに表示や操作をメインブランチとして書き、パフォーマンスなど 自分たちで抽象的な表現を用いて書いたものを併せた。 > 表示についてのテストは、文字数、文字コード、特に日本語表記、スクロールの条件 といったことについて。 > 操作について。ボタンについてのテストは、チャタリング、押し方といったことに ついて。スライダについてのテストは、スライダの位置と音量調節の関係が適切か について。 > 電源ON/OFF、充電中といった状態をマトリックスで整理。電源ONのときに充電すると どうなるのか。 > パフォーマンスについてのテストは、起動時間、USBに対する負荷、チャタリング、 書き換えといったことについて。 > エラーが起きたときにどうやって直すのか。リセット方法はどうなっているのか。 > 扱うファイルの種類についてのテストは、ホストPCのOSごとに適切な動作をするか、 扱えるファイルの拡張子について、mp3以外の音楽ファイルだったらどうなるか、 ファイルサイズといったことについて。 ・司会の方や講師の方々によるコメント > 文字が逆になることは結構起こることで、問題はない。 四方八方から真ん中の紙にみんなで書いて、あとで別の紙に写したりするのはよくあること。 > マトリックスなどの図があるのは、図を見ると一目で書いてあることが分かるので よい。 > 文字は単純なようではまりやすい。 > マインドマップの書き方が一部違う。枝の上に字を置く。 > 異常系の処理のテストをどうやるかの例を書いたほうがよい。 > 抽象度がばらばらで、すごい細かいところもあれば、抽象度が高いところもあるので、 これから整理させて、抽象度の高いところを落とし込んでいくとよい。 ----- 3グループ目 ----- ・発表内容 > まず仕様書にある表示、データについて。 > 表示についてのテストは、再生中・停止中などの状態ごとの表示、起ちあがりのとき の表示に日本語や記号が入っているのはなぜか、文字数といったことについて。 > データについてのテストは、データのフォルダ構成はどうなっているか、サイズが 大きいときはどうなるか、仕様以外のフォーマットについてはどうかといったことに ついて。 > 使用する相手先のソフトについてのテストは、曲の情報、曲順が正しいかといった ことについて。 > ボタンを押したときの状態遷移について。 ・司会の方や講師の方々によるコメント > 絵で具体的に表現しているのは、イメージがし易くなるのでよい。 > あとからもう少し整理して分かりやすいように書いたほうがよい。 > 幹を絵に全てつなげているのはよい > 仕様としてわからないところを残しておいて、次につなげるのがよい。 ----- 4グループ目 ----- ・発表内容 > まず動的構造と静的構造に分けて考えた。 > 静的構造としてボタン、ディスプレイ、スライダ、コネクタ、ヘッドフォン。 > ボタンについてのテストは、普通に押したとき・長く押したとき・短く押したとき・ 連続で押したとき・同時押しをしたときにそれぞれ挙動がどうなるかについて。 > ディスプレイについてのテストは、ちらつきはないか、フォント、見えやすい明るさ かどうかといったことについて。 > スライダについてのテストは、スライダと音量調節の関係が適切かについて。 > スライダとボタンを同時に使ったときにきちんと動作するのか、また、そのときの 挙動はどうなるのか。 > コネクタについてのテストは、USBと異なるコネクタを挿したときに壊れたりしないか どうかについて。 > ヘッドフォンについてのテストは、ちゃんとステレオで音が出るのか、LRが逆に なっていないか、ショートしたものを繋いだらどうなるのかといったことについて。 > 次に動的構造。 > 再生時の状態である再生、一時停止、曲送り、曲戻しの遷移が適切か。 > パソコンとつないでデータを入れるときの相手の環境についてのテストは、OSに 依存するのか、また、どのOSでもちゃんと動くのかといったことについて。 > ファイルについてのテストは、削除ができるのか、サイズは大きいものを入れて 大丈夫なのか、数、フォーマット、ファイル名、ビットレートといったことについて。 > モードについてのテストは、通常再生、シャッフルのモードの切り替えがちゃんと できるのかについて。 > 充電についてのテストは、瞬断と電圧変動が起こったときに壊れないかについて。 > 表示についてのテストは、きちんとスクロールできるのか、点滅もちゃんとして スクロールするのか、アルファベットと数字しか出ないはずなのに初期画面のところ でなぜ日本語が出るのか、充電中の表示はきちんと出るのかといったことについて。 ・司会の方や講師の方々によるコメント > 一番最初に、マインドマップを真ん中に集め、全員で眺めて議論したので、合意形成 が早かった。 > ラフのマインドマップを書いたので、清書のマインドマップはよく整理されていて 見やすい。 > 電圧などもよいテスト観点。 > 著作権管理は重要。 > 静的構造と動的構造に分けて考えると書きやすい。 ----- 発表終了 ----- ============================== まとめ ============================== > 4枚とも特徴的で、こっちにある観点がそっちにはないなど色々な違いがある。これら をさらにマージしてくともっとよい、もれの少ないマインドマップができあがる。 > テストを考えるときに、一人で考えて、その後全員で持ち寄って考えてみると、全員 がテストに関して理解が深くなる。 > こういったことを先輩が行うことで、新人がノウハウを継承できる。 > 教育目的としてもよいツールなので今後とも使用していってほしい。