テスト自動化失敗談を共有しよう！ by T-DASH Advent Calendar 2022の４日目の記事です。
## はじめに
今回の記事は、僕が新卒1年目に初めて開発プロジェクトに参画した時の話です。
今思うと何を考えて開発していたのか…という感じですが、供養したいと思います。
そもそもテストの自動化関係なく開発プロセスとしての失敗も含まれてますがそれも含めてお楽しみください。
前提となる状況
案件
モバイルアプリのテスト自動化案件
人間がやっているテストケースが既にあり、それを自動化するというプロジェクトでした
モバイルアプリはiOS・Android対応のため、両方で動くテストを作るのが目標でした。
開発メンバー
プログラマー: 自分1人
PMっぽい感じに動く人: 上司1人
（最後の方にテストコード書く人員として2人追加された)
選定言語・フレームワーク
- javascript
- Appium
- webdriverio
失敗
失敗① そもそも対象のアプリケーションの事を何も知らないまま開発を進めた
私は外注としてテスト自動化のために参画したので、モバイルアプリの事を何も知りませんでした。
また、テストケースもエクセルを読むだけだったので、テストケースの意図やアプリの動きがふわっとした理解のままテストの自動化を始めてしまいました。
結果として納品後に、テストを動かしたもののうまく動かないというお叱りをうけました。
これは今思えばもっと情報を集めることに時間をさくべきだったと思います。
テスターの人にあってみるとか、テスト自動化の作成中に他の人にテストの動きを見てもらうとかして、本当に方針があっているかの確認をするとかでもっと良いテストがかけたと思います。
失敗② 環境構築が難しすぎる
もう詳細は覚えていませんが、環境構築が難しすぎて他の人が後から参画してきた時に困ったのを覚えています。
Appiumを使用していたのですが、iOSアプリを操作するためのドライバーを組み込んでアプリをビルドすると、Appiumがうまく起動しない事象が多発しておりました。
これはそもそもテスト自動化プロジェクト側でどうにかする問題ではなかったなと思っています。
私が対象のモバイルアプリのソースコードを一部いじった状態でビルドしてましたが、そもそも今後テストを自動で実行するなら余計な手順は省くべきなので、アプリ開発チームと連携してやればよかったと思います。
（まぁ外注なのでそこまで細かく要望を通せたかと言われると微妙ですが）
失敗③言語・フレームワークの選定が適当
特に言語・フレームワークに関して指定がなかったので、私が調べて上司と相談して決めた記憶があります。
私としては拙い知識とGoogleを活用してなんとか調べましたつもりでしたが…。
そもそもエンジニア歴1年かつ、テスト自動化について何も知らない人間が選定したのは無理がありましたね…。
あとからwebdriverio特有の問題にぶち当たったりとか、javascript故に型情報がなく変な振る舞いをしたりと散々でした。
経験が豊富な他のエンジニアに相談するべきだっだと思います。
失敗④テストがアプリの変更に追従できない
テストを前提にアプリケーションが開発されていないので、xpathのid(だったかな？)ではなくフルパスを取得してテストを実行する形になっていました。
これは本当にテスト自体の保守性を下げるもので、UIの変更が少しでもあるとテストが失敗するので、保守が大変だったと思います。
テスト自動化の開発チームとアプリ開発チームでわかれていなければ、まだ良いと思うのですが…。（変更に追従しやすいため）
これもアプリ開発チームと連携して、テストの自動化用に各要素にidを埋め込んでもらえばよかったと思います。
最後に
このテスト自動化プロジェクト、今も動いているのだろうかと思うことがあります。
結局使えない、と判断されて廃棄されてそうな気もします…。