那須野が原ハーモニーホールで行われた「とちぎテストの会議04」に参加してきました。
d.hatena.ne.jp
今回で2回目の参加になります。
前回参加した時の記事はこちら。
toshimana.hatenablog.com
今回の昼食はご当地大盛中華料理店「阿Q」で揚げ焼きそば、肉丼、餃子をいただきました。仙台テストクラスタのマスコット様と一緒に食べたんですが完食ならず…
余りは持ち帰りパック(お店で販売してる)に詰めて持ち帰りました。
「つくるいとなむ」をテーマにしており、
テストの話だけではなく、教育、成長に関する話が多かったです。
とても刺激的な話を沢山聞くことができました。那須、楽しい。
招待講演
『失敗ばかりの開発チームをいとなむ』椎葉さん(@bufferings)
良いものを作れたら嬉しい、と大体のメンバーが思っている。開発チームで良いものを作る方向に動いていない(と自分が思う)ことが多い。悪いのでは人ではなく「場」。人の動きを阻害する「場」を何とかする。何度も繰り返し伝えたり、自然と気づける仕組みを導入したりした。
感想
環境を変えると人も変わる。椎葉さんは恐らく「文化」を作ったんだと思う。
あと、自分の愛娘を預けたい、と思えるチームを作るというゴールがあることが素晴らしいと思った。自分のためにチームと一緒に成長したいという、理想的なモチベーションが保たれていると感じた。また、自分事だからこそ、現実から目を背けずにいられるのだと感じた。
一般講演
[経験と、ルールと、知識と] 松尾さん(@Kazu_cocoa)
障害の再発防止として、「今は経験ベースだから、ルール(自動化、チェックリスト化)ベースを増やしていこう」というのを実践し、さらに踏み込んだ内容。ルール／知識ベースの障害対策を覚えた人より、経験ベースの人の方が障害が発生した時の事後対応を適切に行える。しかし、失敗への予防は経験だけよりも知識／ルールがある方が役に立つ。重要なのは学ぶこと(対象を理解しようとすること)。知識／ルールも深掘りすることにより「経験」を覗くことができる。それを自身に転化できたら面白い。
感想
ルール／知識を中心に理解した場合、そのルール／知識にしか焦点が向かなくなる「思考が縛られる」状態に陥ることがある。ルール／知識はとても有用だが、思考が狭まるものにならないよう、学び続けることが必要だと感じた。
[チームメンバーを"テスト"する] やっとむさん(@yattom)
www.slideshare.net
新しいチームメンバーには定期的に(毎週)試験を実施する。試験は点数を判断するものではなく、チームが何を大切に感じているかを伝えることに利用する。
[剪定テスト] よねざわさん(@vestige)
剪定（せんてい）とは樹木の枝を切り、形を整えたり、風通しを良くする事。 見た目を美しくするのみでなく、養分を効率よく利用させて生長を促進したり、病害虫の繁殖を予防する効果がある。*1
[0からはじめたUIテスト・ABテスト～スマホアプリ開発の経験をもとに～] @ki_macho
大学生が作ったアプリでUIの改良にABテストをやってみた。大学生のアプリ作成はウェーイになりがちだから、しっかりした方法でやりたかった。
[テスターのドロア（わたしのあたまのなかのひきだし）～プログレスダイアログの巻～]みわさん(@miwa719)
みわさんがプログレスダイアログをテストするときのテスト項目の紹介。「何を考え、何を心配しているのか」を伝える目的。
プログレスダイアログの「しばらくお待ちください」のメッセージがあるとき、時間が長すぎないか、短すぎないかがテスト項目にあるなど、仕様書には出てこないような内容もテストするところは流石だと感じた。
[割とみなさん挫折しているかと思いますが、実践アジャイルテストの第５部は意外とよく出来てると思います。正誤表もででます。] 川口さん(@kawaguti)
speakerdeck.com
タイトルの通り。途中で出てくる第5部の全体像の図は世界一わかりやすい(らしい。川口さん談)
[テストと情報エントロピー] 松山さん(@Dai_HungryWater)
www.slideshare.net
テストの良し悪しを情報エントロピーで表現できるのではないか、という話。情報エントロピーが大きいテストほど良いテストなのではないか。
[かえりみち] (@track8)
speakerdeck.com
雪月花に合わせて季節に沿ったバグを紹介。ログ出力の年月日が日本表記か英国表記かの違いと最新ファイルの指定方法が名前ソート(年月日が日本表記でしか機能しない)が組み合わさったバグ、熱によるクロックダウンによるシステムの速度低下、サマータイム問題など。だいたい、エンジニアは何もしていない。
「チョットデキル人に訊け！」
秋山さん(@akiyama924)、和田さん(@t_wada)、関さん(@m_seki)によるパネルディスカッション。和田さんだけお題を事前に聞いていないというサプライズがありました。秋山さん、関さんが事前に準備した回答であることを強調し続けるおまけ付き。
ここまでプレッシャーを感じるパネルディスカッションがかつてあっただろうか…… #toteka
— Takuto Wada (@t_wada) April 23, 2016
凄い人の話を聞いたときどうするか
秋：凄い話は理想に近い。理想と現実のギャップを理解すること。
和：成功した人がする成功した話は一番きれいな話。そこから成功のパターンを掴むことが大事。あと、前に出てきていない話(苦労話など)を聞く。
ちゃんとテストしているか
秋：リスクの高い項目(健康・財産・環境)は特にテストが必要
和：開発と品質保証のテストが異なる。開発は自身が近くした範囲でしかテストできない。開発者が自信を持てるテストと製品として十分な品質を担保するテストは異なる。品質保証のテストを行うには、自分が見ている枠の外に視野を広げる必要がある。他人の考えをテストに取り入れられているかが重要。
テスト上手くなりたいか？
関：テスト上手くなりたい、とは思わない。興味のあることをやっているだけ。
感想
「興味があることだけをやっている」という関さんにとって、テストを含む多くのモノはその興味を満たすために必要だからやっている、という感覚なのかと思った。ぶれないビジョンがあるからこそ、良いものを作るために淡々と前に進めるのだと感じた。
その他
テストの地図
みわさんから「テストの地図」についてお話しいただきました。良い価値を届けるための開発に使えるテスト技法としては「テストの地図」はこれまで触れた中では最も理想に近いと感じた。
miwa719.hatenablog.com
テストの地図、いろんな人に見てもらえてよかった。ディスカッションしながら地図を作っていく過程がとても大切で、それを伝えたくて昨日の夜、資料を作りました。コメントも貰えて嬉しかったです。ありがとうございました♡ pic.twitter.com/0HrhCUPnt3
— miwa (@miwa719) March 8, 2016
感想
感想をまとめるの大変なくらい盛り沢山の内容でした。また来たいです。
