自動化されたQAシステム：Star Crusadeを例として使用するテスター向けの頭痛薬

QAアーキテクトVladimir Savelyevとのインタビューでは、関連するITトピックに関する一連の出版物を続けています。 ウラジミールはテスターの主な頭痛について話し、それらを解決する効果的な方法を共有します。







誰が誰ですか：

自動QAシステムは、単一の構造、単一のモデルを備え、この単一のモデルを使用したテストの自動化を可能にするテスト設計プラットフォームです。 このプラットフォームは、ウォーターフォールプロジェクトでの自動テストの簡単なテスト、アジャイルプロジェクトでの包括的な品質管理、および継続的な統合開発やその他の手法を使用するプロジェクトに適しています。



Star Crusade-多数のカード（320枚以上）を備えた収集可能なカードゲーム。ゲームには、複雑なサーバーパーツと、多数のグラフィックエフェクト、アニメーショングラフィック、さまざまな機能（チャット、友人との決闘）を備えたクライアントアプリケーションがあります。



この製品には多くのWebインターフェースがあります。

-製品開発およびサポートチームが使用するサーバーWebインターフェイス

-エンドユーザーに表示され、ゲームアセンブリをダウンロードできるゲームサイト。 現在、アルファビルドが利用可能です。



テストの問題は何ですか？ それらをリストできますか？



VS：私の経験に基づいて、テストにおけるいくつかの主要な問題を強調できます。



問題1：非構造化テストに起因するバグ。

テスターが論理的に一貫性がなく、構造化されていない一連のテストを実行する場合、そのようなテストは製品全体をカバーしない可能性があるため、より多くのバグを見つけるたびに、どの開発者とテスターが互いに多くのコミュニケーションをとる必要があるかを修正します。 そのような通信の過剰は、時間の損失と製品の品質の低下につながります。



問題2：バグを効果的に分析するためのツールがないか、これらのツールを100％使用できない。 事実は、バグの分析は口頭での説明だけに限定されないことです（たとえば、一部のボタンが機能しない、ゲーム内のアクションが正しく実行されないなど）。 開発者がバグとは何かを理解して修正するために、テスト担当者は見つかったバグに関する一定量の情報を収集する必要があります。



典型的な例は、テスト中のアプリケーションのログ（レポート）です。画面のスクリーンショット、いくつかの拡張テーブル（データベースからの選択）が含まれます。 複雑なプロジェクトでは、すべての情報を一緒に収集することは難しく、時間がかかりすぎます。 そのため、検出された欠陥に関する情報を迅速かつ効率的に収集できるツールが必要です。 このようなツールのこの欠点は、テスターに​​とっての別の頭痛の種であり、その結果、開発者にとっての頭痛の種です。



問題3：継続的な日常業務。 誰もが知っているように、ITプロジェクトを実装する場合、開発者はほぼ毎日機能を追加および最適化し、見つかったバグを修正します。 したがって、アプリケーションは毎回再テストして、新しい機能の機能をチェックし、回帰バグを検索する必要があります。 そうしないと、以前に機能していたコードが変更後に機能し続けることを保証できなくなります。 テスターは毎日テストをすべて実行する必要がありますが、そのたびに増加するだけです。



それとは別に、 回帰バグをサブクラス化したいと思います。 開発中の製品が定期的にテストされていないか、構造化されていない状態でテストされている場合、大量の回帰バグが発生します。 時間が経つにつれて、そのようなバグは雪だるまのように蓄積し、さらなる製品開発を単に不可能にします。



開発とテストのプロセスを簡素化するために、これらの問題をすべて解決するにはどうすればよいですか？



VS：まず、コミュニケーションの問題を解決する必要があります。 すべてのチームメンバー（テストと開発の両方）は、担当するコンポーネントを完全に理解するだけでなく、製品が複雑に開発されていることを確認し、製品の他のすべてのコンポーネントについて最小限の知識しか持たない必要があります。 次のようなツールを含む品質管理の開発。

