探索的テストの文献一覧
探索的テストの勉強会用のコンテンツを作っていて、 文献を調査していたらこんな感じのがありました。 名前は有名だけど、日本語の本は少ないなぁ～って思います。
探索的テスト
高橋 寿一
知識ゼロから学ぶソフトウェアテスト 【改訂版】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
Think Global Act Local ～北海道から世界へ～ 初音ミクの生みの親 クリプトン伊藤さんの講演
Think Global Act Local ～北海道から世界へ～ クリプトン・フューチャー・メディアの伊藤さん講演
今日は初音ミクの生みの親、クリプトン・フューチャー・メディアの伊藤さんが会社で講演してくれました！ 伊藤さんの落ち着いた声のトーンとは裏腹に、とにかく熱く、面白い話が聞くことができました。 用意された2時間はあっという間に過ぎてしまいました。 クリプトン・フューチャー・メディアは「コンテンツ」×「技術力」で勝負している会社で、音で発想するチームを目指しているとのことです。 http://www.crypton.co.jp/
特に注力して話していただいたのは、初音ミクの話。 音声技術×コンピューターミュージック＝歌唱合成技術 ＋ キャラクターということで 今までに無いキャラクターと結びついたボーカロイドが生まれたとのことです。
権利関係もかなり考えられたようで、世の中のクリエイターがつながりやすいように、 気持ちよく創作活動ができるようにと考えて仕組みづくりをしている感じを受けました。 伊藤さんは創作の連鎖～共感の連鎖/ありがとうの連鎖と言っていて、 言葉だけではなく、それを仕組みにしているのは凄いなぁと感じました。 また日本だけではなく、世界の人をターゲットにしているというのもグッときました。
初音ミクはその活躍する世界も広がってきているようで、 最近では世界ツアーも開催されている模様。 なんと！札幌でも4/5（火）にあるようなので、行ってみたい！と思いました。 世界中で満員御礼が続いていて、中国はわずか10分で売り切れたとのことです。 凄い！！凄いぞ！初音ミク！！
最近では札幌のクリエイターやスタートアップの人を応援する取り組みをしているようです。 ・雪ミク ・ミライスト カフェ ・シメパフェ ・札幌移住計画
伊藤さんの地元愛をヒシヒシと感じました！ やっぱり札幌いい街ですもんね～
最後に質問できる機会があったんだけど、 「最初の初音ミクのデザインはどうやって決めたんですか？」って聞いてみました。
伊藤さんの答えは、音楽のクリエイターが引かないようにコテコテの萌えではないデザインにしました、とのことでした。最後はなんとなく全体的にいいんじゃないかい？っていう雰囲気になったようです（笑
伊藤さん、企画してくれたHさん、本当にありがとうございました！！
ドラクエ風スキルマップ
あるとき突然『チームのキーマンが抜ける』というイベントが発生しました！
まあ会社という組織ではよくありますよね（苦笑
チームメンバーが不安がっていたので、以前、楽天の川口さんに教えてもらったドラクエ風スキルマップを使って今の状況を可視化してみました。
これもまさにゲーミフィケーションって感じですねぇ～
スキルマップを作る過程
元々はWebアプリケーションエンジニアのスキルマップだったため、自分達に合うように数人でスキルマップを練り直しました。 これだけでもかなり盛り上がりましたッ！！ 以下は川口さんのオリジナルから変更したところです。
- 要件定義のスペシャリストとして、商人を追加。
- 旅芸人はマネージメントのイメージに変更
- スキルの方向を上方向に変更
- 盗賊のスキルレベルの見直し
- CやC++をイメージして文言を見直し
- 特性に対応するキーワードを追加
スキルマップを記述する
チームメンバーに実際に記述してもらったところ、通常の無味無臭なスキルマップより楽しくつけることが出来たとのことです。 まずはそれだけでも大成功ッ！！それとともに問題点がいくつかでました。
- 下のスキルはないが、上はあるなど、スキルが飛ぶことがある。
→そのまま素直につけてもらいました。 - 文言が2個あり、片方にしか当てはまらないときはどうするのか？
→そこまで厳密ではないので、今回はどちらかに当てはまればつけてもらいました。
これらの問題点に関しては次回以降の宿題になりそうです。
チームの現状とキーマンが抜けた後の状態を把握する
チームメンバーからのスキルマップを合成して、キーマンがいる現状とキーマンが抜けたあとのイメージを共有しました。 予想通り問題がありそうというのがはっきりと分かりました。（図はイメージです） 自分達は数も出していて、1人は赤、2人は黄色、3人以上は赤色にしてみました。 特にキーマンというだけあり、その人しかもっていないスキルが多いと思います。
やってみた感想
何はともあれ面白くできたのというのが大きいです。
スキルマップつけるのって面倒になること多いですもんね。
特にドラクエ風のスキルマップにすることで、戦士だけのチームを目指すのではなく、いろいろなスキルを持った人がチームに必要なんだよというイメージが伝えやすくなります。
そして自分達のチームの問題点を可視化できるのも効果が高そうです。
まずい状態をメンバー全員で共有できるし、次にどうしたらいいかという話に持っていきやすいと思います。
今回はキーマンが抜けた後の問題点を出したかったので、その前にアイスブレーク的な感じでこのスキルマップのワークを入れました。
とりあえず自分達のスキルマップをみんなでワイワイ作ってみるのをお勧めします。 意外に面白いですよ～
川口さんのオリジナルネタは日経SYSTEM（2015年11月号～）に載っていて、現在好評連載中とのことです。 特にキーマンの離脱に関連するところとしては、日経SYSTEM2015年12月号の「メンバーの離脱について考える」の節に詳しく載っていますので、ぜひ読んでみてください。
『自分の成長に責任を持てるのは中長期的には自分だけなので、自分で（スキルを）選んでいく必要がある by 川口さん』（日経SYSTEM 2015年12月号）
スプリントをドラマ仕立てに！
Scrum Gathering Tokyo2016できょん君の発表で 『スプリントを無味無臭なモノから、ドラマ仕立てにする！』 というのがあった。 ゲーミフィケーションに興味があるので、こういうのグッと来る。
面白いっていうのはもちろんだけど、 スプリント自体に名前を付ける事によって、今回のスプリントで何を大事にするかが分かるとのこと。 うーん なるほど！いいアイディアだなぁ〜
『胎動』とか『鉄は熱いうちに打て！』とか名称が秀逸過ぎるでしょ〜
Googleにやられた話
12月24日。クリスマスイブ。 Googleのトップページには何かの平面図が載ってました。（全部で4種類）
会社の友達と印刷をして作ってみたら家が出来た。 可愛いっ！！
でも緑の平面図だけがどうにも分からない。皆さんは分かりますか？ 半円はクルっと丸めて木だろうなぁ～なんて予想して（笑
結果できたもの。。。 木がある小屋かな？
・
・
・
・
・
・
そして、今朝クリスマス当日・・・
衝撃の画像がGoogleのTopページに！！
いやー Googleにやられました・・・ 答えを教えた会社の友達も「今年一番の驚きです！」と言ってました。 この半円を重ねるという発想はでなかったなぁ～ 答え分かると簡単だけど、これぞコロンブスの卵ってヤツでした。
悔しいので、昨日のものを使って新しいデザインの家を考案してみました。 こっちも意外に可愛い家ができました♪
クラス設計とテーブル設計のちょっとしたDiff
すごい久々のエントリですｗ デブ沙汰しています。
半谷さんからバトンタッチしました♪ マンガなので読みやすく、それでいて内容はグッと来るので是非見てください♪
このエントリ記事はDevLOVE Advent Calendar 2015の「Diff」11日目の記事です。
今回は今年実施したSQLアンチパターンの勉強のときに感じた違い(Diff)になります。
今までDBはメンテナンスが多くてキチンとSQLの勉強をしたことがなかったので、チームの有志であの t_wadaさんが監訳したSQLアンチパターン勉強することにしました。
その第3章を勉強してたときのことです。 「IDリクワイアド」といって、全てのテーブルに（何も考えずに）id列をつけてしまうというアンチパターンでした。 その中に列の名前付けの話が書いてあったのですが、例えばBooksテーブルの場合はid列よりbook_id列が推奨されるとのことでした。
一方、Bookクラスの場合、メンバ変数nameやidとはしますが、bookNameやbookIdとはしませんよね？ 昔オブジェクト指向を勉強したとき、Book.bookIdとなるとブックブックしちゃうので、だからBook.idとなるようにnameやidを付けるのですと書かれたのを見てなるほど！！と思った記憶があります。
そのことを思い出して、どうしてSQLの場合はid列ではなくてbook_id列が推奨されるのだろうと参加者と一緒に考えてみました。 その結果、テーブルは他のテーブルとも結合されるため、様々なテーブル間で一意になるように、idではなくbook_idと付けた方がいいということが分かりました。 idだとBooksテーブルのidもReservationsテーブルのidも見分けがつかないですもんね。 しかも2つのテーブルに同じ名前の列名がある場合はUSINGを使って簡潔に書けるとのことでした。
SELCT * FROM Books INNER JOIN Reservations USING book_id
SQLアンチパターンにはもしidとしてしまうと冗長なON構文を常に使う必要があると書かれています。
SELECT * From Books As b
INNER JOIN Reservations As r
ON b.id = r.book_id
ON構文は冗長である。 ｶﾞ━━Σ(ﾟДﾟ|||)━━ﾝ 普通だと思ってた･･･
普通にSQLを書いている人にとっては、あたりまえだね～と思われるかもしれませんが、メンテばかりしていると気づきにくいものです（言い訳ｗ）
ある日DBの新規設計を任されたら、id列としていたと思いますので、やっぱり素振りって大切だと再認識しました。 個人的にはクラス設計とテーブル設計のDiffを感じたところだったので今回のエントリとして書かせてもらいました。
魅力的品質と品質特性
この記事はソフトウェアテストあどべんとかれんだー2014の12/16の記事になります。
今日は今年の心に残っているエピソードの１つを紹介し、それについて考えたことを紹介したいと思います。
あるとき、TEF道のお世話役の安達さんと品質特性の使い方の話をしていたときに、「製品やサービスに必要な品質を考えるときに、いきなり品質特性を使うとグッとくる製品はできないよ」ということを言っていました。
これを聞いて自分はハッとしました。Σ(ﾟДﾟ；)
テスト設計コンテストに参加したときは網羅を意識して最初から品質特性を用いていました。また実際の業務でも品質特性に基づいて初めから品質の定義をすることが多かったと思います。でも確かに最初から品質特性を使うとヌケ・モレは防げますが、製品・サービスのコアになるべき機能が全くトガらずに、ありきたりなものになる可能性がありそうです。
この問題を解決するため(*1)に、狩野モデルを使ってこの製品・サービスのコアになるトガった機能とそれ以外の機能に分けて考えてみます。
- 魅力的品質 ：製品・サービスのコアになるトガった機能
- 当り前品質 ：上記以外の機能
順序的には、トガった機能にあたる製品やサービスの魅力的品質をまずしっかりと考え抜き、その後、当り前品質を考えるときにモレ・ヌケがないように品質特性を使うといいのですね (*・Д・)ﾅﾙﾎﾄﾞﾈ-
ところで本当に魅力的品質かどうかはどうやったら分かるのでしょうか？
机上で品質特性の一覧とにらめっこしていても答えはでないと思います。 COOKPADの高井さんの発表（*2）から引用しますと、「要求事後性：ソフトウェアが要求を満たしているかは、ソフトウェアを使わないと判断できない」ということです。もちろん特定のドメインのソフトウェアに おいては簡単に使ってもらうことが難しい可能性もありますが、Webサイトやスマホアプリなどのソフトウェアは使ってみることでフィードバックを得ることができます。
リーン・スタートアップでいうところのMVP（Minimum Viable Product）で作り込む機能も、魅力的品質（と思っているモノ）に属する機能とその魅力的品質が成立するための必要最低限の当たり前品質の機能が対象になると思います。そしてMVPのリリースとフィードバックを繰り返していくことで、ユーザーにとっての本当に魅力的品質かどうかを判断していくのですね。
特に目新しくはないと思いますが、自分にとっては品質特性の使いどころを改めて整理する良い機会になりました。
次回はきょん君お願いします♪
*1 @snskが提案している品質特性自体に重みをつけて品質モデルを定義するという方法でも解決できそうです。詳しい説明はAndroidアプリテスト技法（秀和システム）を参照のこと。
*2 JaSST’14東北発表資料 https://speakerdeck.com/takai/cookpad-and-test-automation
2014/12/18 追記
安達さんからコメントありましたので、そのまま転記しておきます。
私のコメントの真意は「いきなり品質特性を使うとそれに一律はめ込んで満足する＝特徴的な要素が尖らずに平坦にしてしまう人が多いんだよね」です。十分に使いこなすスキルを持っている方は大丈夫ですが、そうでない方が使うと特徴のない平坦な結果ｗｗを出しがちなのでこのコメントになっています。それを防止する一つの手段として、①品質特性を使わずに特徴的な特性を明確にする（尖らせる）→②そのあと何か忘れているモノがないかを確認する意味も含めて品質特性を使う、というやり方を紹介しました。
