テストエンジニア時代の悲喜こもごもが今のわたしを作った

「WACATE 2012 夏」参加レポート(その1)――組み合わせ全部テストするなんて無理ですから

»

 こんにちは、第3バイオリンです。

 もはや恒例行事となっておりますが、この夏もソフトウェアテストワークショップ「WACATE 2012 夏」に参加してきました。

 実は今回、参加申し込みした時点では求職中(つまりテストエンジニアとして働いていない状態)だったので、本当に参加して大丈夫なのか、ワークについていけるのかどうか、不安がありました。しかし、2日間参加してその不安は杞憂に終わりました。今回も、多くの気づきを得ることができて、参加してよかったと思いました。

 それでは、参加レポートをはじめたいと思います。

■日時と場所

日時:2012年6月30日〜7月1日
場所:マホロバ・マインズ三浦(神奈川県)

■テーマ

 今回のテーマは「禁則にときめけ! 無則にひらめけ!」テストの基本のひとつである「組み合わせテスト」について、深く掘り下げる2日間となりました。

■ポジションペーパーセッション

 オープニングのあとは、ポジションペーパーセッションです。5〜6人でグループになって、申し込み時に作成したポジションペーパー(立場表明書)を使って自分自身について3分間でプレゼンを行います。

 ポジションペーパーには自己紹介だけでなく、テストに対する想いやWACATEに参加した目的、参加者の皆さんと議論したいことなどを思い思いのスタイルで書き込みます。

 しかし今回のわたしは参加申し込み時に求職中だったこともあり、あまり積極的なことを書けませんでした。WACATE当日には再就職先が決まっていたので、そのあたりはプレゼンでフォローしましたが、ポジションペーパーだけを見ると少し動機が弱かったかもしれません。

 ただ、その辺りも含めて、今の自分が出るところなので、それはそれでいいのかもしれません。今回を含めて5回参加しているので、一度、過去のポジションペーパーを読み直してみようかとも思いました。

■BPPセッション「WACATE365日徹底活用術〜組み合わせて一歩前へ、そして世界へ〜」

 前回の「WACATE 2011 冬」でベストポジションペーパー賞(Best Position Paper賞)を受賞した藤崎 祐美子さんのセッションです。

 藤崎さんは、会社では品質保証関連の部署に所属しています。今年5月にその部署が発足するまでは、いろいろな部署を回ってきたそうです。

 藤崎さんがテストの勉強を始めようと思ったきっかけは、どうしても出せないバグがあり、それが悔しくてテストの本を読んだことでした。

 そうして勉強会にも参加しているうちに、勉強したことを社内に展開したくなり、なんとテストの全社研修を立ち上げてしまったそうです。このとき、いろいろな部署で仕事をしていたことが役に立ったそうです。藤崎さんは、たとえ不本意な異動があったとしてもその部署で得られることは必ずあるし、それが役に立つときがくる、だから腐ったりしないでほしいと話しました。

 藤崎さんは「自分には特別な技や強みがあるわけではない。だけど、自分の成長に自信が持てたのはWACATEにそういう仕組みがあるからではないかと思った。」と語りました。

 そして、このセッションを通して、WACATEでお世話になった方に感謝を伝えるとともに、若い世代にバトンタッチするための「WACATE活用術」を伝授してくれました。

 藤崎さんの「WACATE活用術」のポイントは3つです。

  1. みんなの力を組み合わせて加速
  2. 気づく、考える、発信する
  3. 世界へ視野を広げてみよう

 まずは「みんなの力を組み合わせて加速」です。

 藤崎さんはWACATEを通していろいろな人と知り合い、多くのチャンスに恵まれました。大学のゼミで講義を依頼されたり、シンポジウムの実行委員に入ったりと活躍の場が広がっていったそうです。

 また、社内で全社研修を立ち上げたことで、自分自身の勉強にもなり、社内の情報が集まるようになったそうです。

 社内外の活動について、藤崎さんは「ひとりではここまで来られなかった。他の人と力を合わせれば誰でも加速することができる」と語りました。

 次は「気づく、考える、発信する」です。

 藤崎さんは「気づいてしまったらこちらのものだ」と語りました。気づいたらとにかくやってみる、考えてみればいいのです。もしくじけそうになったら、WACATEの仲間を頼ればいいのです。そして、やったことや考えたことをブログでもSNSでもいいから発信するのです。発信するということは、単に自分の知識や経験そのものを伝えるだけでなく、「こういう考えを持つ人がここにいる」と光を発することでもあります。すると、必ず助けてくれる人が現われるのです。

 また、自分の活動、学んだことや思ったこと、気になったことなどを記録するのもいいと語りました。記録することで、自分の軸が見えるようになります。また、自分が少しでも変化し、成長する様子がわかるようになります。それが自信につながるのです。それに、そのとき直感的に気になったことは、あとで必ず必要になることが多いのです。

 最後は「世界へ視野を広げてみよう」です。

 藤崎さんは、「日本で世界がどういう立場にあるかを考える」と語りました。これは、自分自身が会社でどういう立場にあるかを考えるうちに、この考えに至ったそうです。

 藤崎さんは、世界の「今」に触れることが大切、と語りました。自分が知りたいと思っていることが日本では話題になっていなくても、世界に目を向けてみれば、誰かがすでに始めていることもあります。そこに飛びつけば、自分が日本初になれる可能性だってあるのです。

 しかし、やっぱり気になるのは英語の壁です。それについて藤崎さんは「論文やプレゼンの英語はそれほど難しい言い回しはなく、文法的にいえば意外と簡単」と述べました。それでなくても、英語が必要になる日は突然やってくるものです。

 最後に藤崎さんは「最初の一歩を踏み出すことが肝心、踏み出してしまえば、あとはWACATEが自分を動かしてくれる。参加者の皆さんには、この2日間でお互いの良いところを見つけあい、伝えあってほしい。そして、お互いの力で自分たち自身だけでなく、WACATEというコミュニティを加速させてほしい」と締めくくりました。

 わたしもコラムの記事がきっかけでいろいろなことにチャレンジする機会に恵まれました。そのため「気づく、考える、発信する」のくだりは特に共感しました。また、藤崎さんは「自分には何もない」とおっしゃっていましたが、この行動力はすばらしいです。行動力のある人にはチャンスのほうから飛び込んでくる、ということがよくわかる内容でした。

