Qt GUIテストの実践：複雑なアプリケーションをチームはどうテストしているか

Qt QMLを使う開発チームはGUIテストにどう取り組んでいるか

Qtで開発していると、アプリケーションが大きくなるにつれてGUIテストの難易度は上がっていきます。画面、状態、操作、エッジケースが増えていくためです。特に組み込み開発では、ハードウェアもテストの対象に含まれることがあります。ある機能の変更が、何年も問題なく動いていた別の機能に影響することもあります。また、アプリケーションの実際の動作ではなく固定のタイミングに依存したテストは、不安定になりがちです。

こうした問題は、Qtで本番ソフトウェアを開発するチームにとっておなじみのものです。興味深いのは、製品が一定の複雑さに達したとき、各チームがどのように解決しているかという点です。reMarkable、d&b audiotechnik、Accenture Song、TEM Innovations（Werfen）は、デジタルペーパーからプロフェッショナルオーディオ、コンサルティング、医療機器まで、業界は大きく異なりますが、開発とテストの課題には多くの共通点があります。

その経験から、Qtの開発者がGUIテストを実際に確実に機能させようとするときに抱く疑問への、いくつかの実用的な答えが得られます。

実機で動くQt UIはどうテストすればよいか

reMarkableは、書く、メモを取る、アイデアをまとめるための、デジタルペーパータブレットを開発しています。デバイスの操作体験はあえてシンプルに設計されていますが、その裏にある技術は決して単純ではありません。同社は現在、白黒のreMarkable 2と、新しいカラーディスプレイ搭載のreMarkable Paper Proという2つの異なるタブレットプラットフォームを展開しています。デバイスに加えて、デスクトップ版とモバイル版のコンパニオンアプリも開発しています。この製品エコシステム全体のインターフェースはQtで構築されており、reMarkableは同社が提供したい体験のために独自のコンポーネントも作成しています。

reMarkableのシニアテスト自動化エンジニア、Nuno氏の話を直接聞く

ここには興味深い開発上の課題があります。ソフトウェアは、利用者にとって一貫性があり分かりやすいものである必要がありながら、その下では異なるハードウェアやアプリケーションをサポートしなければなりません。そのためチームは、モジュール性と再利用性について慎重に検討する必要があります。ここでQMLが役立つのは、開発者が製品の異なる部分で同じ考え方を適用できるからです。ある製品でQMLを使ったことがあれば、まったく別のUI技術を一から学ぶことなく、モバイル版やデスクトップ版に移れます。複数の関連製品を保守するチームにとって、この親しみやすさは日々の開発をかなり楽にします。

デバイスのテストには、さらに別の難しさがあります。UIがハードウェアと密接に結びついているためです。reMarkableはSquishを使い、ユーザー操作を自動化して実機上でテストを実行しています。これにより、操作を再現し、アプリケーションの応答を検証できます。ソフトウェアの変更のたびに同じ動作を繰り返し確認する必要がある場合に、特に有効です。

また同チームは、テストの安定性を高める取り組みも行ってきました。プロパティを即座に確認し、アプリケーションが期待される状態にすでに到達していると想定するのではなく、テストが状態の発生を動的に待機するようにしたのです。この違いは、実機上で実際のソフトウェアをテストする際に重要です。実機では、操作が毎回同じミリ秒数で完了するとは限らないからです。この検証方法を見直したことで、reMarkableはテストの不安定さを大幅に減らすことができました。

組み込みQtアプリケーションを開発する人にとって、教訓は実用的です。信頼性の高いGUI自動化は、タイミングについての楽観的な前提ではなく、アプリケーションの状態に従うべきです。任意の時間だけ待ってうまくいくことを願うテストよりも、アプリケーションが準備できたタイミングを把握するテストのほうが、一般的にはるかに有用です。

Qtオブジェクトの認識はGUIテストでなぜ重要なのか

Qtアプリケーションに適したGUIテストツールを評価する場合、そのツールがQtについてどこまで理解しているかを確認する価値があります。多くのテストツールは、マウスクリックを再現したり、画面に表示されているものを操作したりできます。しかし、それがQtアプリケーション内部のオブジェクト、プロパティ、関係性を理解していることを意味するとは限りません。

d&b audiotechnikにとって、Qtとの直接的な統合が重要な理由の一つがここにあります。同社は、スタジアムやクルーズ船などの大規模な会場で使われるプロフェッショナルPAシステムを開発しています。ソフトウェアの成長に伴い、正常に動き続ける必要がある機能やUI要素も増えてきました。シニアソフトウェアエンジニアのアレクサンダー・ヴァイデマンは、Squishが Qtのオブジェクトシステムと直接連携できることを、チームにとっての重要なポイントとして挙げています。

