実際にテスト自動化をしていて感じたこと

さっきTwitterを書いてたら、最近、自分がのめり込んでやっている、自動化の取り組みについて書きたくなったので、今自分が書けることを一気にかいてみます。結構とりとめなく書きます。

最近、ある税金の計算システムの税率改定に対する税率計算のテストを自動化することになって、スクリプト書いています。

私は、現時点では、テスト専門部署のマネージャーをしてますが、前述した計算システムのシステムテストのテストアナリストの方から「何としてもこういうことを自動化したいのですが、なんとかなりませんか？」と相談を受けて、確かにこれは自動化するとメリットが絶対あるよなーと思ったのと、うちの部署のメンバーに、ちゃんと実務でテスト自動化を進めていく実体験をさせる良い機会だとも思い、「私たちに任せてください」的なことを言って、引き受けることにしました。

自動化できるようにするまでの進め方は、以下のような流れで行いました。
１、システムの説明とどのようなテストをやるか説明を1時間くらい受けて、
２、サンプルのデータを500件ほどもらい、
３、その500件が全て動くようにスクリプトを作る。
４、いろいろなルールをきめて、その合意をして、
５、本番！

ドメインのことをあまり話せないのですが、税率の計算には何種類ものカテゴリがあり、そのカテゴリごとの税金計算までのいろいろな条件を画面から入れていくことを自動化するのですが、長いものは約60個のパラメータをチェックボックスやリストや入力フィールドなどのパターンで何画面にもわたって入れて行きます。画面遷移も条件で結構変わりますし、その組み合わせで金額が決まります。システムから出てきた金額が、もらったサンプルデータに書かれている金額と一致していればテストは成功、計算時点で条件に不備があると不備があるメッセージがでます。

自動テスト的にはどっちだとしても計算ボタンを押すところまでたどり着けばOKで、不備だとしてもそのメッセージをキャプチャできれば良いという感じです。

今回、スクリプトをうちの部署が書いて、実際にそのスクリプトは、プロジェクトに入ってシステムテストをする技術者の方々に実行してもらっています。なので、システムテストにジョインしている人たちにテスト用データの差し替え、追加をどうやってもらうかとか、実行した時のエラーはどういう順番で切り分けしていくかとか、ルールをきめてやってます。

スクリプトもあらゆるパターンに完全対応するスクリプトを最初から作るのは無理なので、一旦は500パターンのテストデータに対応するものを作った後、テストしている時に出てくるこれまでとは別のパターンでスクリプトが動かなくなったら修正するって方式ですすめることにしました。

まぁ、ちなみに私はそれに関するドメイン知識は全くありません。スクリプト作成能力とテスト設計能力だけで勝負みたいな。ドメイン知識は、スクリプト書けばそれなりにわかってきて、「なんかよく理解してますね」とか言われる程度で十分です（笑）。テスト設計能力は何の役にたつのか？というとデータパターンの持たせ方をどうするか考える際に、どうバリエーションを持たせればいいか決めるのに役立っていると思います。

本当は、これを機会に自分の部署にスクリプト作成能力つけてもらうのが目的だったんだけど、メインでやってもらうつもりだった自分の部署のインド人が家庭の都合でインドに戻ってしまい、人を雇うお金もないので、私がスクリプトを書く実働メンバーの一員になるはめになってしまったという感じです。

ツールはUFT（言わばQTPです。もっというとWinRunner！）を使っていて、私はUFTが大好きだからいいのですが、世間的にはUFTはあまり興味がないと思うので、UFTでスクリプトを作るテクニックについては今は触れません。しかし、まぁ自分で、なんて言うか、サンプルではなく、本当に使うスクリプトをがっつり書いたりするのは20年ぶりぐらいだと思うので、いろいろ思い出しながら、わからないときは調べながら、かつ知らなかった便利機能に感激しながらやってました。

あとは、オブジェクトリポジトリの保守性確保の方法とか！これはこれで、今回とてもうまく行ったと勝手に思っていることの一つで、私含めて自分の部署の４人で助け合いながら同じスクリプトを成長させるように書いてますが、うまくやり切れているのはオブジェクトリポジトリをうまく作ったことの一点につきると私は思っています。これは機会があればどこかで話できればと。

