去る2013年11月15日、JaSST東海に行ってきました。
JaSST’13 Tokai
※2012年参加時のエントリはこちら
今回はPMIJ中部としてのポスターセッション発表をやることになっていたので、バッチリ準備した上で会場のある刈谷に向かいました。
当日は残念ながら雨模様でしたが、例年どおり多くの人が参加し貴重なお話を聞くことができました。（いつも感じるのですが、実行委員のみなさんホントに凄いと思います・・・）
基調講演
清水吉男氏による『DevJTestでQCDの同時達成を目指せ』と題した講演です。
ちなみに氏の著書である『[改訂第2版] [入門+実践]要求を仕様化する技術・表現する技術 -仕様が書けていますか?
さて本題に入ります。
テストでバグを漏らさないためにテストの網を強化するというやり方は、拾えるゴミ（バグ）の数は増えるけれども、バグそのものの数が減らなければテスト工数が増大する一方です。
従来の日本のソフトウェア開発プロジェクトでは、「人海戦術」で乗り切るケースが多いと言われていますが、これがQ（品質）とCD（生産性）が相反するというプロジェクト上の問題を引き起こします。
ここで、本講演のタイトルにある「DevJTest」に着目してみます。「DevJTest」は「Development Join to Test」の略で、開発側とテスト側で連携してQCDを同時に達成しよう、というのが講演の主旨です。
バグを見つけることに注力するよりもバグの数そのものを設計段階で減らそう、という発想ですね。
本講演を拝聴して、テストで得られた情報を開発側にフィードバックするためのプロセスを確立する必要があると改めて感じました。私の理解を以下のとおり整理して結びたいと思います。
- 過剰な分業化・専門化がムダな作業を生む
- テストで得られた情報（バグのパターン等）を開発側に提供して今後作りこまれるバグを減らそう！
- 水中のゴミは網で引っ掛けられるが、水質の悪さは引っ掛けられない（テストでは見つからない品質の悪いプログラム）
- 派生開発は変化点（before/after）を見える化する
- プロセス改善活動を形骸化させないためには、その「本質」を理解すること（本質を考えて文章に書き出してみる）
- 「人のどんな行動パターンがこのようなバグを生むか？」テストエンジニアは推理を働かせるべし！
ポスターセッション
短い昼食を挟んだ後に、いよいよポスターセッションの準備に入ります。PMIJ中部のテーマは「マネジメントの新常識、ステークホルダーマネジメントとは！」と題してステークホルダーマネジメントについての研究成果発表です。
これまでの活動概要は以下を参照ください。
●ステークホルダーマネジメント勉強会の概要
●分科会のワークショップで使った資料
また、当日のポスターセッションで掲示した資料は以下を参照ください。
●JaSST’13Tokai ポスターセッション資料
PMIJ中部の分科会として実施した「ステークホルダーマネジメント勉強会」の成果をベースに「ステークホルダーマネジメントとは何ぞや？なぜ重要なのか？」をまとめた内容になっています。また、PMIJ中部の活動紹介も織り込みました。
テストに関するシンポジウムということで、こうしたマネジメント系のセッションはあまり内容的にそぐわないのかなと懸念していましたが、意外と多くの参加者が興味を示してくれたようで少し安堵しました。ε-(´∀｀*)
最近はテスト要求分析やテスト設計の際にステークホルダー分析をやるケースが多いらしく、意外とタイムリーな発表だったのかも知れません。
それだけに当日名刺を忘れるという致命的ミスのせいで、せっかく興味を示してくれた方と名刺交換できなかったのが悔やまれます・・・･ﾟ･(つД｀)･ﾟ･
探索的テストを探索してみよう！
今回のSIG(Special Interest Groups)は、@MasaoAprilさんによる探索的テストに関するセッションです。
セッション資料はこちら。
「探索的テスト」とは「スクリプトテスト（既に記述されている手順どおり実行するテスト方法）」と対で語られることが（少なくとも私の知る限りは）多いのですが、「場当たり的なランダムテストと何が違うの？」と疑問に思われることが多いようです。
あくまで私の理解ですが、ランダムテストとの大きな違いは
- チャーター（指示書）を作る
- 結果を次回のスクリプトテストに反映する
の２点にあるようです。
このセッションでは「チャーターを作成するのに必要な要素を洗い出してみよう」ということで、参加者が思いつくままに要素をあげてみました。そのときの様子です↓
出てきた意見を集約すると、
- 製品コードまたはテストコードが「アヤシイ」箇所を狙い撃ち
- 操作が複雑な部分を狙い撃ち
といったように「重点的に探索的テストを実施する箇所をどう絞り込むか」といった観点が多かったように思います。
また、これとは別に「どのタイミング／どんな状況で探索的テストを実施するか」といった、そもそも論に発展する場面もありましたが、プロジェクトの目的を達成するための手段としての探索的テストの「使いどころ」をどう考えるか・・・個人的には非常に興味のあるセッションでした。
さいごに
今年は残念ながら情報交換会には出られませんでしたが、ポスターセッションという形で「参加」できたのが何よりも収穫だったと思います。次回も何らかの形で「参加」させていただけると幸いですね。
（終）
＊＊参考書籍＊＊
Follow @tuto_i