「決め手となるのは、シームレスな統合です。UIテストツールがQtのオブジェクトシステムの内部まで踏み込めるのです。」

このような統合により、チームが自ら行う必要があるQt固有の作業は減ります。もちろん他にもテストツールはありますが、汎用ツールがフレームワークを適切に理解していない場合、開発チームの誰かがその差を埋めなければなりません。結果として、エンジニアは有用なテストを書いて実行するという本来の仕事に入る前に、Qt向けの追加対応を実装する必要が出てくることもあります。

d&b audiotechnikのシニアソフトウェアエンジニア、Alexander Weidemann氏の話を直接聞く

すでに規模の大きなアプリケーションを保守しているチームにとって、そのような追加のインフラには費用がかかります。それは開発、理解、デバッグ、そして変更のたびの保守が必要です。d&bのアプローチは、ソフトウェアのQt固有の部分をすでに理解しているツールを使うことで、チームがテストツールにアプリケーションの動作を教えるのではなく、テストすべき対象を定義することに時間を使えるようにするというものです。

手作業に頼らずにQt GUIテストを自動化できるか

テスト自動化では、もう一つの実用的な疑問が生じることがよくあります。開発者やQAエンジニアが、自分たちでどれだけのテストコードを書き、保守しなければならないのかという問題です。フレームワークが技術的に強力であっても、有用なテストを実行するまでに大量のスクリプト作成が必要であれば、導入は難しくなります。

d&bでは、Squishのレコード＆再生機能を使い、アプリケーションとの操作に基づいてエンジニアがテストスクリプトを作成しています。これにより、最初から基礎となるPythonをすべて手で書く必要が減ります。チームは、プロジェクトや対象の動作に応じて、振る舞い駆動開発（BDD）やモデルベースドテストなど、異なるアプローチを組み合わせることもできます。

ただし、録画によって優れたテスト自動化に必要な思考が不要になるわけではありません。どのワークフローが重要か、期待される結果は何か、テストをどう整理するか、そしてアプリケーションの進化に伴って有用であり続けるだけの堅牢さがあるかを、誰かが判断する必要があります。録画によってできるのは、有用なユーザーフローを特定してから、それを繰り返し実行可能なものにするまでの道のりを短縮することです。

これは、開発者とQAエンジニアの間でGUIテストを共有する場合に特に価値があります。自動化に関わる全員が、同じ方法で問題に取り組んだり、大半の時間を技術的なテストコードの作成に費やしたりする必要はありません。ツールがインタラクションの部分の多くを担い、チームは検証したい動作に集中できるのです。

新しいQtの機能が既存の機能を壊さないようにするには

Qtアプリケーションが成熟するにつれて、回帰テストの重要性はますます高まります。開発者が新機能や大きなエピックに取り組んでいるとき、その注意は自然とその作業に向かいます。何が変更されたか、どの新しい操作を確認すべきか、実装のどこが難しいかは把握しています。しかし見落としやすいのが、アプリケーションの別の場所にある古い機能であり、それらも以前と同じように動作し続ける必要があります。

d&bは、新しい機能を追加するたびに、確立された部分が引き続き正しく動くかを確認するため、Squishによる自動GUIテストを使っています。ヴァイデマンは、機能を追加しても、既存の機能が引き続き動作しなければならないという要件は変わらないと指摘しています。自動回帰テストがあれば、変更のたびにUIの全領域を開発者が手作業で確認しなくても、既存の操作を繰り返し検証できます。

これは、製品が成長するにつれてさらに価値を持ちます。過去からの機能は増え続けるため、手動の回帰テストは、リリースのたびに大きな作業になっていきます。一方、確立された自動テストスイートは、重要な動作を継続的に検証できます。開発者は手動の注意を、最も価値のある領域、特に新機能や調査が必要な変更に振り向けられます。

d&bは、GUIテストでSquishと併用して、Axivionによる静的コード解析も使っています。両ツールは、ソフトウェア品質の異なる側面を扱いながら、どちらもアプリケーションのQt固有の部分に対応します。静的解析はコードとアーキテクチャの問題を特定し、GUI自動化はユーザーの視点からアプリケーションが期待どおりに動作しているかを確認します。開発チームにとって、これは各ツールの周りにカスタムのQt統合を作ることなく、2つのレベルで有用なカバレッジを提供します。

手動によるGUIテストはどの時点でスケールしなくなるのか

