いかにしてテスト文化を醸成させたか.pdf

Transcript

1. いかにしてテスト文化を醸成させたか 〜SPEEDA事業におけるテストの話〜

2. 自己紹介 • 林 尚之（はやし たかゆき） @t_hyssh • 株式会社ユーザベース ◦ SPEEDA事業

   CTO • Agile（XP）、ペアプロ、TDD、DDD • 最近使ってる言語はDart、Kotlin、OCaml等

3. 現在に至るまでの流れ

4. 黎明期 2013年〜

5. 黎明期 〜当時の状況〜 ビジネスをより加速させる上で開発生産 性を上げたいと思っている開発責任者 手動テストに疲弊して現状をなんとかしたいと 思っているQAメンバー 出典：いらすとや

6. 黎明期 〜当時の状況〜 林さん、なにか 案ありません か？ アジャイルやりましょ う！（ニヤリ） 出典：いらすとや 注）一応この時点でアジャイル開発 の経験は5年ほどありました。

7. 黎明期 〜結果〜 • E2Eはアジャイル（XP）という文脈で始めた • 意欲のあるメンバーを集めて小さなチームで実施 ◦ 新機能の部分のみE2Eを書き始める • 結果は好評

   ◦ ただし、好評だったがゆえに次の停滞期を迎えることに・・・・

8. 停滞期 2015年〜

9. 停滞期 〜当時の状況〜 そうだ！E2Eとして自動化さ れてない部分（過去に作った 機能）は全部オフショアに出し ましょう！ う〜ん、大丈夫だろうか・・・・ 出典：いらすとや

10. 停滞期 〜結果〜 • 納品されたのはまともに動かないテストコード ◦ 動かすためにかなりのコストを掛ける事に・・・ ◦ この時の不安定なテストには今でも悩まされる事に • そもそもオフショアで正しく成果を出すための準備がこちら側に出来ていなかった

    ◦ 単に単価が低いからという理由で出してしまったオフショアのアンチパターン

11. 成長期 2017年〜現在

12. 成長期 Gaugeと出会う（ドキュメントとしての表現力がとても良い）

13. 成長期 〜現在〜 • マイクロフロントエンドで新規開発する部分は全てGaugeでE2Eを記述 ◦ ドキュメントとしての表現能力の大幅向上 ◦ モノリシックの部分（オフショアに出した部分も含め）は最低限の保守のみ • Docker、k8sを活用し、再現性を高める

    • デプロイメントパイプラインの整備 • 並列実行によるテスト時間の短縮 • コンシューマー駆動契約テストの取り組み（やりたい）

14. 重視している事（3つ）

15. 1. 成果（信頼）

16. 2. 実感

17. 3. 実践

18. 成果（信頼） • 必ず成果を出す ◦ 成果とは「ある事をして得られた良い結果」 ◦ 特にビジネスサイドの人からもわかりやすい成果を出す ▪ 例：バグが少ない、手動テスト時間やリリースサイクルの短縮等 ◦

    成果を出すためにも 小さく、細かく始める ▪ 可能であればスパイクを打つ • 成果を出すことによって信頼を得る ◦ 信頼を得られればより広い範囲で E2Eを適用出来るはず ◦ SeleniumとかGaugeがどうこうとかより重要な事 ▪ 自分（達）が今持っているスキルを最大限活かす ▪ 最初のタイミングでチャレンジしすぎると失敗する可能性が高まる

19. 実感 • E2Eに直接関わる人に良さを実感してもらう ◦ ソフトウェアエンジニア、テストエンジニア等 ◦ E2Eを書く人自身が「書いた方が良い」と思える状態にしなければ上手く行かない • Greenを保つ ◦

    難易度は高いがこれが実現出来なければ E2Eが形骸化してしまう • 頻繁に実行する ◦ デグレの早期発見 • リファクタリングをする ◦ ここでのリファクタリングはテストのソースコードではなく、テスト対象のソースコード ▪ 「Green維持すればいくらでもリファクタリング出来るね！」というのを実感してもらう

20. 実践 • 何よりも自分自身が第一の実践者となる

21. まとめ

22. 同じ志や課題感を持つ人を集め、少しずつ確実に成 果を出して実感、信頼を得られるように進める 「それができれば苦労はしないよ！」という声が聞こえてき そうです・・・・。でも、やっぱり「銀の弾丸」も無いのも事 実。。。

23. ご清聴ありがとうございました。