前回に引き続き抽選に当たったので、参加してきました。
前回の勉強会の記事についてはコチラ
今回はメモを手書きで取ったため、抜けが多いです。
口頭の説明を中心にとったので、公開されたスライドの補足的に使ってもらえればと思います。
はじめに（松尾さん）
スライド
www.slideshare.net
※p6まで
前回と今回のテーマについて
- 前回はcheckingをテーマにした。
じゃあテスティング話したい cc @t_wada @miwa719 #cooketn
— seki at druby.org (@m_seki) October 21, 2015- 今回はtestingをテーマにすることに。
「今回は面白いと思うので」という言葉を残しつつ、関さんにバトンタッチ
前振り（関さん）
スライド
※p24まで
設計とテスト
- ソフトウェアの開発とは2種類の作業を含んでいる。設計とテストである。
- 計画を立てることも設計の1つ
- 良いテスト=エラーを発見できるテスト
- testingの方が近い
checking vs testing
- checkingは待ち伏せ
- testingは探しに行くこと
私達のtesting
- 感じる＆壊す
- いつ感じるのか？
- 製品を目の前にして
- 使いにくさ（「仕様書に書いていない」も含む）
- 朝会
- 「仕様です」「合意しました」はおそらく失敗している（なので禁句にしている）
- 対象
- 製品はもちろん対象
- チームも対象
- 製品を目の前にして
- 感じた後どうするか？
- 理解する
- 考えながら触ってみる
クックパッドでのtesting（松尾さん）
スライド
「はじめに」と同じスライドのp7～p21
普段の観察
- 朝会（いろいろな部署からの共有）
- いつもと違う？→バグへと繋がる
- 寝不足
- メンタルは大事
- いつもと違う？→バグへと繋がる
- issue
- やり取りの多さ
- 関係者の多さ
- 話の複雑さ
- チャット
- 雑談、話題
- ガヤガヤしてる→集中できていないかも？
- 雑談、話題
- 席周辺
- 人の往来、相談回数
- 松尾さんの席の近くは技術基盤チームなので、そこと相談しているものは気になる
- 人の往来、相談回数
- 製品を触る
- アプリを触る時
- 感情の変化
- 違和感という直感
- アプリを触る時
感じ方、知り方を拡張する
- 多彩な経験、考え、歴史
- 話す、見る、聞く…
視点を動かして拡張する
- 大局⇔局所
- 組織⇔事業
- 全体の振る舞い⇔部分的な振る舞い
- 役割の切り替え、つなぎ目に注目する
感性/考え方
- 変わらない/変わりにくい
- 脳の成長は25歳ぐらいまで
- 変わるにはストレスがかかる
- 変化することを知る
- 動機、環境、組み合わせ
- 振り返りからの改善とか
- 動機、環境、組み合わせ
miwa style（深谷さん）
「前振り」と同じスライドのp25～p60
朝会から何を知るのか（機能的なことは前提として）
- 担当者を知る
- 最良のアクセス先を知る
- どんな人なのかを知る
- 人に合わせてテスト内容をトッピングする
- 揉めていることを知る
- ある部分で盛り上がったチケット
- その裏で盛り上がっていない内容には要注意
- ある部分で盛り上がったチケット
- プログラマが混乱していることを知る
- プログラマは分かっていないことを気づいていないかもしれない
- プログラマが心配していることを知る
- 作れると思って作っている人？…そう思っている人に「なめんな」と言いたい(by関さん)
- 周りが「ヤバイんじゃないか」と言っていることに気付くようにする
- 声の調子
- 不安そうな時は不安そうにしていてほしい
- 自信満々にしていると関さんにやられる
- 心配事をこちらから話す→実装することを気にしてもらえる
- 朝会中もエアテスティングしている
- 報告されたバグから多くのことを知る
- 知らなかった過去を知る
- 昔のチケット
- 誤解した仕様を知る
- ここまでの内容は以下の記事に書いてあります。
あるチケットのTesting
- チケットを読む
- 何が出来るようになったの？
- 出来たことはどうやったら分かるの？
- 実装中に起きていたこと
- 朝会で聞いてはいるが、新たな気持ちで
- 気になったメモを読み返す
- 怪しい匂い
- 沢山書いてる
- あっさりしている
- 説明がコードっぽい
- 「苦戦中です」と書かれている
- 簡単に書いてる
- 結局どう書いていても匂う
- 動かしてみる
- チケットに書いてあるテストケースを忠実に行う
- checkingの気持ち
- ファーストインプレッション
- 初見に感じる「何か」を大切にする
- チケットに書いてあるテストケースを忠実に行う
- Testing
- テストケースを変形する
- 表には出てこない処理を思い浮かべながら
- 複雑なものほど丁寧に
- 面倒なもの（複雑なプログラムなど）ほどじっくりと
- 匂いの種類や強さによってバリエーションを変える
- 「テスターによって壊し方が異なる」(by関さん)
- 関連するかもしれない機能との相性
- 話題になっていないものこそ注目する
- 入力はどこから来るのか
- それを使う機能を試す
- 別機能と一緒に使ってみたらどうなるのか試す
- チケットのキーワード検索から関連のものを探す
- テスターモードからユーザーモードへ
- ユーザはどんな気持ちで触れるのか
- ユーザは次に何を操作するのか
- ユーザのユーザのユーザを考える
- 例1）クックパッドを見て料理したお母さんの料理を食べる人（ユーザのユーザ）
- 例2）クックパッドを見て指導した家庭科の先生の元で調理実習した生徒が、その料理を披露してお母さんに報告する（ユーザのユーザのユーザ）
- 機能寄りではなく、やりたいことをやれているのか調べる
- 「やり過ぎ」にも気付くことができる
- 過去に起きた嫌なこと
- これから起こるかもしれない嫌なこと
- 不安なことをいろいろな人に話してみる
- 昨日との違い
- プログラマとの会話
- 「こういう所が不安」「実は…」みたいな話が聞ける
- プログラマと一緒にテストしてみる
- プロ無職（関さん）との会話
- 直球で「ここにバグがあると思うから」と言われる
- 「休んだら？」とテストを止めに来る係りでもある
- 「集中しすぎるのは良くない」(by関さん)
- テスターとの会話
- おかしいと思うことを他のテスターはどう感じるのか
- テスターが作ったテストもどう感じるのかは重要
- ペアテスティングをやってみる
- おかしさを見つけたら開発者の元へ
- 鮮度が良いうちに現象を見てもらう
- ログを取る
- 再現しなくてもログから分かることもある
- テストケースを変形する
まとめと所感（関さん）
スライド
- 「前振り」と同じスライドのp61～p68
所感
- テスターは「テストを書く」とは言わない。「テストする」とは言う。
- Feelingを育む土壌が重要
- 人がミスするのは当たり前ということを受け入れる空気も大事
さいごに（松尾さん）
- testingは人によるものが多いが、勉強会では話されないことが多いので、こういうことも共有していきたい
質問
心配事を話す時に設計上の情報を共有してもらっているか？それとも漠然とした捉え方か？
- 他の人との会話を聞いた上で、大きなレベルで捉えている。
心配事を話すタイミングは？
- 9:15～9:45が朝会。その後に、朝会の2次会が10分ほどある
- 新人を育てるには、2次会で育てれば良い(by関さん)
- また、テスト環境はすぐに用意できる状態にある
チケットの粒度や期間は？
- チケットには機能単位
- 半日～2日程度
- 追記はあり
- テスト技法に従ってテストケースを書いてもらっていたりもする
チケットに書いてあるテストケースというのは開発者が考えたテストケースか？
- そうです。
- バグを出したい気持ちで書いていると思うが、基本的なテストケースである。
探求の終着点はどこか？
- 基本的には時間で区切る。
- チケットによってその時間もまちまち
- 通常、約3個/日のチケットをクローズしているが、日をまたぐこともあり
時間で区切るのは経験から？
- 感覚で。
- 「もういいよ」という雰囲気になったら
- リリースまでに全てのチケットを見えるようにするのが大事
- 残業すると周りのプログラマがざわざわする
ペアテスティングを行うと、「ここは他の人がやってくれるから」みたいな仕切りを作ったりしないか？
- 私の方から壁を作ることは少ない
感想
- 人の往来の多さを気にするという感覚はすごい分かる。
- 私個人としては、コミットの多さとかも気になることがあるぐらい。
- 朝会の二次会っていいな。
- ちゃんとその時間の枠を確保しているのも素晴らしいです
- 担当者を知って、その人と適切に話すと言ったことは、TPI NEXTのコミュニケーションのエリアが効率化レベルまで行っているように感じました。
- checking→testingと話してきていたけど、ユーザーモードの話とかはUXの分野にまで踏み込んでいると感じました。
- 明確な区分をする必要も無いと思うけど
発表後の懇親会の内容
- 別記事にしてます。
