合成データと実際のテストデータ：長所、短所、落とし穴

甘いものから始めて、テストの実践から例を挙げましょう。



オンラインストアの立ち上げを想像してください。 何も問題を引き起こすものではありません。 マーケティング担当者はプロモーション戦略を策定し、記事は専用のインターネットリソースで作成され、広告が支払われました。 経営陣は、毎週最大300件の購入を予定しています。 最初の週が経過すると、マネージャーは53件の支払いを記録します。 店舗管理は激怒しています...



プロジェクトマネージャーは、使いやすさを考えていないという理由を求めて実行します。 不適切なトラフィック？ 他に何か？ データ分析システムを理解し、研究し始めました。 247人がチェックアウトに到達し、53人だけが支払ったことが判明しました。









分析の結果、メールアドレスが原因で残りのユーザーは購入できなかったことがわかりました！

注文フォームのテストは、初心者のスペシャリストに提供されました。 彼は最善を尽くし、「名前」、「電子メール」、「電話」のフィールドに、オンラインジェネレーターを提供する可能性のあるオプションと不可能なオプションをすべて入力しました。 1週間後、すべてのバグが発見され修正されました。 リリースが行われました。 しかし、考慮されたオプションの中には、@の後の8文字未満を含む単一のメールアドレスはありませんでした。









そのため、@ mail.ru、@ ya.ru（および同様のもの）のメールの幸せな所有者は、メールを入力できず、買い物をせずにサイトを離れました。 所有者は60万ルーブル未満を受け取り、広告予算はすべて無効になり、オンラインストア自体は多くの否定的なレビューを受けました。



これは孤立したケースだと思いますか？ それから顧客のための別の恐怖物語はここにある。



キャッシュレス支払いへの一般的な関心をきっかけに、ローン会社は資金を移転する新しい方法を借り手の銀行カードに導入することにしました。 マネージャーの個人アカウントに適切なフォームを実装し、カードデータを入力するためのフィールドでさまざまなエラーオプションをテストし、修正して、作業を開始しました。 1か月後、経営陣は、すでに承認を受けた潜在的な借り手の24％が最後まで融資を申請しなかったという情報に到達しました。 なんで？ 彼らは、誓約してテストした16の代わりに18桁の数字を含む銀行カードを提供しました。システムもマネージャーもそのようなカードを登録できず、顧客は何も残しませんでした。









パイロットプロジェクトは、市内の3つのオフィスで実施されました。 3つのオフィスでの月間ローンの平均数は340でした。結果：組織は少なくとも612千ルーブルを失いました。 収益。



これらは、合成データがプロジェクトで深刻な損失を引き起こす可能性があるいくつかの例です。 多くのテスターは、モバイルアプリケーションからソフトウェアまで、さまざまなプロジェクトをテストするために合成データを入力します。 この場合、テスター自身がテスト状況を考え出し、ユーザーの行動を予測しようとします。



しかし、多くの場合、3Dメガネの映画館のように多次元ではなく、子供がアルバムシートに小さな男を描いたかのように大ざっぱに見えます。



これは、テスターがすべての可能なテスト状況をカバーしておらず、大量のデータを扱うことができないという事実につながります。 また、テストは適切に実行できますが、実際のユーザー（ほとんどの場合、非論理的で予測不可能な場合もあります）が製品との対話を開始したときにシステムが落ちないという保証はありません。

今日は、テストプロセスでどのデータを優先するかについて説明します：合成または実データ。

用語で理解します

テストを受けるたびに、使用するテストデータを決定します。 それらのソースは次のとおりです。

1. テストベンチ上の本番データベースのコピー。
2. 現在のシステムで使用できるサードパーティのクライアントシステムのデータベース。
3. テストデータジェネレーター。
4. テストデータの手動作成。

最初の2つのソースは、実際のテストデータを提供します。 それらは、ユーザーまたはシステムによる既存のプロセスによって作成されます。









たとえば、製造会社向けのWeb製品を開発するプロジェクトに参加する場合、既存の1Cデータベースのコピーをテストに使用できます。これは、数年にわたって運用および顧客に関するすべてのデータを収集および処理してきました。 完了した注文のレポートを生成および表示するモジュールを使用して、1Cから必要な形式で情報を取得し、実際のテストデータを処理します。



ポイント3および4からのソースを「合成テストデータ」と呼びます（このような用語は外国のテストで見つけることができますが、ロシア語のセグメントではほとんど使用されません）。 開発とテストの目的で、このようなデータを自分で作成します。









たとえば、44の連邦法に基づいて、州および地方自治体の組織による調達のための新しい電子取引プラットフォームから注文を受けました。 ここでは、非常に厳しい情報保護ルールが守られているため、チームは実際のデータにアクセスできません。 テストを行う唯一の方法は、テストデータのセット全体をゼロから作成することです。 テストのみを目的とした物理的なデジタル署名でも。



私たちの実践では、あるタイプのデータはめったに使用されません。通常、タスクに応じてそれらの組み合わせを使用します。