手動テストが悪いわけではありません。アプリケーションが比較的小規模であれば、重要なワークフローを手でチェックするのは迅速で柔軟であり、十分に合理的です。問題が生じるのは、アプリケーションが成長を続ける一方で、チームがリリースのたびに同じ検証作業を繰り返さなければならなくなったときです。

Accenture Songのデジタルソリューションチームリーダーであるゼバスティアン・クラッツは、QtやQML、Qt Widgets、Squishを使ったクライアントプロジェクトで、この移行を経験してきました。同チームは数年にわたってこれらの技術を複数のプロジェクトで組み合わせて使ってきたため、テスト要件がソフトウェアとともに増大していく過程を間近で見てきました。

「手動テストだけの世界から来ると、自動化を始めることは本当に目から鱗です。プロジェクトがある規模に達したときの複雑さに対応するには、それしか方法がないのです。」

プロジェクトの規模に関するこの指摘は重要です。チームは管理しやすい数の手動テストから始めるかもしれませんが、機能を追加するたびに、後で再確認が必要になる動作が増えていきます。やがて、考えられる操作や回帰シナリオの数は、手作業で一貫してカバーするには多すぎるようになります。その時点でチームは、繰り返しの検証により多くの時間を使うか、アプリケーションのうち確認されない部分が増えることを受け入れるかという、厄介な選択を迫られます。

ガイド：自動テスト戦略をスケールさせる方法を学ぶ

5ステップのハンドブックを入手

自動化は、繰り返し行う確認を別の場所に任せられるようにすることで、この状況を変えます。重要なワークフローが一度確実に自動化されれば、人が毎回すべての操作を手で再現しなくても、そのテストを再実行できます。開発者やQAエンジニアは、その時間を探索的テスト、例外的なケース、新機能、そして人間の判断が本当に役立つ問題に使えます。

Accenture SongのデジタルソリューションチームリーダーであるSebastian Kratz氏の話を直接聞く

ゼバスティアンにとって、自動化に向かうことは、QAに対する見方も変えました。テストはもはや、開発者が作ったものを手作業で検証するだけのものではなくなりました。自動化によって、テスト戦略、統合、結果、そしてプロジェクト全体で品質情報をどう活用するかを決める、より広い役割が生まれたのです。

自動GUIテストは既存の開発ワークフローにどう組み込むか

GUIテストスイートは、その周りにある開発プロセスに自然に組み込まれたときに、より有用になります。テストを別の環境で実行し、ときどき結果を確認するだけでも一定の価値はありますが、潜在的な利点の多くは活かされません。チームは通常、開発、統合、レポート、品質保証のために既に使っているシステムとテストが連携することを必要とします。

ゼバスティアンは、Accenture SongのSquishでの取り組みについて、この点を強調しています。彼のチームは、テスト環境を既存のITエコシステムに統合し、結果を追跡し、テストデータを他のツールと連携させることができます。つまり、GUI自動化の出力がテストツールの中だけに閉じている必要はありません。プロジェクトの状態を把握するためにチームが使う、より広い情報の流れの一部になれるのです。

Qtチームが GUI自動化を評価しているなら、これは早い段階で検討する価値があります。当面の問いは、ツールがQMLコントロールを操作できるか、プロパティを検証できるかかもしれません。しかし長期的な問いは、数百、数千ものテストが存在するようになった後に何が起きるかです。開発者は何かが失敗したときにそれを知る必要があります。QAチームは傾向と結果を理解する必要があります。テストシステムは、プロジェクトや周辺のツールチェーンが変化しても有用であり続ける必要があります。

自動GUIテストを既存のエンジニアリングの実践に統合しやすいほど、それは別個のプロセスになり、チームのごく一部しか理解していないものになりにくくなります。

新しいエンジニアをQt GUI自動化に参加させるのはどれほど難しいか

テスト自動化の保守しやすさは、技術だけでなく人にも左右されます。現時点で問題なく動くテストスイートがあっても、いずれ誰かが新しいテストを追加したり、失敗を調べたり、既存のテストがなぜそのように設計されたのかを理解したりする必要が出てきます。ツールの習得に何か月もかかったり、特定の一人のエンジニアの知識に大きく依存したりするなら、チームは新たなボトルネックを作ったことになります。

TEM Innovations GmbH（Werfen）は、特に止血関連の製品を含む医療機器のGUIテストを自動化する中で、この問題に取り組んできました。同社は約4年間Squishを使っており、テスト結果の管理にはTest Centerも使っています。クリスチャン・ネンネマンは、他のいくつかのテストソリューションを使ってきた後にこのツールに移り、比較的早く業務を進められるようになったと述べています。