オブジェクトリポジトリとは、UFTの用語ですが、簡単に言うと、画面とか入力フィールドとかラジオボタンとか画面のパーツになるものをライブラリとして一つ作って複数のスクリプトで共有するための仕組みのことです。Seleniumなど他の自動テストツールを使うにしても、こういうライブラリを準備するという考え方は不変だと思います。

今は実際にシステムテストが始まってまだ２週間目ですが、ここ数日は毎日300件のデータパターンを自動実行をしてもらっています。今はまだ出力結果が期待通りではない時にその原因の調査をしたりしているので、これくらいでないと仕事が回りません。ただ、手動では１つのデータパターンを入力して計算結果を正確に入力して確認するのに20分〜40分かかるのが自動だと4分で実行できますので、その入力作業だけ考えてもメリットありと話している技術者の人もいます。それでも「自動なのに4分もかかるの？優秀な人なら手でできちゃうよ！」という人も多くいますが、システムのつくり上、猛スピードで入力すると、Ajaxで入力値を非同期に取ってくるフィールドの入力値が上書きされてしまったり、システムが予期せぬエラーを出したりします。ネットワークの状況やDB検索によって、ボタンを押して返答が来るまでばらつきがあり、ひどいと1分程度かかる場合もあり、なのでチューニングした最適な時間が4分です。それでも、今回準備した今のテスト環境であれば、全て状況が整えば、1日1,000件くらいのパターンを実行できるように運用をデザインしていますので、まだまだこれからです。

だらだらと書きましたが、テストの自動化を進めるための大事なこととして、自ら当事者としてがっつり入って改めて気づいたことは以下のとおりです。

自動化で確認することは１点に絞る
今回はズバリ金額計算結果の確認のみです。なので、１データパターンを実行してそこでのテストケースは実質一つで、金額が正しいかどうか？だけです。

テストケースとスクリプトは紐づける
めっちゃ当たり前ですが、真剣に、ちゃんと、しかも最初にやっておかないといけないことがこれです。どのテストケースを自動で実行しているのか？がわかるために必要です。今回は「自動化で確認することは１点に絞る」ことにより、テストケースとスクリプトの紐付けを可能にして、「テスト結果の集計に時間をかけない」につなげました。

スクリプトができて、実行してもらうようになった後の運用ルールをちゃんとみんなで考える
これも当たり前ですが。。。最初から完璧に全てのことをできないので、実行した後のエラーの対処をルール化してます。具体的には、同時に１０台のマシンで自動実行できるようにしている状態でスクリプトの修正が必要になった時の修正内容の展開方法やバージョンの管理方法です。実際にシステムのバグのケースもあるので、システムが回収された後の再テスト用に再テスト時に流すデータだけをまとめて別のスクリプトとして保存しておくときのスクリプトの命名規則やバグ管理ツールとのトレース方法などもルールにしています。

デイリーミーティングをする
スクリプトを作る人とテストデータを作る人と自動スクリプトを実行する人が違うので、課題を持ち寄るための毎日30分ミーティングをしています。ずっとやる必要はないかもしれないけど、最初は絶対必要ですね。

テスト結果の集計に時間をかけない。
私たちはUFTとALMという高価だけどめっちゃ便利なツールをラッキーにも持っているので、これらを組み合わせで、テストの進捗をリアルタイムに可視化しています。実行していない人たちもみんなテストの結果や失敗具合も含めてリアルタイムに見れます。実施予定テストケース数に対して、実行は何件、Passedは何件は、リアルタイムに全部見れます。

自分たちの身の丈にあった自動化にする
けど、結局DevOpsやCI／CDに比べたら全然なわけです。まぁ、私たちの技術力や準備の不足から、本当に夜中に流し続けることがあまり上手く出来てないとかありますが、けど、それでもよいのでできることを始めて、本当に手でやるよりは多くの（本来はやりたいテストが）できることが大事です。

まだまだこれからですが
まだ、本当にテストしなきゃいけない全部のパターンをカバーできるようなスクリプトにもなってないので、対応は当分続きそうとかありますが、３、４ヶ月後にこの自動化がどこまで効果を発揮したかがわかるので、またどこかで続きを書ければ書きます。以上、現場からでした。