• 品質管理のグラフィカルモデル
• テストカバレッジマップ
• 明確に構成されたテスト

これらのツールは、さまざまなプロジェクトでの作業の過程で作成されたものであり、アジャイル開発と同じ方法でプロジェクトテストの高品質なグラフィカルツリーのようなモデルを構築できます。 プロジェクトはエピックに分割され、エピックはユーザーストーリーと特定の開発およびテストタスクに分割されます。 このモデルは、アジャイルプロジェクトの開発構造に有機的に適合し、ウォーターフォールプロジェクトのテストの構造化と整理に役立ちます。



一見すると、ツールは特別なものではありません。 これは、製品モデルを示す図であり、テストを表示するためのツリーのようなモデルです。 これらは「明らかなもの」であるというレビューを繰り返し聞いています。 ただし、完成した結果を見て、話すのは簡単です。 プロジェクトに取り組むという現実は、これらのことはそれほど明白ではないことを示しています。



品質管理のグラフィカルモデルでは、製品はテスターが確認する必要がある形式で表示されます。 たとえば、トップレベルでは、Tomcatで製品コードが実行されていて、MySQLとLDAPとの通信にどのライブラリが使用されているかは重要ではありません。 製品がユーザー操作を実行できることを確認することが重要です：認証（データベースへのアクセスとクライアントとのデータ交換を含む）、メッセージ交換（2つのXMPPクライアント間の相互作用）など。 ただし、1レベル下に移動してモデルを改良したり、モデルを複数のスライド/画面に分割したりして、コンポーネントの内部構造をさらに表示することを妨げるものはありません。



この品質管理モデルは、製品のデバイスに関する情報だけでなく、プロジェクトのドキュメント、単体テストに関する情報、さまざまなナレッジベース記事などを収集するインタラクティブなツールにすることができます。 結局のところ、特定のテスト/開発タスクを解決するには、スペシャリストはすべてのプロジェクトドキュメントを必要とせず、現在作業している製品のその部分に関する情報が必要です。



したがって、チームが製品について同じ考えを持ち、チームのメンバーが必要な情報をすばやく取得できることを保証します。 チームはすべての新しい従業員にゼロからすべてを説明する時間を無駄にしないでください。また、従業員は現在のタスクを解決するために30％しか必要としないドキュメントの束を読むことに時間を費やすべきではありません。





品質管理グラフィックモデル



同様に、テストカバレッジカードの状況。 論理的に品質管理のモデルを継続し、機能の開発が行われている形式のテストで製品をカバーできるようにします。 いくつかの機能を完成させるか、または作り直すことを決定した場合、理解できるツリーモデルの形式で表示されるため、テストカバレッジをすばやく更新できます。



どれだけ余分な時間がかかったかについて多くの議論がありました。 たとえば、ここで示すテストカバレッジマップの作成には約15分かかりました。





テストのリストで表されるテストカバレッジ





ツリーモデルを使用したテストカバレッジ（テストカバレッジマップ）



開発したツールの実装結果について詳しく教えてください。



VS：実例：約70のテストが行​​われた経験豊富なテストの同僚が作成したコンポーネントの1つのテストカバレッジを取得し、テストカバレッジマップに示されているようにそれを破りました。 約15の失敗したテストが見つかり、すべての作業に約30分かかりました。



時間が経つにつれて、各製品は類似したモデルとして認識され始め、製品テストに関連するアクティビティは構造化され、一貫したものになります。 これは特に初心者に当てはまります。 どのようにテストを書き始めたかを覚えていますが、テストにアプローチする側、製品をテストでカバーして何も見逃さないようにする方法を理解できませんでした。 そのようなツールがあれば、正社員としてずっと早く仕事を始められるでしょう。



