こんにちは。QAエンジニアをしているハルです。
現在は、Webアプリのテスト業務に日々取り組んでいます。過去にはデジタルカメラ等のバンドルソフトや複合機のファームウェアに関するテスト設計、実施、管理業務にも携わっていました。
3/9-10に開催された、JaSST’23Tokyoにオンライン参加してきました。以前、携わっていたプロジェクトで自動化チームが旗揚げ時に苦労していたなという記憶と、ファームウェアテスト時に、実施するテストケースの組み合わせパターンが非常に多く、リリース毎、対象機種毎にこれらのテストを何度もこなす大変さから、テスト自動化に興味を持っていました。
今回、組込デバイス向けのテスト自動化推進をされている現場で挙がっている課題と対策を紹介するセッションに参加させていただいたので、自分の体験や記憶と照らし合わせながらレポートしたいと思います。これからテスト自動化の導入を考えている方にも読んでいただけたら幸いです。
JaSSTとは
JaSSTとは「ソフトウェアテストおよびソフトウェア品質に関心のある方が深い学びを得ることを目指して、ソフトウェアテスト分野の幅広い情報と、参加者同士の交流や議論ができる場を提供」するため、特定非営利活動法人ソフトウェアテスト技術振興協会(ASTER)が主催する日本最大級のソフトウェアテストのシンポジウムになります。
JaSST’23 Tokyoのテーマは「相互理解で広がる世界」ということで、関連するセッションが多数催されました。
組込デバイス向けSQAにおけるテスト自動化の推進
～ビジュアルプログラミングを使ったテスト自動化～
登壇者の方々は、世界のソニーさんということで、組み込みデバイスを制御するソフトウェアの品質向上、自動テストのサポート等をされており、テスト自動化ツールも自前で開発してすごいな！と思いながらお話を聞きました。
複雑化、大規模化するソフトウェア開発で自動化のニーズが高まっている昨今、テスト自動化を進めている現場での課題について、原因分析や解決策を挙げ、自社で開発された自動化ツールを「プログラミングスキルに関係なく、誰でも使える」取り組みとして、ビジュアルプログラミングを利用したツール開発と導入事例を紹介されていました。
学び１ テスト自動化のメリットとデメリット
まず、手動テストと自動テストの特徴を整理しながら自動テストの特徴を説明されていました。
手動テストは、
⚠️ 実行者のドメイン知識や熟練度によって、テスト品質にばらつきや属人化がでやすい
確かに、今までに経験したある現場では先にテストを行っていたメンバーのドメイン知識や熟練度との差を感じ、担当する機能毎にばらつき感がありました。その時は、メンバー間でのレビューの強化、テスト観点等のノウハウを共有することで、レベルを少しずつ合わせていく取り組みをしていました。
⚠️ 製品開発が進むにつれ、対応機器や機能が増えることによりリソースが不足してテストの網羅性が低下する
⚠️ 外部デバイスやクラウドと連携するなどでE2Eテストがどんどん複雑化してきている
私が携わっていた現場も、対応機器や機能が追加されることが多く、限られたリソースでテストを行うため、サポート機器や各機能のテスト範囲を絞り込んで実施することになり、テストの網羅性は低下していました。どの現場でも同じようなことが起きているのだなと感じました。
続けて、テストを自動化することで、以下のような効果が得られると説明されていました。
💡 テストステップが安定して実施できる
💡 誰が実行しても同じ結果が得られる
💡 人の作業時間に依存しない
同じテストケースを実行でき、属人化せず数あるシリーズ機種などで動作確認ができるのは非常に便利ですよね。また、人の作業時間に依存しないというところが大きなメリットだと思いました。実機を使ったテストとなると、リソースが限られていて「待ち」の状態が発生してしまい効率が悪くなりますが、例えば、稼働していない夜中にスケジュール実行したり、仮想PCを使用することで、1機種のテストに時間がかかったとしても、稼働中の人の邪魔をしないので、網羅性を下げないテストが効率的に行えます。
とはいえ、
☝ すべてを自動化することはせずに、複雑で高度なテストは手動で行う方がよい
とも説明されていました。例えば、探索的テストについてはドメイン知識や熟練度が色濃くでるものですし、対象機能に合わせた観点で適切な重みづけでテストすることが必要だと思いました。
回帰テストのような反復的なテストは自動化することで、限られたリソースで網羅性を下げることなく安定したテストが実施できます。
手動、自動、お互いの良いところを利用してテストすること（手動テストとの棲み分け）が大事だということが学べました。
学び２ 現場でテスト自動化がなかなか進まない原因
次に、現場で自動化を導入したものの、なかなか軌道に乗らない事例を挙げ、各関係者が抱いている悩みや原因を説明されていました。
【担当者】【運用者】の悩み
🗣 テスト業務で手一杯、プログラミングスキルも不足していて、自動化まで考えられない
🗣 自動テストの開発者と実際テストでツールを使用する担当者でスキルがあわず、説明しても「？」がいっぱいで不要なQ&Aが増える
🗣 結果の解析も大変で時間がかかり、活用しきれない
私が携わっていた現場の自動化チームでは、実装者が担当、運用も兼ねており、関係者間のトラブルはあまり記憶にありませんが、取り組みの序盤に、テストチームと自動化チームで「ツールの使用方法」や「アウトプットをどのようにまとめ、活用するか」をすり合わせたこと、両チームメンバーがすぐ隣で作業していたことでサポートしやすい環境にあったのだと思います。
【実装者】の悩み
🗣 テストフレームワークを使いこなすのが大変（ツールにより性能や使用方法に差がある） 使っていたツールが仕様変更に対応できなくなり、使えそうな別のツールを探して同じことを繰り返す
🗣 過去の実装担当者が作ったプログラムのコード解析や修正が大変（属人化）
🗣 開発者も業務が忙しくなると、仕様変更に対応したツールの修正まで手が回らなくなり、使われなくなってしまう
🗣 仕様変更を見越して自動テストを組んではいるが、インターフェース仕様が予想を超えて変更された場合は大変
複数人でコードを作成すると実装者の個性が出て、ここでも属人化の要素が出てくるんですね。
機能の増加や、仕様変更の度にコード等を構築しなおしたりする手間が非常に大きく、作業の大変さが自動化するメリットを上回ってしまうといった内容で、これについては他の参加者も共感しており、予めいつまで使い続けるか寿命を考えることも大事だと話されていました。
関係者ごとに様々な困りごとが挙げられていましたが、実装者の悩みが一番多いということが示されていました。
私は以前自動化ツールを学習した際に、学習なので自分の使い勝手がいいように自由にやっていました。いざ現場でテストケースを機能毎に複数人で作成することになった場合、こういったことを共通ルールとして決めておく、また仕様変更があることを前提としてカスタマイズしやすいコード作成が必要であると再認識できました。
学び３ 人に依存しない解決方法「ビジュアルプログラミング」
上記で挙がった実装者の主な悩みの原因である
「プログラミングスキルの技術差」「ばらばらなコーディングルール」を解決するため、
ビジュアルプログラミングによる自動テストツールを開発した話になっていきます。
まず、これらの課題をプログラマーの育成で対応できないかを検討したところ、
🙄 「育成メンバーや期間、コストが捻出できるのか？」
⇒そもそも業務に手一杯な人たちが育成研修や勉強に十分な時間をさけないのでは？
🙄 「育成の習熟度はどうやって図るのか？」
⇒評価する側、される側の負担が増えてしまわないか？
🙄 「当初のコーディングルールの順守をどう確認するのか？」
⇒やっていくうちに派生したルールができてしまったりしないか？
このような懸念が挙がり難しいとの結論に至ったそうです。
そして、自社開発の「自動テスト用フレームワーク」というものがあり、様々な機器操作、高度な判定機能を持つツールだそうで、このツールを使いこなせる人を育成するよりも、誰でも使えるようにする方法を考えた解決方法が「ビジュアルプログラミング」を利用したテスト自動化ツール開発とのことでした。
「ビジュアルプログラミング」とは
視覚的にオブジェクトを置いて繋げるプログラミング技法で、図形やイラストをつなぎ合わせることプログラミングする方法です。いわゆる黒い画面に文字を書いていくテキストプログラミングとは異なり、視覚的にわかりやすくプログラムを作ることができます。
レゴ社のマインドストームなどの教育玩具的なものもあり、小さな子どもでもプログラミングに触れるきっかけになっている技術ですね。
学生の頃、マインドストームがどうしても欲しくて割と高価でしたが思い切って購入し、実際に動くロボットを作って動かせた時は何とも言えない達成感と、すごくシンプルで簡単なことに感動した記憶があります。それでいて奥が深かったことも。
ツール開発で実現したこと
✅ 小さなプログラムや関数の単位をユーザインターフェース上でオブジェクトとして表現
✅ 使いたい順に並べてテストケースを作成していくことで、プログラミングをしたことがない人でも使える
✅ 作った物を自動でプログラミング言語に変換するので、コーディングルールも統一される
✅ 自動テスト用フレームワークの各機能と組み合わせることができる
このようにして、「誰がやっても同一なコードがかけ、高精度な自動テストができる」を実現したと説明されていました。
デモ操作で、実際に作成したテストケースでテレビモニターを操作しているところも見せてもらいましたが、画面上のコード（図形が線で繋がった処理の流れ）もスッキリとして見やすく、ツールに慣れさえすれば他の人が作成したものでも読み解きやすいなと思いました。
このツールの導入効果についても次のように報告されていて、
✅ テストケース作成に作り手を選ばない
⇒プログラム書けない人、プログラム書ける人が同一レベルの自動テストができた
⇒担当者間での引き継ぎやノウハウも共有しやすい
✅ ある程度慣れた担当者の結果
⇒プログラムコードをゴリゴリ実装したテストケースの作成時間と比べ、ビジュアルプログラミングで実装することで作成時間が1/10程度に短縮された。
短縮した要素は、実装者がそれぞれ行っていた「ライブラリの調査」、「コーディング時のリターン値の保存」、「その後の処理など」を、ツール側で機械的に行うことで、細かいことを気にせずにできたことに表れているとのことでした。
私が昔、C言語を学習していた頃は、コード記述の作法やリターン値のこと等いろいろと考慮するため、それなりに時間がかかり大変でした。それと比べると遊びでやっていたマインドストームのプログラミングでは「まっすぐ進む」「ラインセンサーが反応したら」「3秒待機「90度右に旋回」のように直感的でわかりやすく、細かいことを気にせずに簡単に作成できていました。
今回開発されたツールも同じくらい楽にテストケースが作成でき、簡単に使えそうな気がします。
逆に、前々からゴリゴリ実装していたプログラマーからすると物足りなさを感じたりしないか？と質問されていましたが、属人化しないこと、誰でもカスタマイズできる等の保守性を重視したとのことでした。職人としてはウズウズしてしまうのかもしれませんね。
まとめ
自動テスト関連のセッションは最近増えてきていて、自動化の利点や現場での課題解決に関する話が聞けて、実現場で導入経験がまだない私にとっては非常に興味深いものでした。
このセッションを聞けたことで、テスト自動化ツールが使いやすく進化していることも知れ、これから自動化を検討している現場へ導入するハードルもぐっと下がっていくのではと考えます。
私も自動テストに関する知見を少し広げることができたと思います。
ちなみに、今回参加させて頂いたJaSSTではセッション中にDiscordのチャット機能を利用して参加者が自由に会話や議論ができ、他の参加者から気づきをもらえたりしてプラスαの学びができました！
最後まで読んで頂き、ありがとうございました。
