GREE Tech Talk #4 パネルディスカッション

Jenkinsによるテスト自動化の

会社への導入

パネラー：太田 健一郎 (株式会社SHIFT)

パネラー：岡崎 隆之 (グリー株式会社)

モデレータ：粉川 貴至 (株式会社セガ)

おおまかな流れ まず、パネラー自己紹介＆事例紹介 各10分 そのあと、会場に振りますので、 ・各事例に対して聞きたいこと ・各自の現場で困っていること など、考えておいてください。 本日の資料は後日公開します

3

4

5

話題 Q:静的検証ツールを使う メトリクスや指摘をどの程度反映するかはQA側が指示するのか？ A: 一番緩い（クリティカルな）部分だけ指摘する。

サイクロマチック数などは、かなり緩い限界値だけ示す。 どちらかと言うとアーキテクトの人が言う まずは下限を防止して、だんだん上げていく 教育と合わせて。

6

話題 Q:CI導入時に、 開発者の手元で先にテストを走らせるべきか インテグレート時にやるべきか 両方？ A: できれば両方。

ケースによる。環境依存やサーバでやった方が速かったり。少なくともどちらかではやる。

自分で書いた部分だけは自分の所で、その先はサーバというパターンも ローカルで開発スピードが落ちる場合はサーバで

7

話題

Q:入った会社に自動テストが無い。 理由が「テスト自体の品質を誰が担保するか」 A:

実際に放置されたテストが存在して、動くかどうか分からないケースもある。

テストを書くスキルも地道に育てていく必要があって、止めてしまうといつまでも人手でやる所から進めない。 OSのバージョンアップとか長期的な運用で効果が出てくるところをアピールしていく。

8

話題 Q:入った会社に自動テストが無い。 理由が「テスト自体の品質を誰が担保するか」 A: テスト技法にも実際に役に立つか疑問の声が出る。 が、同値分割と境界値分析くらいはやっておくべき。

最低限の部分を実際にやると、本番での障害を防げる実績が出る。

起こった障害を全部あらって、それをどこで防ぐかを決める→自動テストで担保すべき部分が分かる。

実際に起こっているものからお金に換算して出すのが効果的。

9

話題 Q:

自動テストを書いても仕様変更で自動テストを書き直す必要が出てくる。 A: TDDをやっている場合は、仕様変更に合わせてテストを先に直す。

テストが失敗するので、そのタイミングで直すが現実的かも。

開発スピードが速い場合、手でテストして、リリースを先にやってしまう時も。ある閾値を超えた時に集中して直す。ゲーミフィケーション的に導入すると効果的。

10

話題 Q: 自動テストへの適正の白黒を見つける方法。 A: 実際に導入してみて、見積もりとその結果で判明。 もっと事前に調べておいた方が良かった。

当てずっぽうの見積もりでプレッシャーになったり問題はあった。 現状を把握する時間を設けるのが良い。

11

明日からやってほしいこと

岡崎さん 自分達の能力以上の事をやろうとせずに、 地道に少しずつ進めていってください。

「イノベーション」という魔法の言葉に振り回されず、「工夫」を積み重ねていってください。

12

明日からやってほしいこと

太田さん できる事からやるしかない。 あきらめるのは大事。 自分自身が難しいと思う事は他のメンバーも難しい 最初から欲張らない。 大した事じゃなくても劇的に効果がでる部分もある