また、実験も実施しました。 彼らは、このカードの構造化されていない部分的に時代遅れのテストカバレッジと例を初心者に提供しました。 例、テストカバレッジ図、およびキャンペーンへの質問を手元に置いて、テストの経験がない人でも2日以内に良好なテストカバレッジを作成できます。 彼は1か月以内に本格的なテストエンジニアのレベルに達しました。 1か月後、彼はすでにチームと完全に連携していましたが、複雑なテレコムシステムのテストについてでした。



モデル+マップのバンドルを使用する別の例は、テクニカルライターとのコミュニケーションの経験です。 ほぼ完成した製品のユーザードキュメントを書き始めたとき、彼はまず、この製品が構造化された方法で文書化するためにどのように機能するかを理解することに決めました。 私は彼にモデルと地図を提供し、コメントもしました。 彼は必要な製品の一部のデバイスを即座に理解しました。 彼はこのモデルが非常に気に入ったため、公式の製品ドキュメントに含めました。



つまり、当社の経験を活用することで、お客様のプロジェクトをすばやく掘り下げ、お客様のスペシャリストが私たちと一緒に仕事をするシステムに迅速に適応することができます。



しかし、バグをテストおよび分析するためのツールの欠如についてはどうでしょうか？



VS：すべてのテスターが知っているように、バグを分析するためのツールはたくさんあります。 それらのいくつかはより良く、いくつかはより悪いですが、一般に、一度に複数のツールを包括的に使用する能力によってのみ良い結果を達成することができます。



使用可能なツールでは、直面しているタスクを解決できない場合は、自分で作成します。



例として、テスト中にテスト中のアプリケーションのログを分析するための手法を提供できます。 ログは、テスターがバグを発見したときにアプリケーションで発生したことに関する情報の主な情報源です。



作成したツールを使用すると、必要なすべてのコンポーネントのログを効果的に収集し、開発者に明確なクリッピングを提供することができます。これにより、欠陥を特定できます。 エンジニアは、全体像を一度に見ることができ、部分的に収集することはできません。



私たちの経験の中で最も低いレベルは、テストの自動化です。 品質管理の包括的なモデル、テストカバレッジマップ、および自動テストで作成したツールを配置します。 したがって、日常業務の問題と回帰バグが同時に解決されます。



自動テストの3つの基本段階を特定しました。

• テストのための環境の準備
• 検査
• 変更を破棄

最初の段階で、アプリケーションを起動し、特定の設定を行い、機能部分の実行を準備します。 たとえば、ゲームメニューをテストしている場合、アプリケーションを起動し、このメニューを開いて、引き続きテスト操作を実行する必要があります。



2番目の段階は、テスト操作自体です。これらのアクションは、テストしている機能が正しく機能しているかどうかを理解するのに役立ちます。



3番目の段階は、自動テストにとって特に重要です。 これは行われた変更のキャンセルです。 を含む各テスト 自動で、テスト環境でいくつかのテスト操作を実行し、作業の完了後も変更せずに残さなければなりません。 品質テストの重要な要件は、変更されていない環境で、ユーザーが行うような手順でテスト操作を実行することであるためです。



したがって、テスティングの分野での基礎は、テスターのリストされているすべての問題を解決します。



システムについてもう少し話しましょう。 自動QAシステムのその他の利点を強調できますか？



VS： ITプロフェッショナルにとっての利点は、 包括的な品質管理モデルです 。これにより、プロジェクトのコミュニケーションを体系化および構築でき、テストおよび開発プロセスが最適化されます。



私の観点からは、 コンストラクタープラットフォームにも関心があります。 Linuxに精通している人々にはよく理解されています。 ご存知のように、Linuxは小さなツールの大きな複合体であり、それぞれが個別の機能を実行しますが、これらのツールを一緒に使用すると、はるかに大きなタスクを解決できます。 この原則を使用して、 自動化QAシステムと呼ばれるコンストラクタープラットフォームを構築しました。



