12月15日、秋山さんを招いての仙台ソフトウェアテスト勉強会。
秋山さんはHAYST法入門やソフトウェアテスト技法ドリルなどを執筆されている有名な方。仙台で講義が聞けるなんて本当に嬉しいです！！
今回の勉強会は山形の方、岩手の方など県外の方も含めまして、31名の方にお越しいただきました。本当にありがとうございます。
最初は日科技連の安随さんから、日科技連の紹介とJSTQB試験の紹介。
秋山さんが講義されているSQiPの紹介など、自分の価値を高めるために自分に投資していきましょうというメッセージだと感じました。
また2013年2月にJSTQB開催が決定とのことで、受験申込みした人は是非頑張ってください。今回都合がつかなかった人も目標があると違いますので、都合がつくときに是非挑戦してみてください。ただ受験料が少し高いですよね（笑
安随さんからも美味しいお菓子を頂きました。本当にありがとうございます！！
そして、ついに秋山さんの出番です！まず最初にテスト技法の使いどころについて。
これまでの勉強会でも同値分割、境界値分析、デシジョンテーブル、状態遷移テストを実施しましたが、一体いつ使えばいいのかは難しいですよね。
最初はテストの目的という観点で見たときのテスト技法の位置づけ。
そもそも何のためにテストをするんでしょうか？
秋山さんは３つに分けていました。
・Projectリスクの軽減："こんなはずでは"を撲滅
・Productリスクの軽減："バグ検出"で品質向上
・要求達成度合いの確認："カタログ値"の品質保証
グッと来た言葉：「経験だけのテストだとその人が居なくなったら終わってしまう」
そこからポジショニングマップの話へ。
今回は横軸[ピンポイント － ランダム － 網羅的]、縦軸が[単一機能 － 論理関係 － 組合せ － 時間/順序性 － 状態遷移 － 並行処理 － 並列処理]としたポジショニングマップ。HAYST法のサイトではテスト研究者用として紹介されている方になります。
http://www.hayst.com/Pages/positioning.aspx
その後、有則と無則の説明。
新しい言葉が出てくると、なかなか頭に入ってこないですよね。。。
有則：仕様上関わりが【ある】こと
無則：仕様上関わりが【ない】こと（=独立していること）
禁則：仕様上【ありえない】こと
さて、実際に組み合わせテストの説明に突入。
個人的には組み合わせテストは、直接テストケース削減に寄与（=コスト削減）できるので、身につければ強力な武器になると思っています。
組み合わせテストの基本となっているのは2機能間網羅ということ。
なるほど。そもそも組み合わせと言っていますが、何をどのように組み合わせるのかきちんと説明できないとダメですね。
参加してくれた学生の方で知っていた人もいたのですが、元々は実験計画法というものから来ているようです。
http://ja.wikipedia.org/wiki/%E5%AE%9F%E9%A8%93%E8%A8%88%E7%94%BB%E6%B3%95
例えば米の品種：10品種で、水：多め/少な目、肥料の種類：5種類だとすると、10×2×5種類で、100通りになります。毎年やっていくと、生きているうちに終わらないレベル。。。
ソフトウェアテストも同じで、近頃の複雑なソフトウェアであれば、すぐに現実的ではないテストケース数になってしまいますよね。（勉強不足の）マネージャーが全部試験しろ！と声高に叫んでも物理的に無理なんですよねｗ。そこをなんとかするのが組み合わせテストなんですね。秋山さんはそのような人は沢山のパラメータを変えたときのバグの出し方を知らないと言ってました。
ここでもう一つ重要な概念。因子と水準です。
これも初めて聞くと、どっちがどっち？となりますよね。
先ほどの米の品種の場合だと以下のような感じですね。（宮城で栽培されている米）
米の品種 ← 因子
ヤマウタ ← 水準①
こころまち← 水準②
おきにいり← 水準③
ササニシキ← 水準④
：
経験者だと因子・水準の見逃しはないとのこと。
でも最初から熟練している人はいないので、英語モードにしたらバグが出たとか、この機能を有効にしたらバグが出たとかそんな経験ありますよね？
ここで秋山さんの方からQumias(840円)の実演。
QumiasとPictMasterは禁則の入れ方など一長一短があるようです。
おこずかい程度で確認できるので、是非自分も買ってみたいと思います。
さて、今度はPictMasterの演習。
持ってきてもらったPCを使って、例題の値を実際に入力してテストケースまで出してみます。
PictMasterが動かない人や、制約の入れ方が分からないなどを教えながらなんとか出していきました。
やっぱり実際にテストケースが出ると嬉しいですよね。
全網羅を出してテストケースがどう変わるのか確認している参加者もいました。
各機能は独立していて、動作すると思っているのであまりにテストケースが多いと実施するエンジニアも嫌になってしまいますよね。心穏やかにテストを行うためにも理論を押さえて、ギリギリまでテストケースを削減することが必要だと思います。
ただツールって理論が分からなくてもできちゃうので、ちょっと怖いですよね。会社で使う場合も、値を入れてボタンを押せばケースがでるからいいやじゃなくて、理論も押さえておきたいものです。
そして講義はいよいよHAYST法へ。
どのように考えたら良いのか、考え方を説明をしてくれました。
こういうのって本当にためになりますよね。
本を見ると結果は載っているのですが、そこに行くまでの過程などはほとんど書かれていないことが多いので、現場の問題に適応しようとしたときにさっぱり分からなくなってしまいます。
今回はソフトウェアテスト技法ドリルにも載っている以下の考え方を説明してくれました。（※技法ドリルでは「破壊・ノイズ」ではなく、「意地悪」として載っています）
・例示・間
・対称
・類似
・外側
・破壊・ノイズ
次いで目的機能の説明。
目的機能って今までに色々なところで沢山聞いていましたが、イマイチしっくり来ていなかったです。
自分が理解した範囲ですが、目的機能の特徴は「時間の概念」が入っていることだと思います。リリースした時点ではなく、ユーザーが使い続ける間ずっとユーザーが目的を達成できるかどうかが重要なのだと思います。
この話を聞いて思いついたのは、自分が経験したiPadのバックアップ機能です。
最初、iPad中のデータが少なかったときは問題なかったのですが、データが増えるに連れ、バックアップに時間がかかってきました。しかもCドライブに作っていたので、WindowsPCのCドライブ容量が圧迫されていきました。最終的にはバックアップも取れずに失敗しましたというエラーが出るし、ゴミデータは残って新しいアプリのインストールはできないなど悲しい結末に・・・
その後、ラルフチャートの説明。
ラルフチャートもソフトウェアテスト技法ドリルにも載っているのですが、イマイチ使いどころが分からなかった図です。
秋山さんの説明と演習を通して、ラルフチャートは発想を広げるものであることが分かりました。チームのみんなで他に気になる点がないか確認し、モレをなくすために使うということだと思いました。なるほど！！綺麗に書くものではないんですね！！
発想を広げるという点ではマインドマップも同じような位置づけだと思いますが、マインドマップより形がしっかりしている分、発想がしやすい感じがしますね。
グッと来た言葉：「ラルフチャートは組織の知恵を引き出すもの」
ということで、今回のテスト勉強会も無事に終わりました。
テスト技法の使い方～組み合わせテスト～HAYST法の説明と内容の濃い3時間半だったと思います。自分も本当に勉強になりました！！
次回の勉強会はリクエストが多かったので、組み合わせテストの復習会にしたいと思います。新たな例題をみんなで解いていきたいと思います。
# 今回はブログへの報告が遅くなってしまってすいませんでした。m(_ _)m