属人化による「テスト自動化」の落とし穴とは
テストの専門会社として、下流工程を中心に結合テスト以降のアウトソーシングテストを年間2,600件以上こなすバルテス。同社による「テスト自動化の経験」に関する調査によると、「現在実施している」が42％、「現在実施していない」が19%、「自動化したことはない」は39％という結果が得られている。なんとテスト自動化の経験者のうち、約3分の1はやめてしまっているのだ。
その理由としては、「自動化担当者がやめたため、誰もメンテナンスできない」「ツールの更新が面倒で使わなくなった」「テストスクリプトの更新が仕様と合っているか不安」「結局は手でやった方が早い」といった悩みが挙げられる。
さらに、テスト自動化に関する課題を聞いてみると、「知識・スキル不足」41％、「工数などのリリース不足」31％、「コストがかかりすぎる」27％と、99％が自動化に何らかの課題を抱えているのだ。
では、これらの課題をどう対策したらいいのか。セッション前半は、バルテスのテストアライアンス事業を取りまとめる石原氏から、テスト自動化に関する現状の課題とその解決策について解説が行われた。石原氏はソフトウェア品質やテストに関するセミナーや書籍も執筆・監修しているソフトウェアテストのスペシャリストでもある。
まず、現在のテスト自動化とは「テスト実行」を自動化することを指す。これまで人間が手動で行っていたUIテストを自動化することによって、作業時間の短縮や工数削減、見落としなどの人為的事故の防止などが期待できる。
手動化テストの場合、テスト対象システムの分析やどんなテストをするかを整理して、テスト設計し、それをもとに実装していく。テストを実行した結果、NGであればレポートを作成し、修正を行うといった流れが一般的だ。
それに対してテスト自動化では、自動化環境を構築し、テストスクリプトを作成したら、テスト実装の部分をツールが実施してくれる。
だがメリットだけではない。冒頭紹介したように、テスト自動化経験者の約3分の1は挫折し、99％が何らかの困難を抱える落とし穴もあるのだ。
「とりあえず」「なんとなく」自動化してみようというのが一番トラブルを招くもと。ツールの進歩によって導入が容易になった反面、メンテナンスに手間がかかるといったデメリットもある。導入コストが回収できないまま、ツールが使われなくなってしまうことも少なくはないと石原氏は説明する。
「損益分岐点で見ると、イニシャルコストを回収するためには、テスト自動化ツールを繰り返し使うこと。つまり、使い続けることでROI（費用体効果）は向上します」（石原氏）
このテスト自動化を阻むポイントをまとめると、「属人化」という課題に集約される。自動化技術の属人化でいえば、プログラム技術、自動化ツールの習熟、環境構築・メンテナンスなど。テストの属人化では、テストケースとスクリプトの二重管理やメンテナンスだ。
属人化が引き起こしたテスト自動化の失敗例も紹介された。以下の4事例である。
事例1：使われなくなったテスト自動化
開発エンジニアがかけもちして対応していたが、「多忙でメンテナンスができない」「手動テストが増え、コストも増加してしまう」など、十分なリソースが確保できずに「メンテナンス負債」が溜まっていくパターンである。
事例2：違う言語で作り替えになったテスト自動化
自動化テストを作っていたエンジニアが、自動化技術を引き継がずに退職してしまうケース。例えば、Javaエンジニアがつくった自動化テストをRubyエンジニアが新規に作り直す場合、一度リセットするため、倍のコストがかかってしまう。
事例3：自然言語をスクリプト言語で書き換えになったテスト自動化
テストケースを日本語で書いたがために、自動化ツールを走らすスクリプト言語でも書かなくてはならず、二度手間になってしまうパターンもある。仕様変更やメンテナンスのたびに両方の更新作業をすることになり、テストケースとテストスクリプトが一致しなかったり、テスト漏れといったトラブルも起こったりする。
事例4：テスト自動化を難航させるテストケース
最後は属人化の最たる事例だ。テストケースの前提条件をざっくり書いているために、テストデータの誤りや期待結果の確認もれなど、自動化実装が終わらないケースである。
どの事例にも共通しているのは、「費用対効果が悪いこと」だと石原氏は強調する。では、属人化を解消し、黒字化させるにはどうしたらいいのか。後半のセッションは江添氏にバトンタッチし、前半で石原氏が挙げた失敗例に対して、どうすれば解決することができるのか、現場の実例に即して、その対策のポイントについて語られた。
失敗しないテスト自動化のポイントは「属人化」対策
江添氏はソフトウェアテスト技術者資格「JSTQB」を所有するバルテスのテストエンジニアとして活躍するかたわら、テスト自動化に関する執筆活動なども行っている。
まず江添氏は、属人化を克服するポイントとして「フィージビリティスタディ」「テスタビリティ」という2つのキーワードを挙げた。
フィージビリティスタディとは、テスト自動化の本格導入前に実施する自動化の実現可能性調査のこと。自動化したメリットが得られるか、継続する確実性はどのくらいかなどを把握することができる。
テスタビリティは必要なテストが十分実施できるかを表す指標であり、テスタビリティを上げることで、メンテナンスに強いテストツールを作ることが可能となる。
テスト自動化の実現可能性が確認できたら、次に意識したいのは自動テストの実行時間である。短時間で利用頻度を高めるために、並列実行を想定してテスト設計をすることが重要となる。
システム設計において、本体のテスト対象で考慮すると良いポイントについても紹介された。テストケースは、期待結果を確認するためのテスト条件・テスト手順、合否判定するための期待結果で構成される。
それらに必要なテストデータやシステム状態、アクション、操作対象、比較判定、比較対象に対し、モック・スタブ、テスト用のAPIを用意し、自動化しにくいアクションの見直しやUI要素を一意に特定することで、バグの原因が特定しやすくなる。
また、自動化する候補を絞り込むこともテスト自動化においては、非常に大事であると江添氏は強調する。短時間で何度も実行できることに加え、期待結果を一つにすることが重要なのだ。
続いて、現在のテスト自動化における主流の考え方の一つとして紹介されたのが、「キーワード駆動テスト」だ。最新のソフトウェアテスト標準規格であるISO/IEC/IEEE 29119 Part.5で定義されている。
また、キーワード駆動テストは基本的な動作のキーワードを自然言語として設定し、そのキーワードにスクリプトを定義する。キーワードを使用してテストケースを作成すると、自動的にスクリプトに変換される。
簡易な手順でテスト自動化が設定できる一方で、UI要素のパス指定や定期的な見直しが必要であるほか、通常の自動化より高度なキーワード設定やカスタマイズのスキルが求められるといった課題もある。
このキーワード駆動テストを採用したテスト自動化ツールが、バルテスが提供する「T-DASH」だ。特徴としては、プログラムを書くことがないローコード、かつ日本語でつくることができる。
江添氏はT-DASHのデモを披露した後、効果の目覚ましかったテスト自動化事例を2つ紹介してくれた。
事例1：カード会社さま向けシステムマイグレーション
一つ目は、カード会社のレガシーシステム（COBOL）を新システム（Java）にマイグレーションした事例。新旧システムで差分結果を集めて確認したいが、そのテストケースが20万件と膨大な件数だった。
ユーザーサイトの自動化や利用可能枠、支払仮確定、確定、後リボなど全機能確認を実施し、20万件の比較テストはやり切ったが、費用対効果を高めるためには、以下のような課題も残った。T-DASHはこれらの課題を解消できるツールとして開発されている。
費用対効果を高める対策例
- 再利用性を高める：ログインなどの標準機能をモジュール化
- メンテナンス性を高める：テストケースのメンテのみでOK
- テスト内容の見える化：実装者以外でも実施内容が分かる
事例2：証券会社さま向け基幹システム
もう一つの事例は、証券会社の基幹システムにおける毎月リリースの負担を軽減し、コスト削減を図るもの。
まずは、自動化の効果を見極めるためにフィージビリティスタディを実施。自動化適合性が高いことを確認した上で、適性が高い領域を自動化。毎月のテストコストを約60％削減することに成功。テスタビリティを見極めることが成功につながった事例となった。
最後に石原氏が再度登場し、以下の4点を改めてまとめてセッションを締めた。
- 属人化は失敗を引き起こす
- スピードアップにテスト自動化は欠かせない
- 自動化は使い続けることで、ROIは高くなる
- 気軽に使えるツール導入が重要である
日本語で作ったテストケースをそのまま自動化することで自動化を誰でも理解・保守できるテスト自動化ツールです。
