しばらくの間、Yandex.Moneyでは、すべての製品が多くのマイクロサービスで構成されており、1日に最大12個の更新がリリースされます。 さらに、支払いサービス全体の強度-ピーク負荷にどれだけ耐えられるか、安全マージンがあるかどうかを定期的に確認する必要があります。

だからこそ、私たちには最も多数のソフトウェアテスト部門があります。 テスターの中で最も機能的な専門家。 この記事では、これらの人が何をするのか、彼らが仕事でどのツールを使用するのかを例を挙げて説明します。

この部門には、モバイルおよび統合テストだけでなく、パフォーマンスのスペシャリストがまだいますが、それらについてはまた別の機会です。

機能テストグループは、四半期中に製品チーム全体が作業するサービスの保守性をチェックします。 主に手動チェック-頻繁に繰り返されるシナリオの自動テストがここに書き込まれます。 さらに、「機能」は、複雑で理解できない場合に技術サポートの義務を果たします。

より重要なこと：開発ライフサイクルまたはインターネットの仕組みを知ること

専門サイトの何百もの空席を見ると、テスターは開発方法論、いくつかのプログラミング言語を熟知し、スペースシャトルを管理する初期スキルを持っている必要があると思うかもしれません。 私たちのパラダイムでは、テスターがITアルファベットを知っており、それから意味のある「単語」を作成する方法を知っていることを期待するのが習慣です。

このアルファベットは、マスロウピラミッドの基礎とみなすことができます。これがなければ、インターネットの仕組みを真に理解することはできません。

上から「テスト計画」を割り当てることは一般的ではなく、タスク割り当て専用のテストリードもありません。 各テスターは、今やるべきことを自分で理解する必要があるため、個人的な責任のレベルは非常に高くなります。 もちろん、会社の主要なコンポーネントの仕事についての共通の理解はここで大いに役立ちますが、最初はプロジェクトマネージャーとの理解できない状況で優先順位を明確にする必要がまだあります。

したがって、新規参入者は、最初の6か月間、同僚がくしゃみごとにチーム、分析部門にテストを依頼するという事実に同意する必要があります。

この無力感の不器用さは、特定のチームでしっかりと「調理」された場合にのみ除去できます。 これにより、すべてのエラーシナリオを完全にチェックすることで、数時間から数日節約できます。 簡単な例：ユーザーはATMからお金を引き出しますが、現金の代わりに「何かがうまくいきませんでした」と受け取ります。

問題を理解するために初心者を提案する場合、彼は頭に浮かんだすべての支払いシナリオとすべての可能な結果を​​チェックすることから始めます。 この人物がZenの内部構造と関連するすべてのコンポーネントの相互接続について既に学習している場合、彼はお金を引き出す特定のプロセスと3〜5個の参加コンポーネントに集中することができます。

最初の1か月では、初心者がアプリケーションのアーキテクチャ、REST API、JSONについて詳しく学習します。 Linuxに近づき、SQLクエリ言語と柔軟な開発方法論、自動テストに精通します。 また、JavaとKotlinの基本を学びます。後者は、より簡潔でコンパクトな最終コードのおかげで、セルフテストに便利だと思われました。

ところで、自動テストは私たち全員によって書かれています-テスターに​​とってプログラミングが別の惑星からのもののようであれば、彼はまだフレームワークから正しい順序でメソッドを投げることができます。 そして、時間が経つにつれて、アルゴリズムと言語の知識が向上します。

フロントエンドまたはバックエンドに飛び込む

「テストとは、サイト上のすべてのボタンをクリックすることです。UIをすばやくクリックして、いつでも要求に応えることができます」というアプローチは初心者のテスターの間で非常に人気がありますが、これは常に求人検索とさらなるキャリアパスを単純化するとは限りません。 たとえば、ほとんどのYandex.Moneyサービスはフロントエンドとバックエンドのパーツで構成されており、テスターをこれらのカテゴリに分割することはできません。

テクノロジーテスターをグループ化する代わりに、それらを製品開発チームに割り当てます。そこで、フォーカスを前面または背面に移動できます。 しかし、いずれにせよ、これらのコンポーネントは重複することが多く、両方で機能できる必要があります。

たとえば、コンタクトセンター用の内部ツール-すべてのユーザーコールに関する情報を備えたWebサービスがあります。 次のプロジェクトで、ツールは新しい概要ページを受け取りました。これにより、チケットステータスとSLAコンプライアンスの追跡が簡素化されます。

新しいバージョンでは、次を実行する必要がありました。

• 古いバージョンにあったすべてをサポートしていることを確認してください。
• User Storyプロジェクト用に開発されたコンプライアンスを監視します。
  
  例：監視する従業員が監視ページにアクセスし、キューの色を確認します。 赤いものがあれば、マークし、「オペレーターを割り当てる」をクリックし、専門家の一般的なリストから、システムはすべての適切で無料なものを自動的に選択します。

