【増席】ソフトウェアテスト・QA勉強会【（仮）テスト自動化の光と闇（1年間の苦労話）】での発表資料 https://d-cube.connpass.com/event/149831/

1. テスト自動化の光と闇

2. ● はじめに
● 昔話
● QAになって自動化
● 再始動
● 現在
もくじ

3. はじめに

4. みんな
このタイミングで自己
紹介するっぽいので
名前: 澤口 勲
所属: 株式会社ビズリーチ
経歴: ずっとPHPとJavaで開発してて
1年くらい前にQAはじめました。
あんまりテストについて勉強してこなかった系
エンジニアです

5. 今日話す内容のあらすじ
E2Eテスト自動化について、何も知らずにやってみて砕け散った数年前の話を添えながら。
QAにコンバートした1年前、自動化メンバーになり指示されるままに自動化をすすめるも
完成が見えたところでリーダーがいなくなり、立ちはだかる壁、不穏な空気、漂う不安。
そんな中、方向転換を決意し、ちゃぶ台を返す我々に未来はあるのか！？
● 今日話すこと：
○ 弊社における、E2Eテスト自動化の歴史(主に失敗話)と反省
● 今日話さいないこと：
○ 詳細なシステム構成、開発方法、アーキテクチャなどの技術的な話

6. 昔話

7. はじめての自動化(多分よくあるケース)
数年前のある日。当時の開発部門の課題は生産性向上。上長にMTGを入れられ
「生産性を上げるために、リリース前のシナリオテスト自動化したいんだよね」
「自動化ですか・・・」
「毎回10人以上で１日かけてやるの、時間もったいないよね。
テストケース自体は、既に長期運用してるやつがあるから大丈夫でしょ」
「うーん。確かに。」

8. はじめての自動化(多分よくあるケース)
「とりあえず3ヶ月である程度成果出してね！頑張れ！」
「自動化終わったら開発戻っていいからね」
「がんばりまーす」

9. はじめての自動化(多分よくあるケース)
「開発環境は用意してもらったし、Seleniumのラッパーライブラリも入れてもらった。」
「なんかページオブジェクトパターンってのがあるらしい」
「どういう単位でページオブジェクトのメソッド切ったら良いのかなぁ・・・」
「沢山あるシナリオの中から、ビジネスリスクの高いシナリオに絞った。
でも、一つのシナリオ長すぎて、実行動作が不安定すぎる・・・」
「独り 辛い」

10. はじめての自動化(多分よくあるケース)
周囲の期待と妄想
「やった！そのうちテストしなくてよくなる！」
「これで自動的にガンガン不具合見つかる！」
「将来的にはGoogleみたいに全自動だよね〜」
「自動化しちゃえば、あとは放置で大丈夫っしょ。
変更が入ったところだけ、変更した人が直せば大丈夫☆」

11. 無事死亡😇

12. 結果
成果って何？いつになったら終わるの？
→ 成果を明確化しなかった！
リトライに時間がかかる。原因分析に時間がかかる。
→ シナリオが長すぎ！
運用開始後は、保守と原因分析に忙しくて、新規シナリオなんて作れない。
→ 現状維持で精一杯！
はじめての自動化(多分よくあるケース)

13. 結果
テストが壊れてもみんな無関心。
→ 不安定すぎて、リリース条件に組み込めなかった。
通らなくてもリリースできるし、自分の仕事が阻害されない。
故に実行レポートなんて見る必要もない
自動化したのに、同じテストを手動でもやってる。
→ 不安定すぎて、手でやったほうが早いことが多い。
はじめての自動化(多分よくあるケース)

14. はじめての自動化(多分よくあるケース)
開始から半年後
「まだ自動化やってるの？」
「はい・・・。運用開始まではこぎつけたのですが、運用が大変で」
「メンテナンスで人張るのもったいないし、コストも減らせてないし
バグも出ないから中止ね〜」
「まじっすか」

15. はじめての自動化(多分よくあるケース)
まとめ
最初に合意すべき事を合意しなかった。
成果・目的を明確化しなかった。
テストケースの見直しを行わなかった。
テスト自動化に夢を見すぎ。
運用コスト甘く見すぎ！
(自動化コスト10のうち、開発:3 運用:7と言われるが
みんな開発:8 運用:2くらいの感覚だった)

16. QAになって自
動化

17. 異動
開発者として担当していたプロダクトにはQAの組織はなく、当時リリースするたびに緊急対応が必要
な不具合が毎回発生していた。
みんな改善したいが、どうすればいいのかわからない状態。社内にも知見のある人がいない。
そんなときQAの人が入社し、その人を中心に全社横断のQA組織が立ち上がるという話を聞いた私
は、品質を管理し、向上させる技術を知りたくてQA組織にジョインするべく手を上げた。

18. 異動してみたら自動化やってるぞ
異動するにあたって、QAの状況や自分が何をやるのか話し合うと
現在、採用管理プロダクトを中心にQA活動を行っている。すでに動いているチームが2つあり、以下の
通り。
・テスト設計〜テスト実施するチーム
・各画面の動作確認を行うテストの自動化を行うチーム
もともと開発者ということもあり、自動化チームを軸足にテストを学ぶことに。
「以前失敗した自動化のリベンジができるぞ！！」