■セッション「組み合わせテスト設計はじめの一歩」

 WACATE実行委員の井芹 洋輝さんのセッションです。

 まず、組み合わせテストの定義と、そもそもなぜ組み合わせテストが必要なのか、から始まりました。

 井芹さんは、組み合わせテストの例としてラーメンのメニューの話をしました。たとえば、麺の固さ、トッピングの具、スープの味を自由に組み合わせてラーメンを作ることを考えてみましょう。麺とトッピングがそれぞれ10種類、スープが3種類あるとして、すべての要素を組み合わせると、ラーメンの数はいくつになるでしょうか。

 10(麺の固さ)×10(トッピング)×3(スープ)=300杯

 1日3食、毎日ラーメンを食べたとしても、すべての組み合わせを試すには3ヶ月以上かかります。そんなにラーメンばかり食べていたら栄養が偏って体を壊してしまうかもしれません。これでさらにそれぞれの要素の種類が増えたり、組み合わせの要素が増えたりしたら(例:サイドメニューとの組み合わせも考える)、組み合わせ数は爆発的に増えることになります。

 そのため、限られた時間と人員で現実的なテストをするためには、すべての組み合わせからいくつかをピックアップする必要があります。しかし、やみくもにピックアップすれば、特定の組み合わせのテストが甘くなる危険もあります。どうすれば、まんべんなく組み合わせを試せるテストができるのでしょうか。

 井芹さんは、現実の仕様はもっと曖昧で複雑なので、そこから適切な組み合わせを選ぶには、分析や設計に工夫が必要、と説明しました。

 その工夫のために必要なものが組み合わせテストです。このセッションでは、組み合わせテストの基本的な用語についての説明が主でした。

 たまに「組み合わせを全部テストすればいい」という言葉を聞きますが、ラーメンのたとえ話でそれがどれだけ非現実的なことなのかがわかりやすかったです。