製造会社の同じシステムの制限と例外を確認するために、合成データを追加で使用しました。 彼らの助けを借りて、いずれかの注文に製品がない場合のレポートの動作を確認しました。 電子取引プラットフォームでは、合成データと実際の参考書OKPD2およびOKVED2を組み合わせました。

合成データ機能

多くの場合、合成データは単に不可欠です！ テスターの武器庫から使用できるタスクを見てみましょう。

1.簡素化と標準化

多くの場合、実際のデータは同種のデータ配列です。1セットの属性、さまざまなタイプの法的エンティティ、標準操作、および他の多くのタイプのエンティティを持つ数千人の個人がシステムに登録されているとします。 次に、それらをグループに結合して各グループの「代表者」を任命できる場合、なぜ同じ入力をテストするのに何時間も費やしますか？



昨年のプロジェクトの1つで、顧客は次のリリースの前にテスターのチームを強化することを決定しました。 製品には、多くのフィールドを持つ修正された登録フォームが含まれていました。 テストフォームを30分間レイアウトし、ほぼ同じ時間を費やしました。 並行して、7時間を費やして別のテスターがこのフォームを既にテストしていることが明らかになりました。 なんで？ 彼は、スタッフリストの12人の従業員の実際のデータに従ってテストを実行することを決定しましたが、1人の従業員のテストが登録された各プロファイルで同じ属性をすべてカバーすることを考慮しませんでした。



利益： 6時間30分。これは1回のテストのみです。

2.組み合わせ論とテストカバレッジ

多くの場合、実際のデータが大量にあるにもかかわらず、多くの場合が含まれていない場合があります。 入力データのさまざまな組み合わせでシステムの操作性を保証するには、それらを自分で生成する必要があります。



前の例に戻りましょう。 新しいリリースの登録フォームは、何らかの理由で完成しました。 顧客チームは、企業文化の規範に基づいて、ミドルネームを必須にすることを決定しました。 その結果、州のすべての外国人専門家は突然、1人の父親-イヴァン（誰かがそれを修正するまでイバノビッチを書くと言った）を持っていました。 ケースはおもしろいですが、テストでウィッシュリストまたはクライアントのパラメーターを考慮しない場合、これらの人々があなたのコスト/レビューを考慮しない場合でも気分を害することはありません。

3.自動化

自動テストでは、合成データが不可欠です。 一見些細なデータの変更でさえ、一連のテスト実行全体の動作に影響を与える可能性があります。



ここでは、銀行セクターの例を説明します。 アプリケーションが生成したドキュメントに銀行口座の数を正しく記録しているかどうかを確認するために、自動テストの作成に120人/時間を費やしました。 アカウント番号は自動テスト自体に示されていたため、データベースへのアクセスはありませんでした。 テストは優れた結果を示し、レポートの自動化から180％+ ROIを引き出す準備ができました。 しかし、1週間後、アカウント番号が変更されてデータベースが更新されました。 自動テストだけでなく、すべての自動テストが無事に終わりました。 自動テストの修正後、最終的なROIは106％に低下しました。 同じ成功により、すぐにテストを開始できました。

4.管理性の改善

合成データを使用すると、システムからどのような応答が予想されるかがわかります（最悪の場合、想定されます）。 機能が変更された場合、同じデータに対する応答がどのように変化するかを理解しています。 または、データを調整して目的の結果を得ることができます。



プロジェクトの1つで、当社のチームは顧客の取引先データベースからの実際のデータを使用してテストを開始しました。 データベースは積極的に改良されましたが、当時は非常に不注意にコンパイルされていました。 機能またはデータベースのどこにエラーがあるのか​​を理解しようとして時間を失いました。 解決策は単純で、合成データベースを構成することで、短くなりましたが、より適切で有益になりました。 この機能のテストは12人/時間で完了しました。

では、デメリットは何ですか？

合成データは全能のように見えるかもしれません。 だから、人的要因に出くわすまでです。 合成データは人が意図的に作成したものであり、これが主な欠点です。 考えられるすべてのシナリオと入力要素の組み合わせを物理的に考えることはできません（不可抗力をキャンセルした人はいません）。 そして、ここでは実際のデータの利点が残っています。

実際のデータを使用する利点

実際のデータを操作する際にどのような利点がありますか？ 私たちの経験から4つの証拠：

1.大量の情報を扱う

システムの実際の操作は、何百万もの操作を提供します。 何千人ものユーザーの同時作業を繰り返すか、専門家のチームが自動データ生成を行うことはできません。



証明：合成ミニデータベースを作成しました。このデータベースは、お客様の既存のベースのすべての基準を満たしているように思えました。 合成ベースではすべてがうまくいきましたが、実際のベースでテストを実行するとすぐにすべてが落ちました。 結論：実際のデータサンプルのニュアンスをすべて考慮できない場合でも、合成データの生成に時間を無駄にしないでください。

2.さまざまなデータ形式を使用する

テキスト、音声、ビデオ、画像、実行可能ファイル、アーカイブ-ユーザーがフォームフィールドにアップロードするものを予測することは不可能です。 受け入れられた形式に関するヒントは無視される場合があり、ダウンロードの禁止は開発チームによって実装されない場合があります。 その結果、目的のシナリオがテストされます。 たとえば、サウンドダウンロードフィールドでは、mp3ファイルをダウンロードすることが実際に可能であり、実行可能ファイルをダウンロードしてもシステムに悪影響を与えません。 実際のデータは、例外を追跡するのに役立ちます。



