昨日FBに探索的テストの話を書いたら、コメントくれた人が色々な使い方を言ってくれたのでちょっとまとめてみました。
イメージで語らずに具体化すると違いが出て面白ですね。『探索的テストはスクリプトテストと併用できる』って言ったら、テストクラスタの人は『それは同意！』っていうと思うけど、具体化すると結構違うんですよね～

[2016/04/08追記] スクリプトテスト：テスト設計を事前に行い、テスト手順まで明確にドキュメント化し、その手順に沿ってテスト実行をするテスト。

Aタイプ

Aタイプは最終的にスクリプトテストの結果として全体的なエビデンスが残り、探索的テストで弱いところのバグが出せるので『エビデンス残したいけど、バグも出したい人』向き。スクリプトテストは全体が対象なのでスクリプトテストの作成、メンテナンスに時間がかかる可能性がありそうです。

Bタイプ

Bタイプは最終的にスクリプトテストの結果として全体的なエビデンスが残り、それとは別に探索的テストを実施し、バグを出します。ソフトウェアがボロボロの可能性がある場合はスクリプトテスト終了時に開発側に戻せるため、探索的テストの時間が有効に使えます。探索的テストの範囲は事前に絞れないので、その分時間がかかる可能性があります。

Cタイプ

Cタイプは全体的なエビデンスは残りませんが、短時間で弱い箇所を把握し、その箇所に対してがっちりスクリプトテスト（テスト設計）を行います。探索的テストを先に実施するので、開発へのフィードバックはDタイプと同様に一番早いと思います。

Dタイプ

Dタイプは期間はBタイプに比べると、期間が短くて済むというメリットがあります。ソフトウェアがそこそこの出来だと確信している場合、かつ担当者が複数人いる場合はBタイプよりもDタイプを選択したほうが、納期の点でメリットがありそうです。

f:id:nemorine:20160407182858p:plain

2016-03-25

探索的テストの文献一覧

探索的テスト

探索的テストの勉強会用のコンテンツを作っていて、文献を調査していたらこんな感じのがありました。名前は有名だけど、日本語の本は少ないなぁ～って思います。

探索的テスト

高橋寿一
知識ゼロから学ぶソフトウェアテスト【改訂版】4章
http://www.amazon.co.jp/dp/4798130605

高橋寿一
探索的テストってなんですか？ - JaSSTソフトウェアテストシンポジウム PDF
http://www.jasst.jp/symposium/jasst14kyushu/pdf/S3.pdf

井芹洋輝 (@goyoki)
探索的テスト入門 (SlideShare)
http://www.slideshare.net/goyoki/ss-34292539

James Bach
General Functionality and Stability Test Procedure
http://www.satisfice.com/tools/procedure.pdf

James Bach
Exploratory Testing Explained(v1.3 4/16/03) PDF
http://www.satisfice.com/articles/et-article.pdf

James A. Whittaker
How to Break Software: A Practical Guide to Testing (英語) ペーパーバック – 2002/5/9
http://www.amazon.co.jp/dp/0201796198/

James A. Whittaker
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design (英語) ペーパーバック – 2009/8/25
http://www.amazon.co.jp/dp/0321636414

※一部抜き出したバージョンがmicrosoftのサイトにあります。
https://msdn.microsoft.com/ja-jp/library/jj620911(v=vs.120).aspx

Elisabeth Hendrickson
Explore It!: Reduce Risk and Increase Confidence With Exploratory Testing (英語) ペーパーバック – 2013/2/28
http://www.amazon.co.jp/dp/1937785025/

Cem Kaner
A Tutorial in Exploratory Testing
http://www.kaner.com/pdfs/QAIExploring.pdf

セッションベースドテスト

James Bach
Session-Based Test Management
http://www.satisfice.com/sbtm/

Jonathan Bach
Session-Based Test Management
http://www.satisfice.com/articles/sbtm.pdf

2016-02-25

Think Global Act Local ～北海道から世界へ～初音ミクの生みの親クリプトン伊藤さんの講演

イベント報告

Think Global Act Local ～北海道から世界へ～クリプトン・フューチャー・メディアの伊藤さん講演

今日は初音ミクの生みの親、クリプトン・フューチャー・メディアの伊藤さんが会社で講演してくれました！伊藤さんの落ち着いた声のトーンとは裏腹に、とにかく熱く、面白い話が聞くことができました。用意された2時間はあっという間に過ぎてしまいました。クリプトン・フューチャー・メディアは「コンテンツ」×「技術力」で勝負している会社で、音で発想するチームを目指しているとのことです。 http://www.crypton.co.jp/