自動テストは、 大規模なテストタスクに使用されます。 例として、カードをチェックするための簡単なスクリプトから始まるStar Crusadeプロジェクトの機能的な自動テストを紹介します。これは新しいツールで補完され、現在では製品全体（クライアントとサーバーの両方）をテストするためのツールです。 Star Crusadeには多くのカードがあり、それらのパラメーターはバランスが取れているために絶えず変化しているため、一定の製品テストが必要になります。



プロジェクトのテストを開発する際、2つのオプションから選択しました。

1）特定のカードの変更を独立して処理できる安定した自動テスト

2）手動で変更する必要があるが、作成と更新も簡単なテスト。



その結果、2番目のオプションを決定しました。 自動テストを使用し、クライアントを介してゲームシナリオを観察することで、テスターは常にこの環境に没頭しています。 彼は試して、実験し、新しい領域、非標準のバグを見つけ始め、自動テストでこれらすべてのシナリオをすばやく修正できます。

これは、テスターが、ローカルの問題を解決するためだけでなく、製品全体の品質を監視するための診断ツールとして自動テストを使用するという事実によってさらに強調されます。



専門家にとっては、自動QAシステムに実装されたタスク管理メカニズムも大きな利点になります。 大規模なプロジェクトをテストするには、最初に製品の新しいビルドをダウンロードし、テスト環境に展開し、いくつかの特定の設定を実行する必要があるたびに、自動テストを直接実行できます。 タスク管理メカニズムにより、そのようなタスクを効果的に作成し、自動化し、テスターに​​必要な順序で実行できます。



また、マクロモジュールで自動化を使用します -通常のモジュールよりもグローバルなタスクを実行するテストモジュール。



比較のために、特定の数のタスクを実行するプログラミングの通常のオブジェクトを提供します。 この場合のマクロモジュールは、複雑なタスクを実行するテストの一部になります。 たとえば、Webインターフェイスまたはサーバー側の機能を使用して特定の製品設定を行います。



自動QAシステムの利点は、 ハイブリッド自動化の可能性です 。 マクロモジュールを使用すると、まったく異なる環境で操作を実行するハイブリッドテストを作成できます（製品のグラフィック部分の管理、Windowsワークステーション、Unixサーバー、モバイルデバイス、またはWebインターフェイスでの操作の実行）。 これらのすべての操作は、1つのテストのフレームワーク内で使用でき、マクロモジュール間の情報交換を整理し、そのようなテストのパフォーマンスに関する結果を一元化できます。



システムは顧客にどのような利点を提供しますか？



VS：最初に、ソフトウェア品質管理のためのパッケージサービスを提供します 。 これは、クライアントのプロジェクトに包括的な品質管理を提供することを意味します。 10年以上にわたるテストチームの経験がモデルに組み込まれています。 これはかなり長い期間で、プラクティス、アプローチを開発し、多数のボトルネックを特定し、得られた経験を体系化して統合し、説明した品質管理モデルに到達しました。 包括的な品質管理によってのみ、最高のプロジェクト品質を達成できます。



第二に、自動化されたテストシステムと手動テストモデル（テストカバレッジマップとグラフィカルな品質管理モデルを含む）と構造化テストにより、結果を迅速に顧客に提供できます 。 これは、私たちが書いて実施するテストは、最初は構造化されたツリーモデルを表しており、手動および自動で簡単にレポートを作成して顧客に提供することを意味します。 私たちの自動化された終了テストは、人々にとって比較的理解しやすい形式で結果を提供します。 ほとんどのテストの結果、マネージャーは独立して評価できます。 専門家だけが理解できる大量の技術データは含まれていません。



第三に、自動テストの場合、自動製品テストパッケージの実行をオンラインで監視することができます 。 これを行うために、顧客アクセスを提供できるWebインターフェースを実装しました。 顧客は、さまざまなメトリックを追跡することもできます。いわゆるダイナミクスを持つグラフです。 合格率-テストが正常に完了した割合、自動テストを追加するダイナミクス、およびその他の多くの傾向 必要なグラフを追加して、これらのグラフに関する情報のコレクションを整理できます。





合格テストのダイナミクス（合格率の傾向）



