令和元年、働き方改革関連法が順次適用され、多くの企業が労働時間の見直しや生産性向上に取り組んでいます。われわれ組込み業界の開発現場においても、多くの工数を要するソフトウェアのテスト作業を自動化し、作業効率化を検討する企業が増えています。トップダウンにより、部門やチーム毎のテーマとして、「テスト自動化による効率化」が掲げられることは多く、どのくらいの予算が必要で、どういう期間で進めるか？それに伴うリスクは何か？全体の見通しを立てるために、どうしても最初から「大きな取り組み」として考えてしまいがちです。

スモールスタートで始めるテスト自動化

テスト自動化を検討するにあたって、先を見越した自動化システムの仕様・機能や開発リスクなど、アレコレ考えることが多くて話がなかなか進まない。やることが多くて何から手をつけたらわからない。といったはことはありませんか？「最初から準備できるものはしておく」のは理想的ですが、先が読めない新しい取り組みに関しては、小規模で実験的に素早く始めることで、失敗リスクを最小限に抑えつつ、徐々に大きな仕組みに育てていく、『スモールスタート』の考え方がマッチするかもしれません。

テスト自動化の環境構築も、モノづくりです。モノづくりには、失敗はつきもの。リスクをゼロにはできません。手戻りもあるかもしれまんせんが、試行錯誤の繰り返しによって、より良いモノが作り上げられます。「小さな失敗」を許容できる範囲で、次のステップへ進むための背伸びしない「目的」を設定して、テスト自動化の環境構築に取り組んで行きましょう。

どのテストを自動化するか？

自動化による「価値」を考える

全てのテストを自動化できるわけではないので、自動化ができそうなテストの中から、まずどのテストを自動化することに「価値」があるのかを考えます。自動化の対象となるテストを、以下のような観点で検討します。スモールスタートするために、自動化によって効果が出そうなテストの中から上位のものに絞って検討していきます。

一方、自動化に向かないテストは、製品の仕様変更に伴い、自動化環境のメンテナンスが頻発しそうなテストです。UIを持つアプリ部分に関連するテストの回帰テストを自動化する場合、UIの仕様変更があると、自動化環境も都度メンテナンスが必要となり、自動テストが実行できなくなります。組込み機器の自動化においては、例えば通信仕様が変更になることで、同様にテスト対象を自動制御できなくなる場合が考えられます。仕様変更が発生する可能性とその影響のインパクトも考慮する必要があります。

テスト自動化の８原則

先人の知恵を借りることも、リスク削減のポイントとなります。テスト自動化研究会 STARによる「テスト自動化の8原則」も留意して、自動化するテストの選定や自動化の取り組み方を考えてみましょう。　

1. 手動テストはなくならない
2. 手動でおこなって効果の無いテストを自動化しても無駄である
3. 自動テストは書いたことしかテストしない
4. テスト自動化の効用はコスト削減だけではない
5. 自動テストシステムの開発は継続的におこなうものである
6. 自動化検討はプロジェクト初期から
7. 自動テストで新種のバグが見つかることは稀である
8. テスト結果分析という新たなタスクが生まれる

[参考]テスト自動化研究会 STAR　https://sites.google.com/site/testautomationresearch/test_automation_principle

自動化する目的を把握する

自動化するテストの取捨選択において重要になるのは、自動化をする「目的」です。
「テスト時間の短縮」を目的とした場合、容易に自動化できるテストの自動化を実現したとしても、利用頻度が少ないテストであれば、目的は達成できません。効果を出すには、何をもってテスト時間が短縮したのか(KPI：Key Performance Indicator)を計測する必要があります。KPIを設定することで、目的の達成度合いを計測・監視できるようになり、改善のサイクルを回すことができるようなります。
また、KPIの設定は、関係者間の目標設定にも活用でき、達成感を共有できたり、全体の士気が下がり難くなると考えられます。もしスモールスタートでなく、複数のテストに対する自動化を取り組んだ場合は、どうなるでしょうか？計測するKPIが多くなり、次のステップに行くための仮説を立てることも、改善させることも困難になります。そのため、KPIの計測に時間と工数を要するテストについては、スモールスタートによる自動化には向いていない、とも考えられます。

自動化システムのフレームワーク

組込み機器のテスト自動化においては、結合テストやシステムテストフェーズにおけるブラックボックステスト手法を自動テストで実現させることが多いです。従来のテストでは、ターゲットに対して、操作や制御(INPUT)を行い、その時のターゲットの挙動(OUTPUT)を目視し、合否を判断し、結果をエビデンスとしてレポートにまとめる、といった一連の作業になります。これらの作業を自動化するシステムを開発する際に、4つの技術要素にわけると考えやすくなります。

例えば、ターゲット製品の挙動を目視して判断するだけでなく、内部の変数値RAMのモニタができる機構を実装していて、製品を手動で操作しながら、テストやデバッグできる環境があるとします。つまり、ターゲット製品の内部状態を「監視」するといった技術要素が、既に確立されている環境を対象とした場合です。現在所有しているデバッグツールを自動化できる環境に拡充することで、テスト作業を効率化できる場合もあります。既存のシステムを活用することで、初期コストを抑えて、すぐに立ち上げることもできます。

この場合、ターゲット製品の手動操作の「駆動」にあたる部分を実現することで、「駆動」と「監視」だけでも自動化ができれば、夜間テストが可能となります。業務終了前にテスト実行して、翌朝に取得済の監視データを確認し、すぐにフィードバッグできることも可能となり、評価者は昼間の時間の使い方が変わってきます。

より完全に近いカタチで自動化環境を構築しなくとも、成果を出せる環境を目的とすることで、リスクよりも成果が勝る状況を作りながら、将来に向けて自動化を進捗できます。残りの要素技術である「判定」及び「報告」の自動化については、自動テストによるテスト実行の実績やノウハウが蓄積され、今後の運用をふまえて、自社製品にとって必要なものを見極められるようになってから、より最適な自動化環境の拡充を検討していく方が、様々な変化に対するリスクを低減できると思います。

まとめ

働き方改革によって、作業の見直しが迫られるようになった現状と同様に、将来必要となる効率化の手段も変化していくと思います。テスト自動化をあまり大きく構えすぎず、小さく素早く始めて、小さな成果を早く出す。そして、柔軟に方向転換しながら、無駄なく変化に対応していく「スモールスタート」をオススメしたいと思います。
ソフトウェアテストの自動化に関して、これから検討を始める方、始めたばかりの方がいらっしゃいましたら、是非一度弊社にご相談ください。新時代に向けてスモールスタートを切って、ゴールまで一緒に走りましょう！

---

＜参考文献＞
Mark Fewster,Dorothy Graham 著　テスト自動化研究会 訳　「システムテスト自動化標準ガイド」　株式会社 翔泳社