ソフトウェアテストシンポジウム「JaSST'13 Niigata」開催レポート（その1）――テストを難しくさせているもの
こんにちは、第3バイオリンです。
今年も新潟でソフトウェアテストシンポジウム「JaSST’13 Niigata」を開催しました。今年は実行委員の人数も増え、またプログラムにも初めて演習付きチュートリアルを取り入れるなど、新しいチャレンジもありました。
それでは、さっそく開催レポートをお届けしたいと思います。
■日時と場所
日時：2013年3月15日（金）
場所：万代島ビル11階 NICO会議室
■テーマ
今回のテーマは「上流から始めるテスト開発 ～テスト設計 素（ソ）にして漏らさず～」です。
要求仕様をテストケースまで落とし込むとき、要求の漏れがでてしまう、あるいは余計なテストケースを作ってしまう、と現場で悩むエンジニアは大勢いるのではないでしょうか。どうすればもれなくムダなくテストできるのか。そこで今年の「JaSST’13 Niigata」は、そのような悩みを解消できる場にしたいと思い、このテーマに決めました。
■埼玉在住の新潟の実行委員長
去年の「JaSST’12 Niigata」閉幕後、わたしは新潟から埼玉に移住しました。移住後に実行委員長のポジションをどうしようか、とも考えましたが、いきなり新潟に残るメンバーに全部引き継ぐのはさすがに無理があるだろうと思い、今年はわたしが続投することに決めました。
実行委員の打ち合わせはメールとグループウェアのみで実施しました。もろもろのタスクをどうやって振るか、顔を合わせないで新メンバーが戸惑うことはないだろうかと不安もありましたが、なんとか無事に本番当日を迎えることができました。あらためて、実行委員のメンバーに感謝いたします。
■基調講演「仕様ベースのソフトウェアテストを上手に進めるには ～明文化された要求仕様に対して漏れなくテストするための観点とは～」
基調講演は、ガイオ・テクノロジーの大西 建児さんです。
ソフトウェアテストに関する国際的な資格認定団体であるISTQBの会員でもある大西さん、最初に「今回の講演はISTQBの用語をベースに進めたいと思います」と語り、ISTQBの説明から始めました。
突然ですが「テストレベル」「テストベース」という言葉を聞いて、皆さんが思い浮かべるものは何でしょうか。このような言葉を社内、あるいはコミュニティ内でどのような意味で使用しているでしょうか。意外と、会社や人によって言葉の使い方や意味するところがまちまちなのではないかと思います。
これでは違う会社、違うコミュニティの人とテストについて会話するとき、話が噛み合なくなるおそれがあります。そのため、テストに対する考え方や用語を統一する必要があります。そのための便利なツールとして、ISTQBの資格があるのです（ちなみに、日本の加盟団体であるJSTQBのサイトからシラバスや用語集が無料でダウンロードできます）。
ISTQBの用語の説明がひととおり終わったところで、いよいよ本題の「仕様ベースのテスト」の話に移りました。
「仕様ベースのテスト」というと、なんだか難しそうだと思われる方もいるかもしれません。では、その難しさというのは何からくるものなのでしょうか。大西さんは仕様ベースのテストを難しくする原因として「あいまい」「ごちゃごちゃ」「いっぱいありすぎ」「ちんぷんかんぷん」という4つのキーワードを挙げました。
まずは「あいまい」なテストについてです。
ここで大西さんは、あいまいさの一例として、ある文章を紹介しました。大西さんが受け取ったメールの一部を引用したということでしたが、確かに「おおまかな」「そのあたり」といった抽象的な言葉が並んでいて、あいまいな印象を受けます。実は、わたしはその文章に見覚えがありました。理由は簡単、その文章を書いたのは、他ならぬわたしだったからです。大西さんは、わたしが講演を依頼するために出したメールの文章を引用したわけです。
大西さんは「別に第3バイオリンさんを非難しようというわけではなく、具体的な情報が欠かせない講演の依頼メールにさえも『あいまいさ』が含まれてしまう、ということを言いたかったのです。日本語、というより自然言語で書かれたものにはあいまいさが含まれてしまいます。だからこそ、言葉を尽くして説明することが大切なのです」と語りました。
テストをするときにもこの「あいまいさ」に注意しないと、テストがいいかげんなものになってしまうというわけです。
つぎに、「ごちゃごちゃ」なテストについてです。
テストに限らず何かが「ごちゃごちゃ」になる原因は大きく分けてふたつです。情報の流れが錯綜していて矛盾が多く含まれること、いろいろな要素が複雑に絡み合って因果関係がわかりづらくなることです。
大西さんは、情報が錯綜した状態から脱するためにはまずこんがらがったテストベースの関係性（トレーサビリティ）をはっきりさせること、と語りました。何からすればいいかわからない場合は、個々の要素を水平方向に整理することからでも始めると違います。
また、複雑な要素の因果関係を解くためには、互いに背反する仕様や要件について整理が必要です。例えば、車のドアひとつ取ってみても高級車と軽自動車では求められる質感、閉めたときの音の感じまでも違います。他にも、飛行機のコックピットのように「一覧性を高めて」かつ「操作しやすくする」という、相反するような要求を両立させる必要があるものも存在します。
このような場合は、その製品の性質をつかんで、競合する（あるいはこれから競合するであろう）製品やサービスと同等の作り込みがなされているかをチェックすること、どのような標準や指標（暗黙知も含む）への準拠が求められるかを把握するのがコツです。
情報の流れがごちゃごちゃしてわかりにくい場合は、パスをモデリングすることによって、わかりやすく変換することも大切だと大西さんは語りました。
3つめは「いっぱいありすぎ」なテストです。
まさに言葉どおりですが、一口にいっぱいありすぎといっても、例えばひとつのテストアイテムに対して条件や手順が多すぎる、組み合わせの数が多すぎる、など、いろいろあります。要は「何がいっぱいあるか」を洗い出すことが大切なのです。
これはわたしの考えですが、「いっぱいありすぎ」が先にあげた「ごちゃごちゃ」につながるのかもしれません。
最後は、「ちんぷんかんぷん」なテストです。
テストをしていてちんぷんかんぷん、もうとにかくわけがわからない！ という状態になる原因としては、まずそもそも知識がない、ということが挙げられます。知らないからわからない、というのは当然のことです。
それ以外には、テスト対象が画期的すぎて何の目的で使われるものなのかはっきりしない、技術的、学術的に難解なことがあるからわからない、という場合もあります。
これを解消するには、何はなくとも自分が携わる製品の特徴や品質特性を知ることです。これはドメインや市場によって異なります。例えば、組込み系であればセンサやモータなど、物理的な対象も操作する必要があるので、物理学や力学、機械工学の知識も必要になります。
また、テストで数式や高度な理論が求められる場合は、それらが用いられる理由や目的も理解しておく必要があります。
講演の最後に大西さんは「この講演では『仕様ベースのテスト』の難しさについて話してきました。ぜひ普段のテストで『何が難しいか、どう難しいと感じるのか』を考えてみてください。大切なものはテスト対象への『愛』です。愛があれば『好奇心』が生まれます。これはテストには欠かせないものです。難しければ難しいほどテストは大変になるけれど、そのぶん、やりがいも大きい仕事です」と締めくくりました。
大西さんの講演を聞いて、仕様ベースのテストの難しさというのは必ず出てくるものだけど、ひとつひとつ丁寧に取り組んでいけば必ず解決できるということがわかりました。わたしも、いつまでもテストへの愛と好奇心を忘れないテストエンジニアでありたいと思いました。あと、わたしはもうちょっとメールの文章を改善したほうがいいとも思いました。
「JaSST'13 Niigata」開催レポート第1回目はここまでです。次回は、演習付きチュートリアルの様子をお届けします。