特に注力して話していただいたのは、初音ミクの話。音声技術×コンピューターミュージック＝歌唱合成技術＋キャラクターということで今までに無いキャラクターと結びついたボーカロイドが生まれたとのことです。

権利関係もかなり考えられたようで、世の中のクリエイターがつながりやすいように、気持ちよく創作活動ができるようにと考えて仕組みづくりをしている感じを受けました。伊藤さんは創作の連鎖～共感の連鎖/ありがとうの連鎖と言っていて、言葉だけではなく、それを仕組みにしているのは凄いなぁと感じました。また日本だけではなく、世界の人をターゲットにしているというのもグッときました。

初音ミクはその活躍する世界も広がってきているようで、最近では世界ツアーも開催されている模様。なんと！札幌でも4/5（火）にあるようなので、行ってみたい！と思いました。世界中で満員御礼が続いていて、中国はわずか10分で売り切れたとのことです。凄い！！凄いぞ！初音ミク！！

最近では札幌のクリエイターやスタートアップの人を応援する取り組みをしているようです。・雪ミク・ミライストカフェ・シメパフェ・札幌移住計画

伊藤さんの地元愛をヒシヒシと感じました！やっぱり札幌いい街ですもんね～

最後に質問できる機会があったんだけど、「最初の初音ミクのデザインはどうやって決めたんですか？」って聞いてみました。

伊藤さんの答えは、音楽のクリエイターが引かないようにコテコテの萌えではないデザインにしました、とのことでした。最後はなんとなく全体的にいいんじゃないかい？っていう雰囲気になったようです（笑

伊藤さん、企画してくれたHさん、本当にありがとうございました！！

2016-01-27

ドラクエ風スキルマップ

ゲーミフィケーションチームビルディングスキルマップ

あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！まあ会社という組織ではよくありますよね（苦笑
チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。これもまさにゲーミフィケーションって感じですねぇ～

スキルマップを作る過程

元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。これだけでもかなり盛り上がりましたッ！！以下は川口さんのオリジナルから変更したところです。

要件定義のスペシャリストとして、商人を追加。
旅芸人はマネージメントのイメージに変更
スキルの方向を上方向に変更
盗賊のスキルレベルの見直し
CやC++をイメージして文言を見直し
特性に対応するキーワードを追加

f:id:nemorine:20160127135604p:plain

スキルマップを記述する

チームメンバーに実際に記述してもらったところ、通常の無味無臭なスキルマップより楽しくつけることが出来たとのことです。まずはそれだけでも大成功ッ！！それとともに問題点がいくつかでました。

下のスキルはないが、上はあるなど、スキルが飛ぶことがある。
→そのまま素直につけてもらいました。
文言が2個あり、片方にしか当てはまらないときはどうするのか？
→そこまで厳密ではないので、今回はどちらかに当てはまればつけてもらいました。

これらの問題点に関しては次回以降の宿題になりそうです。

f:id:nemorine:20160127135610p:plain

チームの現状とキーマンが抜けた後の状態を把握する

チームメンバーからのスキルマップを合成して、キーマンがいる現状とキーマンが抜けたあとのイメージを共有しました。予想通り問題がありそうというのがはっきりと分かりました。（図はイメージです）自分達は数も出していて、1人は赤、2人は黄色、3人以上は赤色にしてみました。特にキーマンというだけあり、その人しかもっていないスキルが多いと思います。

f:id:nemorine:20160127135616p:plain

f:id:nemorine:20160127135613p:plain

やってみた感想

何はともあれ面白くできたのというのが大きいです。スキルマップつけるのって面倒になること多いですもんね。特にドラクエ風のスキルマップにすることで、戦士だけのチームを目指すのではなく、いろいろなスキルを持った人がチームに必要なんだよというイメージが伝えやすくなります。
そして自分達のチームの問題点を可視化できるのも効果が高そうです。まずい状態をメンバー全員で共有できるし、次にどうしたらいいかという話に持っていきやすいと思います。今回はキーマンが抜けた後の問題点を出したかったので、その前にアイスブレーク的な感じでこのスキルマップのワークを入れました。

とりあえず自分達のスキルマップをみんなでワイワイ作ってみるのをお勧めします。意外に面白いですよ～

川口さんのオリジナルネタは日経SYSTEM（2015年11月号～）に載っていて、現在好評連載中とのことです。特にキーマンの離脱に関連するところとしては、日経SYSTEM2015年12月号の「メンバーの離脱について考える」の節に詳しく載っていますので、ぜひ読んでみてください。