NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'12 Niigata

13:10～14:40
基調講演
「仕様ベースのソフトウェアテストを上手に進めるには ～明文化された要求仕様に対して漏れなくテストするための観点とは～」
大西 建児氏 (ガイオ・テクノロジー)

ガイオ・テクノロジーでエバンジェリストを務める傍ら、業務とは別にASTERやJSTQB(Japan Software Testing Qualifications Board)などで積極的に活動されている大西 建児氏による仕様ベースのテストにフォーカスした講演。
冒頭、「今回は難しい話はしません。」という一声とともに始まった。まず、講演内容がより伝わるようにと、同氏がJSTQBの技術委員会で副委員長を務めるISTQB(International Software Testing Qualifications Board)の用語を用いて、講演内で登場するキーワードについて説明を行った。
ソフトウェアテストにおいては、まだまだ組織間で別の用語が使われている場合もあり、この導入は参加者の理解を深めるのに非常に効果的であると感じた。
仕様ベースのテストの難しいポイントとして、同氏は以下の4つの観点を挙げた。

• あいまい　なテスト
• ごちゃごちゃ　なテスト
• いっぱいありすぎ　なテスト
• ちんぷんかんぷん　なテスト

これら4つの観点について、それぞれまず同氏が課題となる実例を挙げ、参加者もそれぞれの観点に当てはまる自分の現場での課題を考え、そうならないように対応するヒントを与えてくれた。
特に、「あいまいなテスト」になる原因としてテストベースのあり方について、自然言語(日本語)を用いる難しさを解説した内容は、参加者が特に興味を持って聞いているように感じた。これは、同じように現場で苦労しているエンジニアが多いということであろう。
ただでさえ自然言語にはあいまいさが付きまとうが、中でも日本語は特にあいまいな側面をもった言語であるということで、そのために「言葉を尽くさなければならない」という同氏の説明がとても印象に残った。
また、「ごちゃごちゃなテスト」については単純にトレーサビリティの確保、テストベースの質を上げるといった対策にとどまらず、昨今の複雑な仕様を記述したテストベースの読み方やモデリングについても解説いただいた。
その他の観点についても、先に参加者それぞれの現場での問題点を考えた上で説明を聞くというスタイルであったため、私もより理解を深めることができた。
最後に、「仕様ベースのテストではテスト対象への『好奇心』が欠かせない」という、同氏の思いが込められたメッセージをもって基調講演は終了した。

冒頭、難しい話はしないと宣言された通り、説明の中に難しい言葉は意図的に使用されなかったが、分かりやすい言葉を用いて、現場でありがちだが簡単には解決できていない課題を一つずつ説明し、そこから抜けだす方法を解説いただけたのは、参加者が明日から現場で行う活動へいい影響を与えるヒントとなったに違いない。

14:50～16:25　
演習付きチュートリアル
「マインドマップを用いたテスト要求分析・設計エクササイズ」
鈴木 三紀夫 （MRTコンサルティング）

「マインドマップから始めるソフトウェアテスト」の著者である鈴木 三紀夫氏によるチュートリアルセッション。
他のセミナーなどでも、マインドマップを用いたテスト分析/テスト設計テーマにした講演を数多くこなす同氏は、今回、時間の都合もあり、ある取り組みを行った。
通常は3時間コースで行う同セッションを、今回の95分に合わせて、マインドマップを書く対象を、このセッション全体とするという取り組みである。
つまり、参加者は特定の演習に対してマインドマップを活用するだけでなく、同氏のセッション内容をマインドマップに書いていくということになった。
最初に、マインドマップの書き方と3色ボールペンを用いた手法の説明があり、そこからすぐに実践開始となった。
最初は、何から、どれくらいまで書けばよいのか戸惑う参加者の姿も一部見られたが、同氏の「本当にやりたいのはきれいなマインドマップを書くことでなく、良いテスト設計ができること。なので、きれいに書こうと思わなくて構いません。」という一言で、私も含め参加者はスムーズに書き始めていくことができた。
セッションの内容としては、

1. 自分の組織におけるテストケースの現状整理
2. 自分の組織におけるソフトウェアテストプロセスの現状整理
3. 例題のソフトウェアに対するテストマインドマップを用いて考える実践

