Cybozu Meetup : テスト自動化 https://cybozu.connpass.com/event/83960/ テストをとりあえず自動化してみたけど、継続的に運用ができなかった。 そんな失敗を分析し、テスト自動化をどのように推進しているかを紹介いたします。

1. 失敗に学ぶ
テスト自動化導入で大切なこと
2018-April
サイボウズ株式会社
園 進

2. 性能脆弱性テスト実装設計
単体試験
結合試験
ユニットテスト
受入試験(acceptance test)
機能試験(functional test)
回帰試験(regression test)
構成試験(configuration test)
設置試験(installation test)
移行試験(migration test)
脆弱性検証 性能検証
… プロジェクトマネージャー (PM)
… プログラマ (PG)
… テスター (QA)
… テストエンジニア (TE)

3. テストは自動化してたけど…
失敗談

4. 複数のプロダクトがテストを自動化していたが… 3 years ago…
テスト自動化をうまく運用しているプロダクトもあるが、
自動化したテストが使われていないプロダクトも存在した
なんだ、あるのか
いや…実は…
動かなくなって、使ってないんだよね
テスト自動化やってる？
一応やってるよTE
TE
QA
QA

5. 「なぜ使わないの？」 と聞いてみると…
いやぁ、PGに依頼してるんですが…
プログラムはよくわからないので…
3 years ago…
異動になったわ
ﾖﾛ |ω・)ﾉｼ エッ (・д・川
製品優先！
自動化は後回し！
仕様変更！
リリース期限！
えー
誰かが何とかしてくれる
メンテナンスされないから使わない
やる気がなくなる

6. テスト設計
テスト自動化
コーディング
テストを自動化するための コーディング が負担の要因
ココ
誰かが何とかしてくれる
メンテナンスされないから使わない
やる気がなくなる
負担集中
モチベーション低下
「なぜ使わないの？」

7. コーディングの負担集中
テスト設計
テスト自動化
コーディング
・QAはテストをする人、技術的なことやプログラムはPGの仕事
・知識があるPGがプログラムしたほうが早いよね
・自動化するといいらしいから自動化してみよう
・とりあえず今の状況が解決できればいいや
・自動化で使うのは、プロダクトで慣れ親しんだ言語
→誰か(PG)に頼ることによる負担の集中
→プロダクト外からサポートが得られない
→モチベーションの維持ができない
職能障壁
局所的
衝動的
負担集中
モチベーション低下
負担の集中をなくして、モチベーション低下を避ける

8. モチベーションの創造と維持
どのくらいコストがかかるの？
メリットがあるの？
継続して利用できるの？
やり方変わって混乱しそう
どうせ使えなくなるんでしょ?
導入コスト高そうだな…
本当にメリットあるの？
不安を払拭して、導入への動機付けができるかが課題

9. 継続できているところは何が違うの？
失敗に学ぼう

10. テストを自動化する体制はどこのプロダクトも同じ・・・？
テスト設計
テスト自動化
コーディング
・テストを設計する人
・自動化するテストを選ぶ人QA
PG
・選ばれたテストを自動化する人

11. 継続利用しているプロダクトの特徴
コーディング
・自動化するテスト候補を選択
→コーディングにかかる負担を調整
・候補から自動化するテストを決定
・実装と合わせ自動テストをコーディング
→自動化するテストを限定 負担を調整して
計画的に実施
→自動化予定のテストを動かす責任
QA
PG
リリースプロセスに
組み入れている
テスト設計
テスト自動化

12. 継続利用しているプロダクトのプロセス
テスト実装設計
自動テスト実装
テスト設計
仕様検討 アーカイブ作成
受入CI
実装されなかった受入テスト
要望
OK 却下
回帰試験
実装
動かなければテストを含め修正
技術面・工数面を考慮して
自動テスト実装の可/不可を決定
QAは「要望」を出す
実装とテスト実装を同時に実施
受入れCIが通らないとテストに進まない
QA
PG

13. 導入するときのポイント
【 まとめ 】

14. 導入するときのポイント
理想の確認
負担の軽減・分散
不安の払拭
理想的な状態と、解決しなければいけない問題を確認
負担を軽減・分散する仕組みづくり
不安を取り除く施策で安心感を与える
モチベーションを高める いかに「やる気」になってもらうか
組織を巻き込む 組織に協力してもらえる体制づくり
動機付け テストの自動化は「自分たちの手で行う」という意識づくり
プロセスへの組み込みは効果が高い 「やらなければならない状況」 は継続利用につながる

15. 自動化コーディングの負荷を抑えよう
TEがやったこと

16. コーディングの負荷を抑える手法は様々
コーディングをなくす
人を増やす
できる人を増やす
・非プログラミングによる自動テスト
・自動化コーディングができる人を増やす
→ Selenium IDEなどのツールでプログラミングせずに自動テスト
・専門部隊がコーディングする
→ 専門部隊に依頼すればコーディングしなくてよい
→ 習得した人が増えれば、その分コストが分散していく
専門部隊を作る
コーディング
負担軽減
・
負担分散

17. 理想的な状態にするための最適な手段は？
いつでも
多くのテスト
負担がない
修正・追加
・多くのテストが自動化されている
・いつでも実行できる
・修正や追加が思い通りにできる
・負担が集中しない
PG QA
QA自身がテストを自動化できれば
理想の状態に近づける？
テストを実行するQAの要望が多い
ツールを使いコーディングをなくす
QAもコーディングできるようになる
コーディング専門部隊を作る

18. 理想的な状態にするための最適な手段は？
ツールを使いコーディングをなくす
QAもコーディングできるようになる
・即効性があり、導入コストも比較的低い
・ツールが対応していないテストは自動化できない
・汎用性・再利用性・メンテナンス性に不安あり？
・効果が出るまで多くの時間とコストがかかる
・QAが希望するテストを自分たちで自動化できる
・個人/QA全体のスキルアップにつながる ・プロダクト内で問題解決
・技術系QAへのキャリアパス
・QAメンバーのスキル底上げ
品質保証部の思惑

19. TEST Tool
Test Tool
Test tool
CGI
PHP
Java
テストツールの共通化
CGI
PHP
Java
Public
TestTool
Java
Script
Public
TestToolPublic
TestTool
Public
TestTool
プロダクト単位で自動化手法が異なる状態は教育・学習コストが高い
➡ 共通のツールを作りましょう
共通のテストツール独自のテストツール
Java
Script
Java
Script

20. テスト共通基盤 (Test Common Base) を作りました
Page Object
Test Flow
Test Script
Data
・どのプロダクトでも使える
・構造化されたスクリプトでわかりやすい
・JavaScriptベースで作成された
製品を作成している言語にかかわらずどのプロダクトでも使用可能
QA内では少ないながらも馴染みがある言語。
ある程度使える人もおり、習得も(比較的)容易？
スクリプトを構造化して、可能な限り汎用性を持たせ、理解しやすく
Test Code
・汎用的なツール
ブラウザテストだけではなく、APIテストなども実施できるツール
メジャーなモジュールを組み合わせたツール

21. 導入へのモチベーションを高めよう
TEがやったことのご紹介

22. プログラムの作り方を含めたコーディングの方法を教育する。
モブプログラミング手法を取り入れると効果が高い。
導入教育
プログラムって難しそうだけど・・・？
QATE
➡ TEと一緒に作りましょう
コーディングへの不安解消 -1
スクリプトが作れるようになるまで、学習支援する
QATE

23. 学習した内容を、即ブラウザ上にコードを書いて試せる仕組み
環境を作るのが難しそう。環境を作るのに躓いてしまった。
コーディングへの不安解消 -2
環境設定等を省き、気になったらすぐに取り掛かれる仕組み
➡ 学習時に、すぐに試せる仕組みも作りましょう

24. プロトタイプ作成
実際のテストを、テスト自動化フレームワークを使用して自動化します。
sample
どんなものなの？便利になるの？
QATE
➡ プロトタイプを作成します
ツールへの不安解消 -1
使っているテストケースで体験できる状態を作る

25. Cybozu Device Farm
Test Common Base
ブラウザ テスト モバイル テスト
REST API テスト
このツールを使うメリットってあるの？
➡ ブラウザテストだけではなく、様々なテストに流用できるように機能を拡張します
ツールへの不安解消 -2
同じコーティング方法で、様々なテストを実行できる

26. 自動テストへの意識を高める
自動テストってどうなの？どうせまた使えなくなるんじゃない？
➡ 勉強会や、分析結果を共有する会を開催しましょう
・テスト自動化勉強会
・TE Café
『システムテスト自動化 標準ガイド』を使った輪講
既存の自動テストの分析結果の共有
テスト共通基盤(後述)で実現したいことの説明 …etc
意識・知識の向上と、過去躓いたポイントの再確認

27. ヒアリング
プロトタイプ作成
導入教育
運用/メンテナンス
コーディングのやり方
場合によっては、JavaScriptの基礎から教育する
実際の数件のテストケースをTE側で自動化する
この時点で自動化に対する製品特有の問題などを洗い出す
自動化する期間や内容を確認
テスト自体の目的(速度優先か、範囲優先か)なども確認
運用がうまくいっているか定期的に確認
運用中に困ったことがあればいつでも相談・フォローできる体制
プロダクトの活動にどれだけ影響が出るの？
導入プロセスを明確化し導入イメージを持ってもらう
➡ 導入プロセスを明確化しましょう。
プロダクトの不安解消 -1

28. Public
TestTool
導入することで、プロダクトの活動が楽になるの？
プロダクトの抱えるテスト自動化に関する問題に対応する
人員調整
➡ TEから様々なサポートを実施します
Public
TestTool
Public
TestTool
???
導入支援 相談
プロダクトの不安解消 -2
・・・ Busy

29. 現在の状況は？

30. 中小規模・新規プロダクト
中小規模・新規プロダクトを中心に導入
大規模プロダクト
テスト数が少なく、導入に抵抗感がない
既存のテストが自動化されていないことが多く、導入しやすい。
莫大な量のテストを抱えているため、導入に時間がかかる。
独自の自動テストが存在している場合、移行などでコスト面が高くなる傾向。
昨年後半からプレ導入を開始。現在 6 プロダクトで導入中
テスト自動化が機能しているところを無理に変える必要はない

31. 問題を察知し、相談してもらえる活動
やるぞ！
継続した情報収集・発信を行う

32. Q & A

33. Join us !
https://cybozu.co.jp/company/job/recruitment/list/testengineer.html