すべてのプロジェクトは、実装後にテスターがプロセスに接続される技術的なソリューションから始まります。

通常、すべては、アナリスト、開発者、プロジェクトマネージャーによって準備された技術的ソリューションから始まります。 この決定により、どのコンポーネントが関係するか、どのコンポーネントに処理を行うか、およびバックエンドとフロントで追加または変更する必要があるエンティティの種類が確実に示されます。



プロジェクト計画では、ソリューションは開発者のタスクに分解され、リリース時にテストすることができます。 そのような瞬間、テスターの日は次のようになります。



1.午前中に、現在のスプリントからその日のタスクのリストを自分で作成します。 これは、バグなどの緊急事態が優先されるJiraのかんばんボードを使用して行われます。 残りの優先順位は、プロジェクトマネージャーによって割り当てられます。 ここでの主なことは、リスト内を移動し、リストを再描画しないことです。



2.実装されたタスクのコンポーネントをチェックします。通常はバックエンドから開始します。これは、以前に開発に起動され、いずれにしてもバックエンドなしではフロントが表示されないためです。



3.何かを確認するには、このすべてがアイデアでどのように機能するかを知る必要があります。 したがって、テストする各メソッドには説明（入力とは何か、出力とは何かなど）が必要です。 しかし、通常は十分な情報がなく（開発者にとっては明らかであり、他の人にとっては常に明確ではない）、この場合、 Swaggerと応答の良い同僚が大いに役立ちます。 他の人の利益のために、そして歴史のために、獲得した知識を技術的ソリューションに追加することは有用です。

インフラストラクチャで広く使用されているREST APIがあるため、頻繁にテストされるシナリオは、Postmanを介して送信されるHTTP要求です。

ツールといえば、私たちの日常業務では、テスターは次のセットを使用します。

• PostmanまたはcURL-HTTP要求を送信します。
• SoapUI。
• ログを表示し、コンポーネント（特にgrep）をインストールするためのLinuxコマンドラインは、情報を選別するのに最適です。 ちなみに、キャリアの初めには、かなり基本的なスキルで十分です。
• Oracle DBおよびPostgreSQLクライアント-データベース内のデータの表示および管理用。
• 「戦闘」とテストログの両方を表示するためのKibana。
• 最後に、IntelliJ IDEAユニバーサルツールは、自動テストの作成や手動テストに最適です。一部の同僚は、Postmanを使用する代わりに、テストプロトタイプをすぐにデプロイしてAPIをテストすることを好みます。

特定のツールの選択は、テスターの個人的な好みとターゲットホスト上のツールの可用性に依存します。

ときどき、テスト対象のアプリケーションの構成を深く掘り下げてデバッグモードに切り替える必要があります。 主なことは、必要な情報がすべて収集されたらすぐに、このモードのフラグを削除することを忘れないことです。これにより、ディスク領域の過度の使用によってアプリケーションが誤って停止することはありません。

通常、バックエンド部分のテストでは、必要な入力データを含む要求を送信し、応答を受信し、結果がドキュメントと一致していることを確認します。 この単純なチェーンは、たとえば、データベース内のPOSTリクエストの結果の記録をチェックする必要性についてつまずくことがよくあります。 このための最も簡単な方法は、DBMSエージェントを介してデータベースに手動で入力し、データが正しいことを確認することです。

したがって、データベース（PostgreSQLなど）を使用してサーバーにローカルでログオンするか、 pgadminを使用して要求を実行し、目的のデータを選択する必要があります。 すべてがpgadmin GUIで実行できるため、SQL言語を知る必要はありません。 ただし、SQLクエリの非常に基本的な構造（SELECT *、WHERE、ORDER BY）を知ることは依然として望ましいことです。

たとえば、データベースには10,000件のレコードがあり、GUIでデータを検索するには時間がかかりすぎる場合があります。 一般的に、テスターが次のようにコンソールでクエリをすばやく作成できると便利です。

select * from {table_name} where {table_name.column_name}='condition' order by {column_name} desc;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

他のすべては素晴らしいボーナスです。

テストと省庁間コミュニケーションのバランスについて

テスターは、タスクを選択するだけでなく、一連のテストを実行するためにも自律性を必要とします。「可能なすべてをチェックする」とその時間のバランスを常に探す必要があります。 値チェック付きの特別なフォームからデータをすでに受信している場合、コンポーネント内のすべての可能な値とスクリプトをチェックすることは意味がありません。

たとえば、文字列変数のみを入力として受け入れるメソッドがあり、スクリプトを（セキュリティに関する言葉で）または整数変数を渡したときに何が起こるかを確認する必要があります。 そのようなデータのリストを非常に長い時間作成しても、他のタスクを完了する時間はありません。 妥当なテストのリストを選択する際に、既製のユーザーストーリーが役立ちます。 実際、フロントエンドはすでにいくつかのパラメーターの入力を制限しているため、チェックのリストが大幅に絞り込まれています。