これは、システムが拡張可能で更新可能であることを意味します。



したがって、顧客はプロジェクト全体の包括的なテストを受け、オフラインとオンラインの両方で実施さ​​れたテストに関する詳細なレポートを受け取る機会を得ます。

また、お客様のチームと協力する機会を提供します。これにより、経験を共有することができます。



自動QAシステムを使用した実用的な例を教えてください。



VS：自動化の経験は、主要な機能がLinuxサーバーで機能し、ユーザーとの対話がWebインターフェースを介して実行される複雑なテレコムシステムのテストから始まりました。 私たちの経験のほとんどは、同様のプロジェクトで収集されました。



現時点では、主力プロジェクトであるStar Crusadeに上記のモデルを積極的に適用しています。 自動機能テストを使用して、製品のサーバー側をテストします。 自動テストコマンドによってサーバー上で特定の操作を実行する管理ボットの助けを借りて、サーバー部分をテストします。



特別なオブザーバーモード（ゲームでもある機能）を介して実行される自動テストを監視することにより、クライアントパーツのプレイフィールドでアクションをテストします。 製品のインターフェースが「ホームストレッチ」に達したら、エンドユーザーと同じようにテストがクライアントで操作を実行するときに、グラフィカルビジョンテクノロジーを使用した自動テストで修正します。 テストの観点から、これは理想的です。マウスまたはキーボードドライバーからコマンドを受け取ると、アプリケーションはユーザーが制御するのと同じインターフェイスによって制御されるためです。



また、Seleniumを使用してWebサービス（Webサイト、サーバーWebインターフェイス）をテストします。また、Seleniumの自動化を簡素化し、より効率的にする開発も行っています。 したがって、すべての機能テストがテストパッケージに結合されます。



テストの2番目のレベルは、システムテストです。 システムテストは、明確なハイブリッドテストです。 1つのテスト内で複数のツールを管理します。 ここでは、マクロモジュールの同じコンストラクターを使用します。 たとえば、1つのテストの一環として、LinuxコンソールとWebインターフェイスを使用してサーバーで特定の設定を行い、制御されたボットを使用して必要なメカニズムを確認し、グラフィカルビジョンを使用してテストを完了します。 ここで重要なのは、自動テストをすばやく変更できることです。



たとえば、ユーザーがサイトに登録し、電子メールアカウントを確認し、そのアカウントでゲームに参加して、ゲームの一部をプレイする能力をテストします。 これはさまざまな方法で実行できます。 明示的な形式のWebインターフェイスを使用してサイトに登録するか、低レベルでサーバーにリクエストを送信できます。 実行の結果は同じになります。 しかし、最初のケースでは、サイトとそのWebインターフェイスもテストし、2番目のケースでは、サイトのWebインターフェイスに集中することなく、必要な操作を簡単に実行します。



マネージドボットを使用して、ゲーム内でゲームをプレイします。 この場合、製品のサーバー部分をより広範囲に迅速かつ確実にテストします。 グラフィカルビジョンを使用してクライアントを介して製品をテストすることもでき、クライアント部分もチェックします。 作成された自動テストでは、さまざまな機能要素を切り替えることができます。 たとえば、Webインターフェイスを介して製品設定を使用して初めてテストし、マネージドボットを使用してテストを実行し、結果の集中出力を取得します。 また、製品のグラフィック部分に集中し、サーバーへの直接要求により製品を構成し、クライアントアプリケーションを介してゲームをプレイします。



モジュール間の切り替えは、自動テストで1つまたは2つのオプションを変更することにより行われます。 自動テストは、テスターが使用する他のツールを完全に補完します。



Automated QA System :

1. ,

2.

3.

4.

5.



Automated QA System . ?



..: Automated QA System:

match-3. Lil Quest , Muffin Quest - – , . . , , .



– . , -. , .

. , .



, - , . . , -, , , , . , StarCrusade .



, : , . , - .



. , .. . , , .



, , . , .



.



!