それはあなたではありません。品質保証の大きな部分は欠陥の特定です

QA 業務の大部分は、欠陥の特定です。

確かに、テスト設計テクニックはテストシナリオの選択や効率化に役立ちます。しかし、欠陥の特定とは一体何なのでしょうか。また、どうすればその手間を軽減できるのでしょうか。

まずは基本から始めましょう

ローカリゼーションは探偵ごっこのようなものです。「いつ、どこで問題が発生したのか？」適切なローカリゼーションがなければ、欠陥はフロントエンド、バックエンド、および開発チーム間で取り引きされる厄介な問題になる可能性があります。時間が無駄になり、場合によってはコンテキストも無駄になります。

欠陥の特定は、アプリケーション リクエストとログを毛糸玉にして迷路を進むようなものだと考えてください。しかし、毛糸をただつまずきながら進むよりも、この迷路の地図 (大まかな地図でも可) があれば簡単ではないでしょうか。ここでアプリケーションのアーキテクチャが役に立ちます。

アプリケーションアーキテクチャとは何ですか?

それは、システムのさまざまな部分がどのように連携して機能するかということです。迷路の比喩で言えば、1 つのセクションが別のセクションとどのように接続するか、どの通路がどこに通じているかということです。

私はクライアント サーバーとバックエンドという 2 つの主要なアーキテクチャを区別しています。

• クライアント サーバー アーキテクチャは、クライアントとサーバーがどのように対話するかを示します。
• バックエンド アーキテクチャは、バックエンドがクライアント要求を処理する方法を決定します。

クライアントサーバーアーキテクチャについて

一般的に2つのタイプがあります:

• シンクライアント
• シッククライアント

タイプは、クライアントが独自に保持および処理する情報の量に影響します。これを設定する方法は他にもありますが、ここでは実際に使用した方法に固執します。

ほとんどのモバイル アプリと Web アプリはシン クライアントです。すべての情報はサーバー上に保存され、クライアント アプリケーションはデータを要求したり、処理を要求したりします。登録、ログイン、通知の購読など、これらはすべてサーバーへの呼び出しです。サーバー上の処理はすべてクライアントからは見えません。クライアントは要求に応じて、データベースから収集および処理された情報、または要求が正常に完了したことの確認を受け取ります。

シック クライアント アプリケーションでは、データベースへのデータの追加、レポートの生成、合計の計算、ドキュメントの作成など、ほとんどの処理をクライアント自身が実行します。多くの場合、ローカルにインストールされますが、常にそうであるとは限りません。シック クライアントの例には、オフライン ゲーム、AutoCAD、1C の一部のバージョンなどがあります。

さて、バックエンドのアーキテクチャを見てみましょう

一般的なアプローチは 2 つあります。

• モノリシック
• マイクロサービス

ほぼすべてのものが 1 か所で処理される場合、それはモノリスです。

処理のリクエストがシステム内の他のサービスに送信される場合は、マイクロサービス アーキテクチャを扱っている可能性があります。

モノリシック アーキテクチャでは、通常、異なるチームやサービスが同じコードベースを共有しているため、変更によって予期しない結果が生じる可能性があり、欠陥の原因を正確に特定することが困難になる可能性があります。

2 番目のケースでは、サービスが分離され、それぞれが独自のコードベースを持つため、1 つのサービスの変更が他のサービスにほとんど影響を与えません。

組織構造と責任範囲

タイトルは恐ろしく聞こえますが、誰が何を担当し、迷宮 (アプリケーション) のどの部分に誰が責任を負っているかを示しているだけです。銀行、マーケットプレイス、食品配達サービスなど、大企業を想像してください。アプリケーションが大きく複雑になるほど、作業する人数も増えます。そして、人数が増えるほど、チームに分け、それぞれが自分の開発領域を担当する必要があります。

たとえば、あるチームがプロモーションを担当し、別のチームが支払いを担当する場合があります。アプリケーションがさまざまなサービスを提供する場合、チームは電子文書管理、会計、政府調達などの個々のサービスを担当する場合があります。

すべてと全員を知る必要はありませんが、どのチームがどの領域を担当しているかを概説したドキュメントがある場合は、ブックマークしておくことをお勧めします。