この経験は、新しいテスト自動化エンジニアがチームに加わるときに重要になります。クリスチャンによると、新メンバーは、基本的な自動化を機能させるために長い期間を費やすのではなく、すぐに作業を始められるとのことです。同時に、このツールはBDDやモデルベースドテストなどのアプローチもサポートしており、テストのニーズが変わってもチームに柔軟性を与えます。

GUIテストツールを比較するとき、機能一覧の比較は簡単なので、導入のしやすさは見落とされがちです。実際には、テストを保守するのに必要な専門知識の量が、その体制の持続可能性に直接影響します。複数の人が自動化を理解して拡張できれば、テストスイートが「誰も触りたくないもの」になってしまう可能性は大幅に下がります。

TEM Innovations GmbHのChristian Nennemann氏の話を直接聞く

Qt GUI自動化で実際にどれだけの時間を節約できるか

TEM Innovationsは、わかりやすい例を示しています。同社のGUIテストはもともと手作業で行われていました。繰り返し行うテストのたびに、誰かが操作を実行し、結果を確認しなければなりませんでした。テストを自動化したことで、チームはその作業を、夜間実行を含め定期的に動く安定したスイートに移すことができました。

クリスチャンは、その影響を次のように明確に説明しています。

「Squishは私たちにとって本当に大きな時間の節約になります。テストを自動化したら、あとは勝手に動くんです。」

これは、テストに二度と手を入れる必要がないという意味ではありません。アプリケーションが変われば、自動テストも変更が必要になることがあります。保守は常に発生しますし、設計の悪いテストは、有用なカバレッジよりも多くの保守作業を生むこともあります。違いは、再利用可能な自動チェックを保守することと、毎晩またはリリースのたびに同じ手順を人に繰り返させることは、まったく別物だという点にあります。

そこで時間の節約が意味を持ちます。1つの自動テストだけでは、大きな違いは生まれないかもしれません。しかし、確立された数十、数百のワークフローを繰り返しビルドで実行できる安定したスイートは、まったく異なる価値を持ちます。一貫した回帰カバレッジを提供しながら、それを得るために必要な反復的な手作業を減らしてくれるのです。

TEM Innovationsにとって、これは安定したテストの土台を生み出しました。チームは、その土台を動かし続けながら、手作業の労力を他の領域に集中させることができます。

Qt GUIテストを導入する際に確認すべきこと

顧客の事例はそれぞれ詳細が異なりますが、QtプロジェクトのGUIテストを評価するための有用な視点を示しています。長いテスト機能のチェックリストからではなく、開発者とテスト担当者が実際に抱えている問題から出発してください。

• 組み込みハードウェアを扱うなら、自動テストがリリースする実機で動くか、非同期な状態変化を適切に扱えるかを確認してください。
• アプリケーションに大規模なQMLやQt Widgetsのインターフェースがあるなら、テストツールが基盤となるQtオブジェクトを理解するか、それともチーム自身が統合を実装する必要があるかを確認してください。
• 製品がすでに成熟しているなら、新機能が追加されるたびに、どれだけの既存機能を確認する必要があるかを考えてください。

最初のいくつかのテストだけでなく、その先も見据える価値があります。1年後に誰がそのスイートを保守するのか、別のエンジニアがどれくらい早く理解できるのか、結果はどこに集約されるのか、自動化がチームの既存の開発システムに適合するのかを考えてください。数十本のスクリプトではうまく機能しても、数百本になると管理が難しくなるテストのやり方は、長期的な問題を解決していません。

4つのチームの経験は、この全体像の異なる側面を示しています。

• reMarkableは、実機上でQt GUIの自動テストを実行しており、アプリケーションの状態を動的に待機することで信頼性を高めました。
• d&b audiotechnikは、Qtオブジェクトシステムへの直接アクセスを使い、不要なカスタム統合を避けながら、製品の成長に合わせて既存の機能を継続的に検証しています。
• Accenture Songは、自動化を使ってプロジェクトの複雑さに大規模に対応し、テストを既存のITエコシステムと連携させています。
• TEM Innovationsは、繰り返しのGUI検証を手作業の実行から切り離し、毎晩実行できる安定したスイートに移しました。

Qtで開発していて、どこから始めればよいか迷っているなら、チームが最も頻繁に繰り返していることを確認してみてください。リリースのたびに同じユーザーフローを確認していないか、手作業で同じ回帰パスを何度もクリックしていないか、新しいものを追加するたびに同じ古い機能を再検証していないか。こうしたものは、通常、始めるのに適した場所です。目的は、操作を自動化すること自体ではありません。信頼性のある検証を繰り返し可能にし、開発者とテスト担当者が、製品の中で本当に注意を必要とする部分により多くの時間を使えるようにすることです。