はむはむエンジニアぶろぐ

365日エンジニアリング

Nagoya.Testing in Tokyo -テストを強いられている人達の話- に参加してきた

Nagoya.Testing in Tokyo -テストを強いられている人達の話- に参加してきた。
チームビルディングについて自分と異なるアプローチをしていて、その考えは自分になかったわ とハッとさせられました。
思ったこととかまとめておく。

アジャイルテスティング -バグ埋めこみを年間1件にまで減らした戦略-

speakerdeck.com

関連資料

www.slideshare.net

大量の失敗を許容する。
自由を与えても自由になれない。
規律もセット。
チームに自由と規律を与えて制限を外す。
ただ、世界最高のチームとしてプロダクトをリリースすることに集中する。

何度も伝えたりヒアリングしたり課題を分析する。
自分で気づくように仕向ける。

積極的に暗黙知を作り共同化する。
形式知にすることは継続しない。
形式知を継続することに、こだわらない。
レビューの方針などは形式知化することは難しいし、形式知化したところで活かすのも維持するのも難しい。

プリント毎にPO、エンジニア、QAを入れ替える。
新人でもPOをやらせてみる。
もちろん、うまくいかないけど短いスプリント期間なので問題にならない。

一番刺さったのは、形式知にこだわらないこと。
経験させてしまえば暗黙知でもやっていける。
積極的に色んなことを経験してもらうのは大事だな。

F#用テスティングフレームワークPersimmonに関する何か(仮)

最初は、エクセルの話だったけどF#の話になってテストの話になってあれ?なんの話聞いてるんだっけ?wってなった。
新鮮な発表でした。

資料公開待ち。
エクセルで資料を作られていたので公開されることはないかもw

ユニットテストフレームワークあれこれ

ユニットテストフレームワークあれこれ
NagoyaTesting20161215.md · GitHub

テスティングツールは使うことを強いられるのではなく強いる側になろう。
かっこいい。