ソフトウェアテストシンポジウム「JaSST'15 Niigata」開催レポート（その1）――テスト設計はモデルハウス見学と同じ！？
こんにちは、第3バイオリンです。
今年もソフトウェアテストシンポジウム「JaSST’15 Niigata」を開催しました。5年目となる今年は基調講演からワークショップ、QAタイムまですべてのセッションを富士ゼロックスの秋山浩一さんにお願いするという異例のプログラムでお届けしました。
■日時と場所
日時：2015年4月24日
場所：朱鷺メッセ 中会議室302B
■基調講演「ソフトウェアテストの作り方」
講演のはじめに、秋山さんは「今日は数字の『2』にこだわりたいと思います。あまり多くのことを一度に言っても、たいていの人は一度にあれもこれもとできません。だから、重要な2つのことに絞ります。2つにすれば方向性がわかりやすくなるからです」と語りました。
秋山さんは「品質とテストの改善はひとりではできません。そのため、人を動かす力が必要です」と語りました。確かに、組織のなかで品質とテストを改善しようと思ったら、仕事の進め方を変えたり、プロジェクトに関わる人のマインドを変えたりする必要があります。個人でできることには限度があります。では、周りの人を巻き込んで改善活動を進めるにはどうすればいいのでしょうか。
秋山さんは続けます。「まず思いつくのは『○○さんが言っていた』と影響力のある人物を出すことです。上司や社長でもいいし、業界で活躍する有名人でもいいです。一種の思考停止ワードではありますが、自分自身がさっさと判断して行動するには効果ありです。ところが、同じ言葉で他人を動かそうとしても、うまくいかないことがあります。有名人の名前を出しても、相手がその人を知らないこともありますし、社内の人物であっても『その人が言ったから何なの？』と反論されたらそれまでです。結局、人を動かすのはあなた自身の思いの強さです。なぜ高品質が必要なのか、なぜテストを改善するのか、それをしないとどうなるのか、自分の心に引っ掛かるものを核として理論武装し、『思い』を作って説得するのです」
さて、もし十分にテストをせずに市場に出た製品に致命的なバグがあったとき、どのような問題が発生するでしょうか。製品やシステムの欠陥で業務に支障をきたしたり、大事故が発生したりしたというニュースを聞くことがあると思います。もしそうなったら、企業は損害賠償やリコールで多額のお金を失うことになります。そして、企業の社会的信用も失墜してしまいます。
そのような炎上状態におちいってしまったとき、火消しチームや対策本部が発足し、改善活動が始まります。そうしてある程度の効果を上げられたところまではいいです。ところが、改善活動をいつまで続ければいいのかわからない、あるいはだんだん活動に飽きてマンネリ化しまう、という状態におちいることがあります。そうしているうちに活動がどんどん縮小し、予算も減らされてしまう。そして再び炎上してしまうというケースがあります。このような状況を防ぐにはどうすればいいのでしょうか。
秋山さんは、改善活動を続けるコツは『活動状況の見える化』と『炎上の気配をとらえること』のふたつである、と語りました。改善活動はたいてい3年目くらいで壁にぶつかるケースが多いのです。その時期に改善活動が停滞しはじめますが、そのときに再び炎上しそうになる気配をとらえて、炎が大きくなる前に初期消火してしまうことが大切なのです。
ここからはいよいよタイトルにあるテストの作り方のお話になります。人が造り出すものには必ず目的があります。ソフトウェアには仕様がありますが、仕様書にそのソフトウェアの目的が記載されるとは限りません。「なぜこの機能が必要か」「なぜこのような要求があるのか」まで記載されている仕様書は意外と少ないものです。
ここで秋山さんは、「テストのコツはモデルルームの見学と同じです。与えられたサンプルを、限られた時間でまんべんなく見るという意味では同じです」と語りました。家を買おうと考えている人がモデルルームを見るとき、玄関だけを見て満足して帰ることはまずありえません。中に入って、リビングルーム、キッチン、お風呂、トイレ、子ども部屋、さらには収納やベランダまで、すみずみまでチェックします。このとき、主婦であればキッチンの使い勝手はいいか、布団や洗濯物を干すのが大変ではないかが気になると思いますし、家族に小さい子どもやお年寄りがいる人はつまずくような段差がないか、お風呂で滑ったりしないかどうかが気になると思います。ただ何となく見ているだけでは、家を買ってしまった後で「なんかこの家、住みにくいなあ」と後悔するはめになることもあります。
ソフトウェアテストも同じです。「なぜこの機能があるのか、この機能の意味するものはなにか、この機能が実は無駄だったり、悪い方向に作用したりする可能性はないのか」などを考えてテストをしないと十分なテストはできません。そのためには、機能仕様のテストを作成するのが効果的です。仕様書に赤ペンで確認するポイントを書き込むのです。また、テストの改良ポイントとしては、テスト対象を小さく分解してテストを分割する、ユーザーの声をよく聞く、できればテストする人自身がテスト対象を実際に使ってみることが挙げられました。テストをする人がよい製品、よいテストを知ることが、偽物を見破る一番の方法である、というお話で講演は締めくくられました。
改善活動がうまくいかない、最初はうまくいっても途中から行き詰る、というのはよく聞く話なので、なぜそれが起こるのか、対策はどうするのかというお話はとても興味深いものでした。また、テストをモデルルーム見学にたとえる話もすごくわかりやすかったです。
「JaSST'15 Niigata」レポート第1弾はここまでです。次回はワークショップの様子をお届けします。