■セッション「組み合わせテスト設計はじめの一歩 ―デシジョンテーブル、ペアワイズ、直交表の第一歩―」

 WACATE実行委員の近江 久美子さんのセッションです。

 井芹さんのセッションで基本を押さえたあとで、組み合わせ技法の説明となりました。

 主な組み合わせテストの技法には3つあります。

  • デシジョンテーブル
  • ペアワイズ
  • 直交表

 これらを状況にあわせて、うまく使い分けることが肝心、と近江さんは説明しました。

 まず、条件が複雑な場合はデシジョンテーブルが有効です。デシジョンテーブルは、JISでも「決定表」という名で登場します(JIS X 0125)。

 デシジョンテーブルは、複数の項目が関係する論理的な条件を整理するときに便利です。また、テーブルが大きくなりすぎた場合、動作に影響を及ぼさない条件がある列を圧縮して簡単化することができます。ただし、誤って圧縮したらテストに漏れが生じてしまうので、そこは注意する必要があります。

 次に、組み合わせの数が多すぎる場合はペアワイズ、直交表が使えます。ペアワイズであれば因子と水準(ラーメンで言うと「麺」「スープ」「トッピング」などが因子、各因子の種類(スープでいうなら「味噌」「しょうゆ」「塩」など)が水準)を入力すればテストケースが作れるツールもあります。

 しかし、ペアワイズは登場回数の多い水準と少ない水準が出やすいというデメリットがあります。水準の登場回数に偏りを持たせたくない場合は直交表のほうが便利です。

 直交表は水準をまんべんなくテストするには便利ですが、禁則(成立しない組み合わせ)がある場合、それをうまく回避しないと実行できないテストケースを作成してしまったり、テスト漏れが発生したりすることがあります。

 テスト技法にもそれぞれメリット、デメリットがあるので使い分けが肝心なのです。

 最後に近江さんは「技法は先人の知恵です。もし現場でそのまま使うことができなくても、技法で必要な考え方、注意点を学んで生かすことができます」と締めくくりました。

 いざ技法を学んでも、自分の現場では使えない、使う機会を与えてくれない、ということは多いと思います。わたし自身にも経験があります。ただ、技法の考え方は必ず応用できるという言葉にはハッとさせられました。技法の勉強は一度学んでおしまいではなく、定期的にやったほうがいいのかもしれません。

◇ ◇ ◇

 「WACATE 2012 夏」参加レポート第1弾はここまでです。次回は、1日目の後半の様子をお届けする予定です。

Comment(5)

コメント

真っ赤なレモン

テスト対象が何かにもよりますが、品質工学が使える場合もありそうですね。
テストの組み合わせを減らす方法として。

「禁則にときめけ! 無則にひらめけ!」は、良い言葉ですね。
守破離。使えるものはありがたく使わせてもらうが、現状に合わないものは次のパラダイムに作り替えろ。全く無いなら作れ。
ということなのかな?

真逆にすれば問題が分かりやすく表現されてしまうのかな。
「禁則は絶対。無則はお手上げ」
守守守、の現状維持で、前例が無いと何もできませーん。

第3バイオリン

真っ赤なレモンさん

コメントありがとうございます。

>テスト対象が何かにもよりますが、品質工学が使える場合もありそうですね。
>テストの組み合わせを減らす方法として。

はい、それも多分あると思います。

>「禁則にときめけ! 無則にひらめけ!」は、良い言葉ですね。
>守破離。使えるものはありがたく使わせてもらうが、現状に合わないものは次のパラダイムに作り替えろ。全く無いなら作れ。
>ということなのかな?

もともと、禁則と無則は組み合わせテストの基本用語です。
禁則とは、実現することができない(ゆえにテストできない)組み合わせのことです。
また、無則とは、互いに因果関係のない組み合わせのことです。
(反対に、組み合わせによって出力に影響を与えるものを有則といいます。
この辺りは本文で説明を割愛してしまいました)

組み合わせテストをしていると、特に禁則の扱いって難しいんですよね。
禁則が残っていると、その組み合わせを含んだテストケースがすべて無効になってしまうので。
私にも、作成したテストケースに禁則が残っていて、ほとんどのテストケースが実行できなかった、という苦い経験があります。

そこに、今回のテーマはハッとさせられました。
組み合わせテストをうまくやるコツはここにあるのかもしれません。

真っ赤なレモン

回答ありがとうございます。

おお、専門の用語なのですね。
一般的な言葉だと誤解して解釈していました。

とすると。直感的にはこうかな。
・有則は、組み合わせを減らすことにはつながらない。
・禁則は、因子や水準から除外でき、組み合わせを大幅に減らすことにつながる。
・無則は、組み合わせを分けることに使え、組み合わせを大幅に減らすことにつながる。

なので、禁則や無則を見つけると、テストが楽になって幸せ!

第3バイオリン

真っ赤なレモンさん

いえいえ、禁則/有則/無則は組み合わせの性質であって、
そのような組み合わせを作る、というものではありません。

禁則については、例えばひとつの機能を選択とき、自動的にグレイアウトしたり、選択肢が隠れたりしたりして選べなくなる機能がありますよね。
例えばWordの文字飾りは「下付き」を選んだとき、「上付き」を選べません。これらは同時に選ぶことが出来ない機能です。
この「下付き」「上付き」が禁則の関係になります
これは組み合わせを減らすためにそのような仕様になっているわけではありません。

有則/無則についても、組み合わせの性質ですから
組み合わせの結果がどのような性質を持つのかを考えつつ、テストケースに反映させる必要があります。

コメントを投稿する