一部のタスクでは、戦闘に近い条件での検証が必要です。たとえば、テスト環境では、すべてのアクワイアラーと支払いシステムを介してカードの支払いを完全に検証することは困難です。 したがって、チェックはプリプロダクションで行われます。複数のフロントエンドホストがバランサーから切断され、ネットワークから直接URLでのみ使用可能になります。

テスト環境と比較すると、一部のアクセスがないため、「戦闘」状態のシナリオを確認するのはそれほど便利ではなく、実際のお金を使いたくありません。 したがって、preprod環境では、限られた受け入れテストのみをテストします。

私たちの会社だけでなく、パートナーも関与するプロジェクトでは興味深いことがあります。 良い例は、Yandex.Kassaが支払いソリューションとして機能するパートナーのボーナスプログラムのサポートです。 キャッシャーは、ボーナスに関する情報を彼に転送し、たとえば、彼らが購入の一部を返済することができる必要があります-それは、買い手の欲求とボーナスプログラムの可能性に依存します。

そのようなプロジェクトの全体のポイントは、「省庁間協力」にあり、成功するためには反対側の特定の行動が必要です。

テスターの選択に関する最後の記事を覚えているなら、重要なコミュニケーションスキル、つまり全員と交渉する能力がありました。 そして、それはどこにもないように便利です。 特定の情報を交換するパートナーとの共同プロジェクトでは、動作テスト環境とデータ自体を取得する必要があります。 後者は、アフィリエイトカードのプールである場合があり、その中には、ブロックされた、条件付きでサポートされていないボーナスプログラムなどがあります。

テスト環境とデータに加えて、テクニカルスペシャリストの運用上のコミュニケーションのためのコミュニケーションチャネル（通常、パートナーのようなパートナーであり、多くのボットが独自のニーズに応じて作成されるTelegram）も必要です。 準備作業が実行されると、パートナー側でテストされたメソッドの準備が整うまで待機します。

たとえば、次の一連のアクションで構成される標準の支払い方法の検証についてさらに詳しく考えてみましょう。

1. テスト環境にアセンブリをインストールします。 これはJenkinsを使用して行うことができます。これについては近日中に説明しますが、今のところ、CI＆CDプロセスでJenkinsに関する次の記事を読むことができます 。
2. すべてのリクエストはカードトークンで実行されるため、支払いチェーンごとに一意のトークンを取得する必要があります。 チェーンの段階：トークンを取得し、バスケット内で引き落とされるポイントの数を要求し（ストアは商品の量をバスケットにYandex.Moneyに送信します）、パートナーボーナスを考慮した支払いを行います。
3. 以下は、特定のパートナーの詳細です。通常、ボーナスに関する情報の交換とその後のアクションが含まれます。
4. 前の段落からのクエリ中に、パートナーは、ドキュメントへの準拠を確認することが重要である回答を受け取る必要があります。 通常、成功のステータスコード（HTTP 200）、操作の成功ステータス、支払いID、注文ステータス、クライアント側の支払いステータスを含む応答本文が必要です。 フィールドのリストと許容値の範囲、および実行されたアクションと回答の一致の両方をチェックします。
5. パートナーのボーナスプログラムがトランザクションの結果に関する追加情報の送信を伴う場合、このデータの配信の成功も確認します。 通常、私たちは自分の側のログを見て、システムで注文が生成されたこと、支払いが行われたことなどを確認します。

ポジティブなシナリオをチェックした後、ネガティブなシナリオがチェックされます。 たとえば、ボーナスプログラムに参加していないカードを結び付けて、リクエストを試みます。 また、ネットワークタイムアウトをシミュレートし、リクエストへの応答を待機するかどうか、およびリクエストの完了に失敗した場合のエラーコードを確認することもできます。

このような一連のアクションはさらに自動化され、繰り返しテストを高速化します。 自動テスト自体はJavaまたはKotlinで記述されています。

主なキーが何であるかを尋ねた後にインタビュー中に、彼らは応答で私に尋ねました：「なぜあなたはこれを尋ねていますか？ Habrを開きます。ブロックチェーン、神経科学、人工知能に関する2番目の記事があり、ここで主キーについて説明しています。」 この記事は、テスターの知識が一種のマズローのピラミッドであり、基本的なことを知らないと次のレベルにジャンプできないことを説明しようとしています。

データベース、HTTP応答コード、およびLinuxコンソールは、IT業界の言語を有意義に話せるようにするアルファベットの一種です。 それらがなければ、あなたは中国人の部屋に座って、彼らがあなたに何を求めているのかを本当に理解するのではなく、あなたにどんな種類の答えが期待されるのかを知っています。

したがって、新しい人には、アルファベットの知識だけでなく、文を追加する能力と、アルファベットが実際に用語から何を意味するかを理解する能力が期待されます。