こんにちは。環境対応チームの森本です。
今回は手動で行っていたテストを自動化し、約22％の工数削減を実施したお話をさせていただきたいと思います。
詳細は後述しますが
結論として、Windows 10 の新しい機能更新プログラム(FU) を適用した際の LANSCOPE クライアントのテスト（本記事では「Windows10対応」と表現します）について約22%の工数削減を達成することができました。
またテスト自動化の計画開始から運用までは、約6か月の期間を要しました。
テスト自動化を進めた背景
私は新OS対応など、新たなOSがリリースされた際にいち早くMOTEX製品のオンプレミス版、クラウド版（以下、両方合わせてLANSCOPEと記載）の動作テストを行う業務を担当しています。
その中でもWindows10は、これまで毎年春秋に年2回の機能更新プログラム（FU : Feature Update）がリリースされてきました。
ちなみにMicrosoft社のアナウンスでは2022年からは、Windows10は年1回のFUリリースに変わるようです。ただWindows11という新たなOSも出ましたね。。汗
FUがリリースされる度に、LANSCOPEが正常に動作するかテストする必要があります。
LANSCOPEは多機能なため、毎回、全機能のテストに大きな工数がかかっていました。
またコスト以外にも以下の課題を抱えていました。
- OSがリリースされてから、対応表明までに時間が掛かる
- テストの完了を早めるには、人員を増やすしかない。
- 人員を増やすと、新規に参画したメンバーは慣れておらず、操作ミスやテスト仕様書の内容を誤解するケースが起こる
そこで、Windows10対応では基本的には毎回同じテストを繰り返すため、自動化することでこれらの課題の解決を図ることを計画しました。
細かく言うとOSの新機能のテスト、LANSCOPEの新機能のテストなど、テスト件数は毎回少しずつ増大する傾向にあります。
目標として30％の工数削減を目指すことにしました。
テスト工程の細分化と工数算出
具体的にどういった操作を自動化するべきかを見極めるため、まずはテスト実施作業を細分化し、どの工程にどれくらいの工数が掛かっているのかを確認するところからはじめました。
上記より「クライアントの操作（ログを取得させるなど）」だけでは、目標である30％の工数削減には到達できないことが分かったので 「期待値確認」も含めて、自動化対象とすることにしました。
単純計算で両方合わせて58.4%になるので、もしすべて自動化できれば目標以上の成果を出すことが可能です。
期待値確認のパターン精査
更に「期待値確認」と一口に言っても、いろいろなパターンがあるため、パターンの洗い出しとその割合を精査しました。
洗い出した中で割合が大きい「（コンソール、Webコンソールなどの）画面の確認」について自動化できれば、58.4%には届かなくても目標の30％は達成できる見込みが立ちました。
これにより具体的にどういった部分を自動化したいのか、要件が固まってきました。
テスト自動化ツールの選定
次に世の中にどういったテスト自動化ツールがあるのかを調べ、その上で要件を満たすものを調べました。
また要件を満たすだけでなく、実際の運用シーンまで詳しくイメージして、より使いやすいモノを選択することにしました。
- UiPath（Studio Pro）
- TestComplete
- Ranorex
その結果これらのツールを検討し、要件である「クライアントの操作（ログを取得させるなど）」～「（コンソール、Webコンソールなどの）画面の確認」までのテストの一連の流れを自動化できるツールとして、Ranorexを選定することにしました。
また、その他のRanorex選定のポイントとして以下が挙げられます。
- Delphiに対応している（LANSCOPE オンプレミス版の開発環境）
- 買い切りライセンスであるため、活用できればできるほど費用対効果が高くなる
テスト自動化を進めるうえで重要なポイントとしては、テスト自動化ツールから調べるのではなく、まず自分たちがどういったことをしたいのか、目的・目標を定めて、要件を先に明確にすることです。
ツールはあくまで手段なので、目的と手段が逆転しないように気を付けなければいけません。
Ranorexの使用方法などは本記事では記載しませんが、このツールにより「クライアント端末上で指定した操作を行わせて、コンソールにそのログが表示されることを確認する。」
という一連のテスト実施の流れ（今回の要件）を自動化することができました。
結果と問題点
しかし、結果的に約22％工数削減は達成できましたが、目標である30％には届きませんでした。
原因としては、自動化のスクリプトを作成し、動作確認を行っていた端末と実際にテスト実施時に使用する端末が異なることで、端末の負荷状況などによってスクリプトの実行が失敗することがあった。という点が大きかったです。
掻い摘んで記載しますが、スクリプトには以下のような流れで処理を記載しています。
- 操作Aを行う。
- 表示された画面上で操作Bを行う。
- コンソールを起動し、意図したログが表示されている確認する。
このとき、動作確認を行っていた端末では正常に最後まで処理が通りましたが、実際のテスト端末では、「1. 操作Aを行う。」の時点でまだ操作が終わり切っていないのに、「2. 表示された画面上で操作Bを行う。」の処理が始まってしまう。
といった問題が頻発してしまったのです。
そのためスクリプトの修正が間に合わず、自動化する予定だったテストについても、いくつか手動で実施することになってしまい、目標の30％工数削減には至りませんでした。
しかし次回のWindows10対応時には、テスト自動化を実施する端末は固定し、更に今回手動で実施した部分についても自動化する予定なので、既に50%以上の工数削減を見込んでいます。
まとめ
今回はMOTEXで初の新OS対応テスト自動化の試みであったため、想定外の問題にもぶつかりましたがこの反省を活かし、今後は更にテスト自動化範囲を広げていく計画をしています。
お客様に、より高品質な製品をより早く提供することを今後も追及していきたいと思います。
最後まで読んでいただき、ありがとうございました。
