テスト自動化は"目的"ではない
ソフトウェアテストの専門会社として20年以上の歴史を持つバルテス・ホールディングス。月額4,840円（税込）〜利用できるテスト自動化ツール「T-DASH」の提供をはじめ、要件定義〜テスト実行までの全行程において、ソフトウェアの品質管理を支援している。
「テスト自動化、苦しかったときの話をしようか」と題した本セッションでは、江村氏が過去にテスト自動化で苦労した3つのシーンをもとに話が進められた。
まずは「テスト自動化が目的だったときの話」である。
これは、江村氏がテスト自動化に出会った10年以上前のこと。当時、あるサービスのエンジニアリーダーを務めていた江村氏は、上長からテスト自動化の指示を受け、あるスーパーRubyエンジニアに託したという。
そのエンジニアは、Ruby・Selenium・Cucumber・Capybaraを用いて、キーワード駆動のテスト自動化を構築した。それは、テストデータさえ準備すれば完璧に動くものだった。しかし、最終的にはエンジニアの異動により、封印される運命を辿った。
このとき、何が課題だったのか。江村氏は次の2つを挙げた。
課題1：いつでも繰り返し実行できない
テストに必要な事前のテストデータを手で作る必要があり、これがとても大変だった。また、テストが失敗したときのリカバリーも大変だった。たとえば、お気に入り登録後にテストが失敗したら、登録を解除するというリカバリー作業が発生していた。要するに、テスト自動化のために大きな工数がかかってしまい、テスト実行をいつでも繰り返すことが困難だったのだ。
課題2：テスト自動化の運用ができなかった
テスト自動化には、「テストが失敗したときの原因調査」や「仕様変更に伴うスクリプトの修正」「テスト環境のデータやスクリプトの保守」といった運用が発生する。手動テストの場合、途中で動かなくなったら気づくが、自動化すると結果しかわからない。なぜ失敗したのか、その原因調査は手動テストよりも工数がかかってしまっていた。また、当時Rubyエンジニアが少なく、当該エンジニアしかライブラリのスクリプト修正ができなかった。
さらに、スクリプトを修正した後にテスト環境にデプロイするといった仕組みがなく、テスト環境を維持するための運用工数が余計にかかってしまった。そもそも運用工数が発生すること自体、想定していなかったのである。
これらの課題を解消すべく、江村氏は自動化の目的を「毎日リグレッションテストする」と定め、その目的を達成するためのツールを選定・実装した。加えて、運用に必要な作業内容を洗い出し、工数の確保に努めたという。