すべてをまとめると

地図を手に、毛糸を用意して、迷宮に潜り込み、欠陥の原因を突き止めましょう。いくつかのシナリオを想像してみましょう。

シナリオ1

想像してください: 私たちは会話クラブの Web サイトをテストしています。

授業スケジュールを閲覧し、今後のセッションについて読んでいると、ある時点でタイプミスに気づきました。

さて、その起源をどうやって突き止めるのでしょうか? 冒険の始まりです!

devTools を開いてページを更新し、リクエストと応答を確認します。シン クライアントを使用しているため、応答の 1 つに入力ミスが見つかりました。これはバックエンドからのものでした。

ここで、ログを開いて、バックエンドのリクエストまたは応答の処理を検索します。これがマジックボールからの糸です。リクエストと応答からの任意の情報を使用してログを検索できますが、リクエスト xiid、リクエストからの ID、電話番号などの一意の値を使用することをお勧めします。

エントリを見つけて確認します。クラス情報はデータベースから取得したのか、それとも別のサービスから取得したのか?

情報がデータベースから取得された場合は、問題をテクニカル サポートに渡して、データベース内のタイプミスを修正することができます。

情報が別のサービスから来たものである場合、そのサービスに欠陥を伝えることができます。

おめでとうございます! 最初の迷宮を克服しました。欠陥が特定され、報告されました。

シナリオ2

今、登録フォームをテストしているところです。

メールアドレス、いくつかのデータ、そして架空のパスワードを入力します。登録ボタンをクリックすると、予期せずエラーが発生します。

魔法のボールを解く時が来ました! devTools のお気に入りの [ネットワーク] タブに移動して、何が問題なのかを確認します。すべての手順を繰り返し、サーバーの応答を確認します。

リクエストに対する応答として、空のレスポンス本文を含む 400 コードが返されます。フロントエンドに対して欠陥を報告すべきでしょうか? しかし、何が間違っていたのか、何を修正する必要があるのか、まだわかりません。400 エラーは、クライアントが送信したものとサーバーが期待したものとの間に矛盾がある場合によく発生します。これには、次のような多くの理由が考えられます。

• タスク内の古いドキュメント
• 文書化なしの変更
• タイプミス

クライアントのリクエストを確認しましょう

手動で作成された、または Swagger または OpenAPI で生成されたドキュメントがある場合は、それを使用して次の点を確認しましょう。

• 必要なパラメータをすべて送信しています
• パラメータ値のデータ型が正しいこと（例：intパラメータの場合は数値）

他にどのようにしてリクエストを確認できますか?

文書がない場合でも、次のことを確認できます。

• 構文の準拠（例：リクエストがJSON形式で送信される場合は、JSON構文に従う必要があります）
• パラメータ名のタイプミス（例：「mony」ではなく「mony」、「body」ではなく「doby」）
• ラテン文字の中にキリル文字が含まれている（例：キリル文字の「e」で書かれた「nameе」）

すべて順調ですか? では、答えを見つけるために迷路の旅を続ける時間です。地図を持って丸太の中へ「降りて」行きます。

ログ分析

ここでは、2 つのシナリオが考えられます。

• リクエスト処理中にエラーが記録されました
• エラーは記録されませんが、リクエストは記録されます

後者の場合、マイクロサービスの迷宮を探索し続け、リクエストが処理された場所を探す必要があります。

エラー ログが見つかると、何が間違っていたのか正確にわかります。つまり、ローカリゼーションと旅は完了です。残っているのは、欠陥レポート用に次の情報を収集することだけです。

• バックエンドリクエスト
• エラーログ
• 推奨される修正

結論

欠陥の特定は難しい場合があります。時には壁にぶつかることもあります。追跡していたログがエラーにつながらなかったり、状況がさらに混乱したりします。そのような状況では、通常、数ステップ戻るか、最初からやり直します。

迷宮を探索するには、かなりの時間がかかるかもしれません。旅は困難で、危険を伴うかもしれません。リクエストの処理が複雑になり、複数の異なるサービスにリクエストが送信されることがあります。タスクを簡素化し、迷宮の設計者、つまり開発者に連絡することが理にかなっている場合もあります。