テスト自動化は"目的"ではない
ソフトウェアテストの専門会社として20年以上の歴史を持つバルテス・ホールディングス。月額4,840円（税込）〜利用できるテスト自動化ツール「T-DASH」の提供をはじめ、要件定義〜テスト実行までの全行程において、ソフトウェアの品質管理を支援している。
「テスト自動化、苦しかったときの話をしようか」と題した本セッションでは、江村氏が過去にテスト自動化で苦労した3つのシーンをもとに話が進められた。
まずは「テスト自動化が目的だったときの話」である。
これは、江村氏がテスト自動化に出会った10年以上前のこと。当時、あるサービスのエンジニアリーダーを務めていた江村氏は、上長からテスト自動化の指示を受け、あるスーパーRubyエンジニアに託したという。
そのエンジニアは、Ruby・Selenium・Cucumber・Capybaraを用いて、キーワード駆動のテスト自動化を構築した。それは、テストデータさえ準備すれば完璧に動くものだった。しかし、最終的にはエンジニアの異動により、封印される運命を辿った。
このとき、何が課題だったのか。江村氏は次の2つを挙げた。
課題1：いつでも繰り返し実行できない
テストに必要な事前のテストデータを手で作る必要があり、これがとても大変だった。また、テストが失敗したときのリカバリーも大変だった。たとえば、お気に入り登録後にテストが失敗したら、登録を解除するというリカバリー作業が発生していた。要するに、テスト自動化のために大きな工数がかかってしまい、テスト実行をいつでも繰り返すことが困難だったのだ。
課題2：テスト自動化の運用ができなかった
テスト自動化には、「テストが失敗したときの原因調査」や「仕様変更に伴うスクリプトの修正」「テスト環境のデータやスクリプトの保守」といった運用が発生する。手動テストの場合、途中で動かなくなったら気づくが、自動化すると結果しかわからない。なぜ失敗したのか、その原因調査は手動テストよりも工数がかかってしまっていた。また、当時Rubyエンジニアが少なく、当該エンジニアしかライブラリのスクリプト修正ができなかった。
さらに、スクリプトを修正した後にテスト環境にデプロイするといった仕組みがなく、テスト環境を維持するための運用工数が余計にかかってしまった。そもそも運用工数が発生すること自体、想定していなかったのである。
これらの課題を解消すべく、江村氏は自動化の目的を「毎日リグレッションテストする」と定め、その目的を達成するためのツールを選定・実装した。加えて、運用に必要な作業内容を洗い出し、工数の確保に努めたという。
複数人での運用を見据えたテスト自動化を
次に、「複数人でコーディングしたときの話」である。
先の課題を乗り越え、江村氏はテスト自動化チームを発足させた。これは、複数のテスト自動化エンジニアが複数プロダクトのテスト自動化の実装・運用を専任するチームだ。十分な工数を確保して、誰もが使いやすいローコードツールを用いて、テスト自動化を実装した。これで毎日リグレッションテストをすれば、うまくいくだろう——そう考えた江村氏だったが、結果的にはテスト品質や自動化品質の一貫性が保てなくなるという事態に陥った。
このときの課題について、江村氏は次の2つを挙げた。
課題3：テスト観点や検証方法がバラバラ
たとえば会員登録の際に、複数ページを遷移するサイトのテスト自動化を実装するとしよう。エンジニアAは機能テストのスクリプトを書いたが、ページの遷移はチェックしなかった。処理が正しく進めば、次のページに遷移したという証明になるからだ。
それに対し、エンジニアBは機能テストに加え、遷移した先のタイトルをチェックするスクリプトを書いた。タイトルが機能名になっているので、ページが正しく遷移したことがわかるからだ。
他方、エンジニアCは機能テストと代表的なUI要素の存在をチェックするスクリプトを書いた。慎重派のエンジニアCは、偽陰性を恐れ、多くの要素を確認してページ遷移の妥当性を示したいと考えたからだ。
どのエンジニアも間違っているとは言えないが、エンジニアによって「どこまでテストするか」というテスト観点が異なると、当然ながらテスト品質の一貫性は損なわれてしまう。他の人のスクリプトを修正するのも大変だった。
検証方法についても同様だ。Eコマースで商品購入する際に、商品ページ・購入確認・完了・購入履歴の金額が正しく一致していることを検証したいとする。エンジニアAは期待値をあらかじめ計算し、その値と画面に表示されている金額を比較して検証した。次にエンジニアBは、購入確認で表示された金額を期待値として、完了・履歴の値を検証した。残るエンジニアCは、任意のテストデータに対応するため、期待値をスクリプトで自動計算して検証した。自動化のスクリプト側に計算式を仕込むことで、単価が変わってもスクリプトが吸収できるように実装したのだ。
これらのテストには偽陰性が含まれており、自動化の品質に一貫性がない。
課題4：ローコードなのに保守が大変
テストケース名や要素名、キーワードなどの命名ルールが、エンジニアによってバラバラで、スクリプトの保守が大変になってしまった。また、ローコードの標準機能にはない操作を独自で作成できるカスタム関数を使って、条件によってステップが異なる（下図）テストケースをひとつにまとめようと考えるエンジニアもいた。この場合、テストケースが増えないメリットはあるが、カスタム関数が複雑になっていくにつれ、保守が大変になり可読性が下がるというデメリットもある。
これらの課題を解消するために、江村氏は「テストの基準を設けて、テスト品質や自動化品質を保つ」「コーディングルールを設けて、自動化の保守性を保つ」という取り組みを行った。
ステークホルダーと一緒に進める
最後に、「テスト自動化が孤立したときの話」である。
これまでの課題を乗り越え、テスト自動化を運用フェーズにのせた江村氏。ガイドラインを設けて自動化の品質をキープ、毎日テストを実行してプロダクトの品質をキープ、テストが失敗したらすぐに調査し、不具合があればバグチケットを発行する。「今度こそ、これでうまくいくだろう」と考えたが、開発や手動テストチームといったステークホルダーからクレームが入るという残念な結果になってしまった。
それはなぜか。江村氏は次のように分析した。
課題5：ステークホルダーと協働していなかった
テスト自動化チームは、プロジェクトに関係なく毎日テストを実行するし、不具合が見つかったらすぐにバグチケットを発行して開発に依頼を投げるというスタンスだった。これに対し、「サーバーのリソースが圧迫されて、開発に影響が出るし、新しい機能をデバッグしているのだから、バグは出て当たり前。リリースのリハーサルを行うために、データをリセットして入れ直しているのだから、環境は不安定になって当然であり、テストが失敗するのは必然だ。テスト自動化チームのせいでサーバーの保守や調査依頼の対応で負担が増えた」というクレームが開発からあがったのだ。
他方、手動テストチームからは、「テスト自動化チームのテストはブラックボックスになっていて、何をテストしているのかよくわからない。テスト自動化チームがあることでテストが楽になったという実感はない」と言われ、江村氏は肩を落としたという。
江村氏は、この課題を解消するために、ステークホルダーと話し合いの場を設けた。テスト自動化の実行環境について開発チームと協議をしたり、手動テストチームとテスト自動化チームの担当箇所を可視化したりした。「テスト自動化チームがあることで、開発チームにとっても手動テストチームにとってもこれだけメリットがあるのだ」と、定量的に示して理解してもらう努力もした。
最後に江村氏は、「テスト自動化にまつわる苦しい経験を通じて、『テスト自動化の目的を定め、それに沿った計画・実装することが大切であること』『自動化の保守性を高めるため、一定のガイドラインが必要であること』『ステークホルダーと協働して、みんながハッピーになるように進めていくこと』の3つを学んだ。私の失敗が、みなさんのお役に立つと幸い」と観客にエールを送り、セッションを締めくくった。