証明：ユーザープロファイルの写真アップロードフィールドをテストしました。 データベースから最も一般的なグラフィック形式に加えて、いくつかのビデオおよびテキストファイルを試しました。 合成コンパイルは完全にロードされました。 実際の使用では、サウンドファイルをダウンロードしようとするとエラーが発生することが判明しました。 登録フォーム全体がクラッシュし、ファイルを置き換えることができませんでした。 ページを更新しても保存されませんでした。

3.ユーザー行動の予測不能性

多くのQAスペシャリストが例外的な状況の作成と分析に成功しましたが、正直に言ってみましょう。人の行動と彼を取り巻く要因を正確に予測することはできません。 また、操作時にインターネットをオフにすることから始め、プログラムコードと内部ファイルを使用して操作を終了することができます。



証明：当社では毎年、従業員が認定を受けます。特に、特別なアンケートでスキルを評価しています。 見積もりはヘッドと合意され、それらに基づいて、スペシャリストのグレード（レベル）が計算されます。 リリース前に、モジュールは完全にテストされ、すべてが時計のように機能しました。 しかし、一度、結果を保存するときに、システムに対してddos攻撃が行われ、その結果、データの一部のみが保存され、その後の保存の試みではエラーのみが複製されました。 実際の状況がなければ、このような重大なミスを追跡できませんでした。

4.システムの更新

アップグレード中にシステムがどのように動作するか、起こりうるリスクは何か、「離陸できない」ものを理解することは非常に重要です。 膨大な数のディレクトリとリンクがある1Cなどのプログラムでは、更新の問題が特に深刻です。 そして、ここでの最良のオプションは、製品版の新しいコピーを用意し、その上で更新をテストし、その後にリリースすることです。



証拠：ケースは非常に一般的です。 ファクタリングサービスの分野でのプロジェクト。 データの損失と歪みの重大性は一線を超えており、システムによって再現されたデータの関連性が疑われると、オフィス全体が停止する可能性があります。 そして、ここでは、ビルドの最新の10バージョンをキャプチャせずに、次の更新プログラムをすぐに製品にロールアウトします。



朝の18時から11時の修正で展開されました。完成に失敗し、バージョンの理解が困難だったため、会社の部門の作業は2時間完全に凍結されました。 マネージャーは現在の契約を処理できず、新しい契約を登録できませんでした。



それ以来、私たちは必ず3つのスタンドで仕事をしています。

1. 開発。 ここで改善が行われ、例外テストと呼ばれる無政府状態と無法状態が進行しています。 QAエンジニアは主に合成データを使用しますが、実際のデータはめったに注入されません。
2. プレリリース。 すべての改善が実装およびテストされると、このブランチに進みます。 セールのあるバージョンもここで事前に公開されます。 したがって、条件付き戦闘条件での新しい機能の更新と操作をテストします。
3. 生産。 これは、エンドユーザーが作業するシステムの戦闘バージョンです。

それでは、どのデータといつ動作するのでしょうか？

作業に関する3つの洞察を実際のデータと合成データで共有します。

1.データ型の選択は、テストの目標と段階に依存することに注意してください。 そのため、新しいシステムの開発では、合成データでのみ操作できます。 また、入力条件のさまざまな組み合わせをカバーするために、ほとんどの場合、それらに注目します。 ただし、ユーザーの動作に関連するいくつかのトリッキーな例外を再現するには、実際のログが必要です。 同じことは、一般に受け入れられているディレクトリとレジストリでの作業にも当てはまります。



2.テストデータを使用して作業を最適化することを忘れないでください。 可能な場合は、ジェネレーターを使用し、メインエンティティの共通レジスターを作成し、システムバックアップを適時に保存して使用し、適切なタイミングで展開します。 そうすれば、次のプロジェクトの準備は、憂鬱や憂鬱の原因ではなく、作業の段階の1つになります。



3.合成固体の側面に行くのではなく、実際のデータに焦点を合わせないでください。 組み合わせたアプローチを使用してデータをテストし、エラーを見逃さず、時間を節約し、作業の最大の結果を表示します。



合成は素晴らしい未来を予言しているという事実と、科学者は合成データで人工知能への新たな希望を見ているにもかかわらず、合成はテストの万能薬ではありません。 これは、問題の解決に役立ち、新しい問題につながる可能性があるテストデータを生成するためのもう1つのアプローチです。 実際のデータ/合成データの長所と短所、およびそれらを適切なタイミングで適用する能力を知ることが、損失、ダウンタイム、または法的措置からあなたを保護します。 本日は、少しでも安全になるようお役に立てば幸いです。 かどうか？



議論しましょう。 合成および実際のテストデータを使用した事例についてのコメントで教えてください。 現実主義者か合成者かを見てみましょう。 ;）



ビクトリア・ソコビコバ。

品質研究所のテストアナリスト