7月4日に第三回ギア本の読書会がありました。
software-test-automation.connpass.com
今までは司会をしていましたが、今回は発表をしました！
しかも2章分！
今回は第5章を@masatoshiitohさんが、第6章と第7章は私が発表を行いました。
発表資料
以下、自分が担当した第6章＆第7章について書きます。
会場へのアンケート
発表の中で、以下のアンケートを取りました
前処理として、どうやってデータを用意しますか？（スライド16枚目）
こんな結果になりました。
画面操作をしている人もDBと併用しているそうです。
また、DBスクリプトで用意している人もDBの仕様変更にはその都度、手作業で対応しているそうです。
ギア本の中では「前処理や後処理を自動化することは比較的容易」と書いてありましたが、実際はそこまで容易ではないのかも。（もしくは自動化の優先度が低いのかも）
会場への質問＆会場からの質問（第6章）
アンケートのほかに、色々と質問をしました。
「フェールセーフの考えを用いて、後処理が失敗ならテスト自体も失敗扱い」は本当にそうすべきか？（スライド23枚目）
賛成派
- 場合にもよるが、後処理がきちんとしていないことで次のテストケースが正しく出来ないこともあるので失敗にすべき
反対派
- テスト自体はせっかく成功したのに失敗扱いにするのはもったいない
- 開発者やお客様などに説明がしづらい（「テストは成功しましたが後処理が失敗したので失敗です」と言っても理解はしてもらいかも）
失敗原因としてDB状態を保存するとき、どんな内容を保存すべきか？（スライド24枚目）
- テスト前のDB状態との差分があったものを保存すると良いのでは
前処理としてAPIを使う方法が紹介されたが、APIのテストは行わなくて良いのか（スライド14枚目、読書会終了後に個人的に質問された内容）
会場への質問＆会場からの質問（第7章）
第7章でも気になることを聞きました。
テストケースを草刈りすべきか？（スライド5枚目）
反対派
- テストケースを削ることで、今まで発見できたバグが見つからなくなりそうでこわい
- 容量が少なかった時代の話で、今は余裕があるからそこまで積極的に草刈りをする必要がないのでは？
賛成派
- そもそも削ることを怖がるというのは、きちんとテスト設計できていないのでは？
- 草刈りを考えるのではなく無計画に増やさないように努力すれば良い
- 草刈りというと削るイメージがあるが、重複したテストケースをマージする方針であればすべきだと思う
草刈りはどのタイミングですべきか（スライド5枚目）
- 余裕のあるとき
- 同じようなテストケースを作ることになり、マージが出来そうなとき
※草刈り（リファクタリング）の方法については、こちらの資料を参考にすると良いかも
具体的に採用している命名規則はあるか？（スライド22枚目）
- 最初に対象のお客様名を付ける
ドキュメントはどこまで詳しく書くべきか（スライド30枚目）
- これという決まりは無いが、チームとして統一できると良いかも
- きっと書く側よりも、読む側の方がよく気付くので、レビューを受けて徐々に決めていくと良いと思う
- 結果、テンプレートみたいなものができるとなお良いかも
メンテナンスユーティリティとはどのようなものか？（スライド35枚目、読書会終了後に個人的に質問された内容）
- ラッパーになるライブラリなど
- 各個人が独自実装しないようにするためのツール
参考資料
第7章スライド21枚目（並列化）の補足資料
感想
- 自分が担当した6章＆7章は参加者もなかなか実施できていないところで、みんなで模索した感じでした
- もう少し参加者と対話型の発表にできればよかったのかも
