複数人での運用を見据えたテスト自動化を
次に、「複数人でコーディングしたときの話」である。
先の課題を乗り越え、江村氏はテスト自動化チームを発足させた。これは、複数のテスト自動化エンジニアが複数プロダクトのテスト自動化の実装・運用を専任するチームだ。十分な工数を確保して、誰もが使いやすいローコードツールを用いて、テスト自動化を実装した。これで毎日リグレッションテストをすれば、うまくいくだろう——そう考えた江村氏だったが、結果的にはテスト品質や自動化品質の一貫性が保てなくなるという事態に陥った。
このときの課題について、江村氏は次の2つを挙げた。
課題3：テスト観点や検証方法がバラバラ
たとえば会員登録の際に、複数ページを遷移するサイトのテスト自動化を実装するとしよう。エンジニアAは機能テストのスクリプトを書いたが、ページの遷移はチェックしなかった。処理が正しく進めば、次のページに遷移したという証明になるからだ。
それに対し、エンジニアBは機能テストに加え、遷移した先のタイトルをチェックするスクリプトを書いた。タイトルが機能名になっているので、ページが正しく遷移したことがわかるからだ。
他方、エンジニアCは機能テストと代表的なUI要素の存在をチェックするスクリプトを書いた。慎重派のエンジニアCは、偽陰性を恐れ、多くの要素を確認してページ遷移の妥当性を示したいと考えたからだ。
どのエンジニアも間違っているとは言えないが、エンジニアによって「どこまでテストするか」というテスト観点が異なると、当然ながらテスト品質の一貫性は損なわれてしまう。他の人のスクリプトを修正するのも大変だった。
検証方法についても同様だ。Eコマースで商品購入する際に、商品ページ・購入確認・完了・購入履歴の金額が正しく一致していることを検証したいとする。エンジニアAは期待値をあらかじめ計算し、その値と画面に表示されている金額を比較して検証した。次にエンジニアBは、購入確認で表示された金額を期待値として、完了・履歴の値を検証した。残るエンジニアCは、任意のテストデータに対応するため、期待値をスクリプトで自動計算して検証した。自動化のスクリプト側に計算式を仕込むことで、単価が変わってもスクリプトが吸収できるように実装したのだ。
これらのテストには偽陰性が含まれており、自動化の品質に一貫性がない。
課題4：ローコードなのに保守が大変
テストケース名や要素名、キーワードなどの命名ルールが、エンジニアによってバラバラで、スクリプトの保守が大変になってしまった。また、ローコードの標準機能にはない操作を独自で作成できるカスタム関数を使って、条件によってステップが異なる（下図）テストケースをひとつにまとめようと考えるエンジニアもいた。この場合、テストケースが増えないメリットはあるが、カスタム関数が複雑になっていくにつれ、保守が大変になり可読性が下がるというデメリットもある。
これらの課題を解消するために、江村氏は「テストの基準を設けて、テスト品質や自動化品質を保つ」「コーディングルールを設けて、自動化の保守性を保つ」という取り組みを行った。