という順序で進められた。
テストケースについての解説では、同氏の経験からこれまで見てきた「よくないテスト設計」の事例も紹介され、私も一度は見たり聞いたりしたことがあるアンチパターンもあったが、それだけに同じような問題を抱えている組織が他にもあることを実感することができ、また話に引き込まれた。
多くはテストケースの作成の前にテスト設計を十分に行えていない(行おうとしていない)のが問題ではあるが、技法などを使ってテスト設計を行えばすぐに解決できるのかというと、それだけでは解決しない場合も多いという。
その理由が、２．のテストプロセスの話に深くかかわってくるとのこと。
「テスト設計が必要です。」とテスト設計自体の重要性を理解してそれを訴えたとしても、自分たちの組織のテストプロセスを正しく理解できていないと、これまでやってきていない(もしくはちゃんとやれていない)テスト設計を組み込んだテストプロセスへ移行することは容易ではないということである。
確かに、私の経験でもテスト設計技法の話を聞いたり、勉強したりしてもそれがなかなか現場で活用されないという話はよく耳にする。その大きな原因の一つが、テストプロセスの理解にあると同氏は解説した。
テストプロセスの話では、テストプロセスを定義もしくは理解する場合にはなるべく詳細化した方が改善する箇所が明確になるため、よりテスト設計の適用がしやすくなるといったことや、テストプロセスを図で表現しようとする場合には、「計画」を左端に書くよりも、「計画」は中央に書いてそのまわりに「(テスト)設計」や「(テスト)実行」といったプロセスを書いた方が、計画をトレースしたり見直したりする上で意識的にも違ってくることなどの説明があった。
そして、最後は「西暦和歴変換機能」という架空のシステムを題材にして、マインドマップを使用したテスト設計の実践が行われた。
私も含め参加者は、ここまでのセッションの内容をマインドマップで書くことをしていたため、この演習が始まったときにはセッション開始当初とは明らかに違い、早々に手を動かしてマインドマップを書き進めることができていた。
その後、書き上がったものを周りの参加者と見比べながら「何でこれが出てきたの？」とか「それがあったかー」といった声が会場内のあちこちで上がっていた。

今回のチュートリアルでは、マインドマップの書き方にとどまらず、それらを用いて行ったテスト設計を、実際に現場に適用するにあたって考えるべきことにも注力して解説いただいたため、本来の意味でのより実践的な内容であったと感じた。
また、今回のチュートリアルで行ったセッション内容自体をマインドマップで書いてみるという取り組みは、テスト設計演習の際にスムーズにマインドマップを書き始められたことや、情報交換会でも参加者がそれぞれに書いたマインドマップを持ち寄り、議論していた姿を見てもとても効果的な進め方の一つであったと感じた。

16:30～17:15
事例発表
「新潟ソフトウェア開発勉強会『すわにい』の活動」
齋藤 達也 （新潟ソフトウェア開発勉強会）

新潟で初めて行われたソフトウェアテストシンポジウム(JaSST'11 Niigata)をきっかけに立ち上がったという「すわにい」という勉強会による事例発表。
発表は、同勉強会に参加している齋藤 達也氏によって行われた。

「すわにい」は、月に一回集まって読書会やソフトウェアに関することをテーマに議論を行っているということで、今回の発表は同勉強会がテーマとして取り上げて行った「話題沸騰ポット」のテスト設計についての発表であった。
話題沸騰ポットを題材にしたテスト設計については、JaSSTの主催団体であるASTERが「テスト設計コンテスト」として全国規模でコンテストを開催している(https://aster.or.jp/business/contest.html)が、今回は時間の都合もありコンテストにはエントリーしなかったとのことであった。
「すわにい」では、「話題沸騰ポット」のテスト設計を行うにあたって特に「利用者の安全」にフォーカスして、テストで漏れをなくす方法を検討したということで、実際に行った方法が紹介された。
テスト分析を行うにあたって、

• 作り手の思い込みを排除するため、敢えて「要求仕様」を見ずに「取扱説明書」を元に一般的な使い方のフローを作成
• さまざまな利用者をアバターとして考え、具体的な使い方を想定
• 先に作成した一般的なフローと、アバターによる想定される使い方の差異を抽出し、アバター別フロー作成

という形で進められたということであった。
このさまざまな利用者を想定するにあたり、ブレインストーミングを行った中で挙がったものもいくつか紹介されたが、その中で「ポットでアロマオイルを楽しみたい」など、私ではとても考えが及ばないものもあり勉強になった。
次に、このアバター別のフローを元に、最初に敢えて見ることをしなかった「要求仕様書」をこの段階で見ることで、最初に読んでいたら気付かなかったかもしれない要求仕様書における不明確なポイントを抽出できたという効果が得られたということであった。
次に、テスト設計では、アバターリストとフローより「利用者の安全」に対する観点をマトリクスにして、テストできる所まで落とし込むという方法で行われたということである。
あるテスト対象に対して特に注目すべき観点を決めて(今回のケースでは「利用者の安全」)、それをテストケースまで落としていく一つの方法を見せてもらえたのは、参加者にとってとても参考になった。

私は、新潟で初めてJaSSTが開始されて以来3年間欠かさず参加しているが、JaSSTをきっかけに企業組織の枠を超えた勉強会が立ち上がり、その勉強会の中で独自の方法を考え出し、それをまたJaSSTで発表することで参加者に影響を与えるというこの実績を目の当たりにして、改めて、テストエンジニアの持つパワーと、それを引き出すコミュニティ活動の影響力に感動を覚えた。