19. 自動化するぞ
テスト自動化チームに入り、なぜテストを自動化の目的を教えてもらう。
現在のシナリオテストの課題である、機能網羅を強化するべくシナリオテストを補強する形でテストを
設計し自動化している とのこと。
「QAに詳しい人がやってるから大丈夫」というダメな思考回路で、それで誰がどういうふうに幸せになる
かを気にしなかった。
当時のリーダーの頭の中では緻密なバランスで設計されていたが、当時の自分には理解しきれなかっ
た。また、設計やテスト計画の資料などもなかったが
「完成するまでにキャッチアップすればいいし
資料もそのうちかいてもらおう〜っと。」

20. ちょっとまて
QA組織に来てくれた、界隈の有名らしい人に心配される
「自動化プロジェクト大丈夫？ちょっと危ないんじゃない？」
「？？？ ありがとうございます。ぜんぜん大丈夫っす！進捗進んでますし」
「・・・・・なんかあったら相談してねー」
「何を心配してるのかはよくわからないけど、いい人だなぁ」

21. 突然の転落
急遽リーダーが退職。
一応区切りのいいところまでは終わっているけど、これメンテナンスできない！
開発チームにヒアリングしてみたら
「最終的には、今週１でやってるシナリオテストなくなるんですよね！
期待してます！」
「いや無理ｗｗｗｗｗ
今の段階じゃ、まだ代替はできないよー。」

22. あなたが神か
天上から見守っていた神が降臨する
「ちゃんと理解してないっぽかったから心配してたんだよね」
「ずびばぜん・・・」
「いいかい。そもそも自動テストというのはだね・・・(神の言葉が続く)。
とりあえず勉強できる場所はたくさんあるから行ってみたら。」
「ありがとうございます(感涙)」

23. 勉強するぞ
などなど、参加したり読んでみたり。

24. ソフトウェアテストの7原則を学び
テスト自動化の8原則を学び
テストピラミッドを学び
テストは目的・狙いを定めることが重要だと学び
自動化することが目的になっていて、どういう状態にしたいのか
何が課題なのか、だれがどのように喜ぶかが抜けていたことを思い知る。
「もう一度、自動化の目的・ゴール設定から始めよう。」
色々知った

25. 再始動

26. 仕切り直し
開発チームに、リリース前に行っているシナリオテストに感じることを聞いてみると
「毎週リリースだから、同じ手順の10人くらいが半日かかるテストを毎週毎週毎週毎週毎週やるのが
精神的につらい。修行のようだ。
念の為やっておいたほうが良いことはわかるけど
バグが出るわけでもないし意義を感じない。」

27. テストの目的を決める
そもそもなんのためにやっているのかを誰も説明できない状態だった。
そこでプロダクトの部長やマネージャと話して目的を
「プロダクトがお客様に提供する、最低限の価値を担保する」として
目指す姿を「お客様の日常の業務が止まらないこと」とした。

28. ユーザーシナリオを決める
プロダクトの提供する価値、お客様の日常の業務とは何かを定義する。
カスタマーサポートをはじめビジネスサイドの人に話を聞いたり
プロダクトのディレクションをしている人に話を聞いたりして
お客様がどんな業務をしていて
それは大まかにどのあたりの機能なのかを調べた。
餅は餅屋。
アクセス数を見てデータによる裏付けも行った。

29. やることの許可を得る
今までやってきたものは残しつつも、仕切り直してシナリオテストから作り直すプロジェクトをテスト計画
書として書いて部長にプレゼンする。
どういう世界を実現したいのか、だれがどういうふうに幸せになるのか。
どのくらいの期間かかるのか
想定でどのくらいのコスト削減になって、どのくらいの期間でペイできるのか。
あたりを明確にするのが大事だった。ROIの計算はかなりザックリだったけど。

30. テスト設計〜テスト実装
ユーザーシナリオに沿って、画面と機能を洗い出しテストケースに落とし込んだ。
実際に今の自動テスト環境で実現できるものとできないものを切り分け。
スケジュールを立てる。この時点で、合意を得た工数と乖離したのでもう一度部長に説明。
画面や機能を軸にシナリオごとに担当を決め
実装を行った。
「チーム、幸せ」

31. 運用ルール
● いつ、誰が実行するのか。
● 失敗した場合は誰が調査し、誰が修正するのか。
● 修正が時間内に終わらなそうな場合は誰が手動でテストするのか。
● テストが失敗した場合、リリースをどうするか。
などを決める。
仕切り直しから半年でなんとか運用を開始することが出来た。
運用ルールを決める

32. 現在

33. みんなしあわせになった(光)
● 10人程度で半日かけていたテストは3人で2時間に。
● 毎週テストして疲弊していた人も月に1回くらいやればいい(短いテストもある)。
● テストの目的がはっきりし偉い人と合意したので、テストケース追加も慎重にできるようになっ
た。
● 毎日テスト実行しているので、テスト環境で不具合が出るとすぐにわかるように。

34. さいごに
大事なこと
・なぜやりたいのか、だれがどのように幸せになるのかが大事。
・何を確認したいのか、何をテストしたいのか。目的が大事。
→ 途中で自動化することが目的になりがち
・勉強大事。コミュニティ大事。
・いつまでもいると思うな親とリーダー。
・仲間がいると幸せだなあ。
増えた仕事
・テスト結果確認(毎日)
・テスト失敗時のエラー原因調査＆修正
→ 環境の問題、テスト側のバグ、仕様が変わった、プロダクト側のバグなど
(問題の切り分け/調査は結構時間がかかる)
・開発環境が動かなくなって調査(だいたいWebDriverバージョンアップ時)