今日は北海道土産のとうもりこがメインのお菓子です。
これめっちゃ美味しいので是非食べてみて♪
まずはいきなり質問してみました。
『テストケース通りにテストを実施したときに、違和感を感じてちょっと入力値を変えてみたらバグが出た。こんな経験がある人！』
手が挙がったのは参加者の半分くらい。
これって実は小さいながらも探索的なアプローチをしていますよね。
探索的テストの定義(Cem Kaner)
□ソフトウェアテストの一つのスタイル
□個人に自由意思を持たせるとともに責任をより明確にする
□一個人のテスト活動である
□継続的にテスト活動を洗練させる
□探索的テストは以下の活動を行う
テスト関連の学習 / テスト設計 / テスト実行 / テスト結果報告
□成熟したテスト活動
□上記の活動をプロジェクト期間中並行して行う
探索的テストの定義(James Bach)
探索的テストは、学習、テスト設計、テスト実行を平行して実施するものだ
その後、探索的テストの歴史と探索的テストとスクリプトテストの話をgoyokiさんのスライドを使って説明しました。このスライドはとても良くまとまっているので、是非確認してください。
探索的テスト入門（http://www.slideshare.net/goyoki/ss-34292539）
自分のイメージだと探索的テストは対話型のソフトウェアテストだと思っています。
医者が患者を診察するように・・・
旅人が素晴らしい景色を求めて町歩きをするように・・・
合コンでお目当ての女の子の笑いのツボを探すように・・・
そして探索的テストに必要なのは以下の3つ。
１．製品知識
２．テスト技術
３．バグの知識
これがないと実はただのアドホックテストなのに、名前だけが探索的テストってことになりそうだなぁと思ってしまう。
さてそしてお楽しみの実践編。
かんばんリストのマニュアルをチャータ※に用いた探索的テストを実施してもらいました。
http://kanbanlistfortohokutest.herokuapp.com/
参加者の製品の理解は少ないので、マニュアルを用いた探索的テストを実施することで、製品に対する知識を深めてもらうのが狙い。
同じような状況はスモークテストなどでも使えると思っています。。
※チャータは探索的テストの道しるべになるようなもの
そして、みんな・・・
超真剣っ！！
20分間くらい実施してもらいました。
出している人、苦戦している人両方いましたね～
さてその後、グループごとに話してもらい面白いバグをグループごとに出してもらいました。
Aチーム：ある操作でタスクが登録できなくなる
Bチーム：&3069がampになる
Cチーム：Bookに改行を入れるとBookとして認識されなくなる
実はBookとTaskは分かれていますが、内部的にはひとつの文字列ということで、ここらへんを攻めている人が多かったのかなと思います。
これも実際のソフトウェアを触ることで内部の動作を推測し、新たな視点の操作を実施してみるというのは探索的だなぁと思います。
次のワークとして、Pass基準とFail基準を作ってみました。
そしてその基準をグループ内で交換し、探索的テストを実施しました。
時間が足りなかったので途中で終わりましたが、、、
なんと･･･かんばんりすとfor東北テストが落ちてました ＞＜
誰かが凄い操作を実施したのではないでしょうか（笑
また最後に探索的テストをやった証拠を残すにはどうしたらいいのでしょうか？と質問がありました。
ソフトウェアテストの7原則のひとつに『1.テストは欠陥があることしか示せない』というものがあります。個人的にはですが、毎回コンスタントにバグを出して、『この人は常に本気で、かなりのバグを出せる』というブランドになるくらいじゃないとダメだと思います。
それくらいになって初めて、この人がやりましたということでチームのメンバーが納得するようになるのではないでしょうか？
それには開発にレビューとして参加したり、テスト技法を勉強したり、過去のバグの傾向を把握したりとかなりの努力が必要になると思います。
でも実際に動くソフトウェアで演習するってやっぱりいいですね！！
来月は探索的テストのツアーを使って実施してみようと思います。
お楽しみに♪