「JaSST'10 Hokkaido」参加レポート（その1）――勝つためのテスト戦略してますか
こんにちは、第3バイオリンです。
先日、10月1日にソフトウェアテストシンポジウム「JaSST'10 Hokkaido」に参加するために北海道に行ってきました。
その前の週には、エンジニアライフコラムニストによるライトニングトーク大会に参加するため東京に行きました。自分で言うのも何ですが、エンジニアライフ編集担当者からも「旅芸人」キャラとして認められただけのことはあると思います。
今回は、「JaSST'10 Hokkaido」のお話をします。北の大地に、テストを愛する熱い心をもったエンジニアたちが集結しました。
■ゲンバノチカラ ～テスト実装5秒前！ そのとき現場が動いた～
今回の「JaSST'10 Hokkaido」のテーマです。現場で役立つ、テスト計画やテスト設計のお話がメインでした。
■参加者について
今回の参加者は72名。そのうち北海道以外からの参加者は、わたしも含めて18名でした。中には九州から参加された方もいらっしゃいました。
ソフトウェアテストのシンポジウムなので、参加者はテスト関係者ばかり……と思っていましたが、開発メインの方、または開発とテストを兼任している方が合わせて18名いました。また、少数ではありますが経営やコンサルタントの方もいましたし、学生の方も1名いました。
JaSSTのサイトの「ご挨拶」の最後には、こんな一文があります。
「技術やマネジメント、研究に関わらず、ソフトウェアテストに関心のある方の積極的なご参加や論文のご投稿を、実行委員一同、心よりお待ちしております」
もし、JaSSTについて「興味はあるけど、自分は開発担当だからちょっと……」とお考えのあなた。そんな遠慮は無用です。興味があるなら、ぜひ参加してほしいと思います。
■現場の力をメキメキ引き出すテスト戦略
まずは、JSTQB技術委員の湯本剛さんの基調講演です。
最初に「『テスト戦略』とは何か？」というお話から始まりました。戦略とは、勝つための手段のことです。そういう意味では、テスト戦略というのはテスト設計の前に、「勝てるテスト（効率的で効果の高いテスト）」を実現するための手段を考えること、といえます。
しかし、実際のところはテスト設計の前に「人手が足りない」「時間が足りない」と、足りないもの、できないことを先に挙げていくことが多いというのが現状でしょう。それでは気持ちもネガティブになりますし、戦う前からすでに負けてしまっています。
湯本さんは、勝つためのテスト戦略を作るうえで大切なことは、
- 本当にやりたいこと、やるべきことを反映する
- 作っておしまい、ではなく確実にテスト設計につなぐ
この2つであると語りました。
では、勝つためのテスト戦略を作るには、何をすればよいのでしょうか。
どんなテストにも、必ず目的があります。テストの結果を何に役立てるかによって、テストの視点も変わりますし、テストを開発ライフサイクルのどこで実施するのかも変わります。
視点が異なれば、たとえ同じ手順でもテストケースとしては別々に扱ったほうがいい場合もあります。また、納期がずれたり、開発のスタイルが変わったりしたときには、今までのやり方でよいのか見直しを行う必要があります。
それをうまくやるには、どのレベルのテストを誰が実施するのか、表などを用いて具現化すること、テスト戦略のアウトプットとそれ以外のものとの関係を整理することが大事であると語りました。
こういうことをきちんと行っていれば、テストケースを再利用するときも便利です。そうすれば、機能が増えるたびにテストケースも増えるばかり……といった状況を避けられます。
わたしのコラムだけでは、湯本さんが考えていらっしゃるテスト設計やそのアウトプットについてすべてをお伝えすることはできません。もっと詳しいことが知りたいという方は、ぜひ「ソフトウェア・テスト PRESS Vol.10」の湯本さんの特集記事をお読みください。わたしも読みましたが、とても分かりやすいです。
わたしは湯本さんの講演を聞いて、「勝つためのテスト戦略ができているかな」と考えてみました。日々の忙しさやいろいろな制限の中で「本当にやるべきこと」をきちんと考えたことがあったかな、ましてや「本当にやりたいこと」まで考える余裕があったかな、いや、どうもそこまでは考えていなかったかも……いろいろな考えが頭の中を回っていました。多分、当たり前のことなのでしょうが、その当たり前のことを実行することの難しさを感じてしまいました。
余談ですが、湯本さんは講演の途中で「例えばこのテストは○○さん担当……」と、参加者の中で顔見知りの方の名前を呼びながら説明をしていました。そのとき、ふいにわたしの名前（苗字）が呼ばれたのですが、まさか自分が呼ばれると思っていなかったわたしは慌ててしまい、思わず下を向いてしまいました。
そんなわたしに対して湯本さんは「あれ、目を合わせてくれませんね」と冷静に突っ込みを入れていました。湯本さん、その節は大変失礼しました。この場を借りて謝罪いたします。
■潜在不具合炙り出しテスト ～テストは計画的に～
東京エレクトロンソフトウェア・テクノロジーズの中岫（なかくき） 信さんの発表です。
中岫さんはある日の飲み会の席で、上司とシステムの不具合について話をしました。ちょうどリコール問題が世間を騒がせていた時期で、もしリコールといった大問題が発生したら……というところから始まり、最後に「リコールまでは行かなくても、ちょっとした不具合がしょっちゅう発生して、お客様の仕事を止めてしまうのは問題」という話が出ました。そこで中岫さんは「システムを止めるような不具合を減らすには、今まで以上に運用面を考慮したテストが必要」と提案しました。
飲み会の席の話なので、その場限りで終わると思っていたらプロジェクトが発足し、言いだしっぺの中岫さんもアサインされることになりました。システムの運用に関わる潜在的な不具合を炙り出すためのプロジェクトなので「炙り出しプロジェクト」と名づけられました。
さっそくテストのスケジュールを立てて、テスト対象となる機能の絞込み、テストのプロセスや方法を決めていきましたが、どうしても今までのテストと同じようになってしまいます。
これでは意味がない、何か今までと異なる観点のテストを導く方法はないだろうか……と悩んだ中岫さんは、「スープカレー表」を使ってみることを思いつきました。
スープカレー表とは、去年の「JaSST’09 Hokkaido」で紹介されたテスト技法です。簡単に説明しますと、機能観点（機能要求）と顧客観点（非機能要求）をマトリクスで結びつけてテスト観点を導く技法です（なぜスープカレーなのか、という説明はこちらのPDF資料をごらんください）。
スープカレー表を新しく取り入れる前に、効果について検証を行ったところ、いくつかの課題は見えたものの使えそうな手法であることがわかりました。そこで中岫さんのプロジェクトでは、課題を解決しながらスープカレー表を取り入れたテストプロセスを作り、テスト設計を行いました。
その結果、いままでになかったテストケースを作り出すことができたそうです。さらに、そのテストケースを用いてテストを実施したところ、狙っていた不具合を発見することができたそうです。
中岫さんは、今回の結果をふまえて、次のテストではテスト対象となる機能について、いつ、誰がどのように使う機能なのかもっと具体的に考えたい、そしてプロジェクトで得たことを開発プロセスの上流工程に取り入れたいと語って発表を締めくくりました。
わたしはこの発表を聞いて、新しい技法を取り入れるときの心構えについて考えさせられました。今までのやり方で思ったような効果が出ない場合、新しい技法を取り入れるということは有効な解決方法のひとつです。しかし、新しい技法をそのまま取り入れて大丈夫か、新しい技法を用いることで本当に自分が狙ったテストができるのか、事前によく検証する必要があるということ（当たり前のことですけど）を理解しました。これからも中岫さんの取り組みを応援したいと思います。
第1回のレポートはここまでにします。次回もお楽しみに！