「JaSST'11 Tokai」参加レポート――前提、あってますか
こんにちは、第3バイオリンです。
前回の続き、「JaSST’11 Tokai」レポート第2弾をお届けします。
前回のレポートではポスターセッションまでについて執筆しました。ポスターセッションの後は、2つの会場で別々のプログラムが同時進行する形となりました。2つの会場のうち、一方では特別講演と経験発表、テスト設計コンテスト発表が、もう一方ではチュートリアルが実施されました。私は前者のほうに参加していたので、今回は特別講演と経験発表までの様子をお届けします。
■特別講演「製品、ソフトウェア、プロジェクトの前提と品質の関連付け」
静岡大学の森崎 修司さんのセッションです。
突然ですが、「ソフトウェアに求められるものとは？」という質問をされたら、読者の皆さんはどのように回答するでしょうか。
もし、この質問に対して前提や文脈（コンテキスト）が定義されていなければ、おそらく自分が携わる業務を思い浮かべながら回答されると思います。例えば、スマートフォンのソフトウェアの開発に携わる人は「機能の豊富さ」と回答するでしょうし、エンジンコントロールユニットを制御するソフトウェアの開発に携わる人は「品質が第一」と回答するでしょう。
このような、お互いのコンテキストの違いに気付かないでいると、議論がかみ合わなくなったり、自分の現場では通用しない結論を間違って持ち帰ってしまったり、という問題が起こりえます。
実際に森崎さんは、これまでに多くのソフトウェア開発の現場を見てきたなかで、前提やコンテキストがずれているために議論がかみ合わない、という状況を何度も目の当たりにしてきたそうです。
そこで森崎さんは「コンテキストの抽出」について説明されました。開発プロセスや優先させるべき要素、プロジェクトの体制や業務形態（受託、自社開発など）といったコンテキストを抽出することで、使いたい技術がコンテキストにあっているかどうか、また技術そのものの可能性や今後の方向性が明確になる、ということです。
コンテキストの抽出の方法のひとつとして、森崎さんは「エンピリカルアプローチ」について説明されました。
エンピリカルアプローチとは、技術を実際の現場にあてはめて研究するためのアプローチ方法で、おおまかには次のような流れで進めていきます（詳しく知りたいという方は、書籍「ソフトウェア開発におけるエンピリカルアプローチ」がおすすめです）。
- 第1段階：実験や調査により現象を確認する
- 第2段階：現象が起こるコンテキストを理解する
- 第3段階：因果関係を明らかにして現象を説明できるようにする
つまり、先にコンテキストを決めるのではなく、観察や調査を行ってコンテキストを取り出して理解する、ということです。
ここで森崎さんは、一部が空白になった、ソフトウェア品質について述べる文章を提示して「皆さんの現場を思い浮かべて、空白部分を埋めてください。そうして、皆さんの現場のコンテキストを抽出してみてください」とおっしゃいました。わたしは自分の現場のことを考えながら、文章を作ってみました。「わたしの現場にとって“品質”って何だろう。どうして、それによって競争力が生み出されると思うのだろう」普段、仕事をしているときには意識しづらいことを考えて、わたしのコンテキストを抽出することができたと思います。
最後に森崎さんは講演を振り返り、「ぜひ、この後のSIGで生かしてほしい」と参加者にメッセージを伝えました。
セミナーで聞いたことや、スーパーエンジニアが言っていたことをそのまま自分も取り入れてみようとして失敗した、という経験をされた方はけっこういらっしゃると思います。もしかしたら、その原因のひとつはコンテキストの食い違いだったのかもしれません。
相手のほうから「自分のコンテキストは～」と説明してくれることは少ないと思います。わたしも、相手の話を聞いて違和感を覚えたり、反対に「いい話だ！すぐ取り入れよう」と思ったりしたときには、コンテキストに食い違いはないかどうか、立ち止まって考えてみようと思いました。
■経験発表「探索的テストの適用条件」
三菱電機メカトロニクスソフトウェアの都築 将夫さんのセッションです。
都築さんはテストを担当している製品に含まれる、新規開発からの潜在バグに悩まされていました。システムテストで発生する潜在バグを何とかしようと、スクリプトテストを改善してきましたが、それだけではバグ検出に限界がある、ということに気がつきました。
そこで都築さんは、「探索的テスト」を適用することにしました。探索的テストとは、これまでのテストの結果を見ながら次のテストのやり方を決めていく、というテストのことです。テストの限界を超えるため、失敗を恐れずに想像力を働かせるテストを「やろまい！」と思ったわけです。
さて、探索的テストは、上手に活用すればテストのマンネリ化を防ぎ、少ない手数で多くのバグを検出できるというメリットがあります。その一方で、使いどころを誤るとテスト実行の網羅性に欠ける、テストの目的を見失って思いつきだけになってしまう、テスト仕様の記述が難しい、といったデメリットもあります。
都築さんは、これらのデメリットを克服するための方法を考えました。
まずは「テスト実行の網羅性に欠ける」の克服です。都築さんは、仕様書やマニュアルから、「操作」と「動作」それぞれの要素を取り出し、テスト実行マトリクスを作成しました。マトリクスの重複部分をマージし、グルーピングして最適化することでテストケースを整理し、網羅性がひとめでわかるようにしました。
つぎに「テストの目的を見失う」の克服です。都築さんのチームでは、毎朝チームメンバーとミーティングを行い、テスト実行マトリクスからテスト実行部分を抽出して実行順位を決めました。過去のテスト結果からバグの傾向を読み取ったり、顧客にとってリスクになりえることは何かをテスト担当者と一緒に考えたりすることで、テスト担当者にも「テストの目的は何か」「目的を果たすためにどこをテストするべきか」を自分で考えるクセをつけるようにできた、と都築さんは語りました。
最後は「テスト仕様の記述が難しい」の克服です。これもテスト実行マトリクスを上手に使うことで解決できたそうです。マトリクスの1セルを1テストケースとしたことで、「操作」と「動作」の組み合わせと、テスト結果とのトレーサビリティを確保できるようにしました。
テスト実行マトリクスを利用することで、都築さんのチームは前回のテストよりも多くの潜在バグを見つけることができました。その中には、致命的とまではいかないものの、顧客の元で大きなトラブルを引き起こしそうになったバグも含まれていたそうです。
最後に都築さんは、探索的テストには用意周到な準備が大切、と語りました。今後は、他のプロジェクトにも展開しつつ、どの現場にも通用するようなシンプルな方法を考えていきたい、と話して発表を締めくくりました。
探索的テストの概念をマトリクスという形にしてわかりやすくすることによって、テスト担当者がただテストケースを消化するだけでなく、テストの目的を自分で考えられるような仕組みを作ることができたというエピソードが素晴らしかったです。わたしは探索的テストを、どちらかというとベテラン向けのテストと考えていたのですが、こういう仕組みを作ることでテストエンジニアの訓練にもなるのだと目からウロコが落ちる思いでした。
また、「WACATE」でよくご一緒している都築さんが発表されている姿を見て、いつかわたしもJaSSTで登壇したい、と思ったのですが、それはまた別のお話です。
第2回目の参加レポートはここまでです。次回は最終回、テスト設計コンテストとSIGの内容をお伝えする予定です。