読者です 読者をやめる 読者になる 読者になる

とちぎテストの会議03 参加レポート

とちぎテストの会議03、通称とてか03に梅ちゃんとまなべーと参加した。

とてか02に参加したときにも思ったのだが、"日常"というのがテーマになっているので、開発者とテスターのお互いが普段どう考えているか分かりやすい。とてかは開発とテスターが融合するイベントになっていると思う。

何より雰囲気が暖かいのがイカしてます。

「いかす!」のために大事だと思う4つのこと / 湯本さん

f:id:nemorine:20141011144118j:plain

日本HPの湯本さんが日常生活を振り返り、イカしていると思うことを話してくれた。 本編ではまさかのタイムアウトということで、続きが懇親会という2部構成(笑 http://www.slideshare.net/yumotsuyo/toteka3

定期的なトライ

テストケースを作ると同じ組織でもバラバラになる テストケースを作るときにルールを作る メンバー間の相互理解を促進する環境を作るのが重要。 そしてテストプロセス全体を知ることでテスト技法の使いどころや自動化に必要なことが分かる。

人の知見吸収

本のままの知識ではなく、現場に適応するのが重要である。
特に自分が知らない新しいシステムに本気で対応することで湯本さん自身の勉強になる。

目的再考

近頃は大学でテスト(ゆもつよメソッド)の研究を実施している。
なんでやっているか考えてみたところ以下の3つが出たとのこと。

  • 論理的思考の訓練
  • 刺激
  • 資格
無駄をやめる

この基調講演の依頼を受けたとき、1週間の自分の時間を考えてみたら、色々ムダが多くて、愕然となった Σ (゚д゚lll)

感想

普段のセミナーやシンポジウムではなかなか聞けない湯本さんの日常を垣間見ることができた。その中で自分が気になったことは2つ。
1つめは湯本さんのコンサルではこうやりなさい!ではなく、如何に組織が自立的に回るようになるかということにもフォーカスしているようで「テストの目的」にあたる合意形成をキチンと取っているのがいいと思った。意味無いと思っているテストは誰もがやりたくないもんね。
2つめは何にでも真摯に向き合うこと。例えコンサルでも大上段から構えずに、自分なりの考え(テスト設計など)を持って現場とガチでぶつかるってカッコいいなーって思う。コンサルもQAもそうだけど外からいうだけだと現場は動かないことが多いと感じるし。しかもその忙しい中で博士号を取ろうと頑張っているなんて…
湯本さん… イカしてます!!

忍者式テスト 中島さん @ledsun

気になっていた忍者式テストの発表。
事前に少し調べていたが、実例はいつも楽しみ♪
http://www.slideshare.net/ledsun1/03-39903732

状況

あまり変更したくないコード(ヒドいコード)に機能追加するために、リファクタリングとして様々なパターンを適用し分割する。GUIからテストをしたかったのだが、自動化している暇がなかったので、毎日手動でテストを実施する忍者式を選択した。チームメンバーは中島さん一人。

方法

優先度のついたテストケースを用意し、毎日それを上からテストしていく。新しいバグが出たときはケースを上に追加する。そのことで枯れたテストはだんだんやらなくなり、バグがあったケースが何日間かテストされることになる。テストにかける時間は30分以上。

結果

忍者式テストを導入し実施したところ、新しいバグが見つかってきた。忍者式テストには、どうやらCheckingだけではなく、Testingの要素(*1)もあるのではないかとのこと。

感想

あるなんとか動くコードがあるときに、コードに極力触ることなくテストで抑えようというテストダケガンバルパターンがある。それとは別にコードカラミナオスパターンがある。今回の中島さんの例はコードカラミナオスパターンでかなりガッチリやっている感じ。ここらへんの考え方は咳さんがズバッと切っている記事がある。

中島さんの忍者式テストを自分なりに考えた結果、少し抽象度の高いテストケースをチャーターとした「探索的テスト」に近いと思う。ある軸になるテストケースを決めておいて、そこから派生するケースを毎日コツコツ実施していく。同じことはやっていないので未知のものを発見するTestingの要素が出てくるんだと思う。毎日実施する忍者式の最大の弱点は「飽きること」だと思っているので、前の日とちょっと違うことをやることでテスト実施者(=今回は中島さん)のモチベーションは維持されるみたい。 完全にフリーの探索的テストだと証拠が残りにくいなどデメリットがあるが、中島さんの忍者式テストだと抽象度の高いケースは残るので忘れることはないのではないかと思った。
この仕組みは結構面白いし、色々使えそうだなぁ〜

中島さん… イカしてます!!

※1 ChekingとTestingの違い
Checking 既知の情報を確認する行為 Testing 新しい情報を探す行為
参考)JAMES BACH'S BLOG http://www.satisfice.com/blog/archives/856

中島さん語録

名言があったのでまとめておく。

  • テストは健康な状態でやらなければならない
  • テストをやめる基準は感性
  • 毎日テストしないと怖い

イカついパネル

お題
http://d.hatena.ne.jp/m_seki/touch/20140930#1412073967

聴衆全員がパネリストになるイカついパネル。全然イカつくなくてワイワイと盛り上がったw 最初にmiwa719さんから説明でもやもやしたらOKっていう説明があった。懇親会で関さんとも話したが、色々な考えがあるってことを気づくのが目的にする場合はまとめずに参加者に考えてもらうのがいいなぁと思った。

ワールドカフェ

今回の使用したタイマーの実例を使って、どうしたら良いかみんなで考えるワールドカフェ。タイマーの付加機能としてアニメーションの機能を実装したが、イベント2日前に全く動かなくなって不安になってしまった。明日が本番の場合どうするか?!
開発者とテスターが入り交じっているイベントのため、両方の意見が結構出ていた。自分が覚えているだけ書いてみる。

  • バックアッププランを用意する
  • タイマー機能だけリリースすればよい
  • そもそもタイマー機能だけだったら、このタイマーの意味はない。踊るから意味がある
  • このイベントではバグが出たら逆に盛り上がる
  • 不安の元は何だろうか?明らかにする
  • 言語の問題が不安に影響しているかもしれない
  • メインのシナリオはテストしておく
  • タイマーのテストは長いので面倒である
  • 落ちても再起動すればOKかどうかをテストしておく
  • 拍手を誘導するというタイマーでもOK
  • 運営スタッフが自分たちで作るから意味がある
  • LT用のタイマーでも機能的には代用できる
  • 踊るという魅力品質はいいが、当たり前品質のタイマー機能に影響あるのは困る
リンク等

まとめ
http://togetter.com/li/729139

懇親会で小井戸さんが発表したLT ← これまた熱い… http://www.slideshare.net/koido1961/ss-39837146

参加報告 toshimana's diary http://toshimana.hatenablog.com/entry/2014/10/05/130224

うーん とちぎ熱いですね〜
仙台も負けずに頑張らないとですね。
スタッフの皆さん、スピーカーの皆さん、参加者の皆さんどうもありがとうございました!
みんみんの餃子も美味しかったです♪