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

kentana20 技忘録

技術ネタを中心に、セミナー、勉強会、書籍、会社での出来事を綴っていきます。不定期更新。

テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする@デブサミ2014

2/13(木)、14(火) に目黒の雅叙園で開催された「Developers Summit 2014」の参加レポート#3です。

f:id:kentana20:20140214183727p:plain

テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)

今年はランチセッションなるものがあり、お昼の時間帯にサンドイッチ(無料!)を食べながらショートセッションを聴くという参加者にとってはランチの時間を効率的に取れるとっても良いスタイルでした。昨秋に行われたDevOps DaysでもYahooさん・Microsoftmさんが同じようなスタイルでランチセッションを行っていましたが、1日フルで開催されるイベントだと、お昼をどうするかいつも迷うので、こういう形が増えてくると個人的には嬉しいですね。

コベリティジャパン安竹さんによるテスト自動化についてのセッション。テスト自動化についてはSelenium, Appium, Cucumberなど様々なOSSツールが出てきて、CIの普及とともに今後も活発に活動していくことが予想できます。そんなテスト自動化についての5つのTips的なお話。

5. テスト自動化は本当に必要か

同じテストを4回繰り返すと、コスト的には大体ペイできる

平均値を取ると、これくらいというお話だと思いました。issueの内容やシステムの精度などの因子によって大きく変わると思うので、ここでは一般的なお話として解釈します。

不具合を承認してから、解決するまでに平均9.9日かかる

リリース後の不具合だと、やっぱりこれくらいの時間がかかってしまうんですよね。いかにサービスレベルを小さくして、大規模リリースを避けてissueの数を管理できるようにしていくことが大事だと思いました。

すぐに人をアサインすると9.9日が7日くらいに短縮できる

これも大事ですよね。担当者をアサインすることで、issueに対するオーナーシップが増えた結果がこういった数字に現れているんだと思います。

新しく見つかった不具合から先に対応するほうが効率が良い

これは当然と言えば当然かもしれません。再現率も高く、対応しやすいですし、issueの発生はリリース起因が大半なので経緯をトレースしやすいのは新しいissueです。

放置された障害とすぐにアサインされた障害では、修正コストも変わる

これも上と同じ理由という理解です。

コベリティはスクラムを回している

やはり、スクラムが最適解の1つなんだと思います。発生したissueとビジネス上の課題をバランスよく、効率よく回していくためには小さいチーム(ユニット)でコツコツ改善を続けていくのがベストだと自分も思います。

4. 担当者のスキルセットは正しいのか

QAチームがプログラミングについてトレーニングされていなくて、テストスクリプトを書けないという事態が発生した。対策として、テスト自動化に焦点を当てて、スキルセットの変更を行った。

これは「超あるある」ですよね。モダンな開発ではテストエンジニアもコードを読み書きできないと、仕事にならないということを強く感じます。結局のところ、ディレクションをしようがデータマイニングをしようが、テストをしようが「コードが書ける」ということが非常に重要なスキルになっているということだと思います。非常に共感できます。

3. コードカバレッジの罠

静的解析エンジン(コールグラフ・条件分岐)などを使っている。コードカバレッジ100%でも障害発生率は0にはならないので、そこだけに目を向けてはいけない。機能としての重要性・優先度を決めてカバレッジの妥当性を判断するべき。

2. 優先度を設定しているか

修正対象のコードからテストを書いていくのが一番効率的だと思われる。ここでも「優先度を決めて」というお話がありました。

1. クリーンなコードになっているか

結合レベルでもクリーンに保たれているかをしっかりとレビューする。コーディング → ユニットテスト・コード解析 → テスト(差分テスト)という流れが一番良い。 また、役割に求められるスキルセットに応じて適切な開発者をアサインすることも重要。

所感

カバレッジに目を向けすぎない」ということが大事であるということが印象に残りました。どうしてもカバレッジを数値化すると100%に近づけて行きたくなるのが人心なのですが、機能としての重要度や利用頻度に応じてテストを書くコストメリットがあるかを修正時に判断してテストを書いていくかを決めるべきだと感じました。一休では「コードカバレッジ」なんて言葉が無いくらいテストを書いていないので、これから実施をする中でこのお話を思い出してテストを書くかの判断をしていきたいと思いました。

また、人材の育成・確保という意味でQAにフォーカスしたエンジニアを育てていく文化も大事だと思いました。これから「テストスペシャリスト」のニーズが増えていくのは明らかなので、先行して強化していきたいです。 サンドイッチを食べながら聞いていたので、メモが薄くてしっかりまとまっていませんが内容は面白かったので、スライドが上がったら更新しようと思います。