ALM WorksおよびClassmatesの手動テストの機能

プログラミングが、よく知られているジョークが主張するように、プロジェクトのコードベースにエラーを導入するプロセスである場合、バグや欠点の数が多くなりすぎないように、神経と目をspareしまないスーパーヒーローが存在する必要があります。 これらの人々は私たちの中に住んでおり、私を信じて、特定のプログラムに現れた次のバグについて悪い言葉がすべて言ったことを心に留めています：これは彼らの仕事が終わっていないことを意味します 十字軍 問題の検索が続行されます。

テストに関して確立された神話の1つは、ソフトウェアのテストは研修生にとっての問題であるという考えです。 別の神話は、テストプロセス自体がバグをキャッチするプロセスと呼ばれ、フィッシングの成功は修正された問題の数によって決定されるという考えと呼ぶことができます（これは、自動テスト実行だけでなく、手動テストでも特に当てはまります）。 両方の神話は、ITプロフェッショナルだけでなく、開発者の間でも非常に粘り強いものです。本当に素晴らしいソフトウェアを作成するプロセスのキッチンが誰であるかを本当に知っているので、それはかなり驚くべき事実です。 しかし、私たちは私たちが住んでいるものと一緒に住んでいます。状況を変えることは可能な限りです。

このようなトピックのために、テスト分野の2人の専門家を招待しました。Odnoklassnikiでテストを行っているNikita Makarovと 、ALM Worksで同じ方向を担当しているYulia Atlyginです。

Julia Atlyginaは 9年以上テストを行っており 、最後のテストはALM Worksで過ごし、Atlassian JIRAおよびConfluenceのプラグインを開発しました。 テスターの役割は、製品所有者およびSAFeコンサルタントの役割と組み合わされます。 ユリアの短い伝記の最近の古典的な結末は、「JIRAについて質問がある場合は、お気軽にお問い合わせください！」です。

-ジュリア、すぐに尋ねます。テスターの「良さ」の尺度は何ですか？

優れたテスターはある意味で完璧主義者である必要があります。まず、製品自体ではなく、ユーザーの作業について心配する必要があります。 結局のところ、UIで1ピクセルずらして配置されたブロックも問題であり、数字の前のスペースが誤ってデジタルフィールドに書き込まれた場合、または一般的なスペースだけの場合の不可解な動作です。

別のことは、動くピクセルに関するチケットは通常、最も重要ではないということです。 ユーザーのメリットについて話している場合、そのメリットに従ってチケットをランク付けし、可能であれば最も不快なものを修正する必要があります。 もちろん、これはまた、現在のリリースのリリースの時間枠内で除去するもの（または、より正確には、時間内に除去しようとするもの）とそうでないものについて不快な決定をもたらします。

-そのテスト、特に手動テストのアイデアはどこから来たのですか？ テスターの仕事における経験と知識はどれほど重要ですか？

経験、さらには私が言うには、特定の直感は一般的にテスターの仕事に多くを意味します。 手動テストのために経験の浅い研修生を何十人も入れた場合、彼らは確実に数百の欠陥を見つけますが、それらのほとんどは重要であると判明しません-男は十分な経験を持たず、どこかで、最も重要なバグがどこで探され、どれが見つかったかを理解する知識がありません報告する感覚。 そしてここでは、他のどこにもないように、最初の経験を得ることができるようにする第一のフィルターとして説明し、教え、行動するメンターが必要です。

-良いテスターと悪いテスターを区別するものは何ですか？ トラッカーのバグの数ではありませんか？

定量的なメトリックを使用してテスターの作業を評価することは困難です。 20チケットは1ピクセルと1ピクセルずつのシフトについて始まりましたが、特定の状況でデータを損なうプログラム内のキャッチしにくいバグ-ユーザー（およびテスト中のプログラム）の場合、おそらく2番目のチケットがより重要になりますが、これはUIの「ささいなこと」を意味しません、特にユーザーに表示されるものは、検索、報告、修正しないでください。 私の個人的な「精神的な」テスターの仕事の基準は、このテスターに​​よって修正されたバグのうちどれだけが現在のリリースで削除されたかです。

もちろん、テストはさまざまな方法で実行できます。 テストの明確な仕様がある場合（たとえば、どのフィールドにどの値を入力する必要があるか、プログラムがどのような応答を表示する必要があるかを示すまで）、自動テストを使用するほうが良いですが、人間の代わりになることはありませんテストへの参加。 テスト計画がある場合、かなり一般的な指示（「非ASCII文字のログインでユーザーを取得する」など）が含まれることがあり、ユーザーがこれらの指示を少しずつ実行するたびに、実行ごとに新しいオプションが提供されますテスト。 さらに、手動テストのみが、ユーザーの視点でのプログラムの動作やその他の形式化されていない自動化の観点から、理解できないまたは非論理的な迷惑なレイアウトの欠陥を検出できます。

自動テストに依存する手動テストは無視されることがありますが、経験から、これを行う価値がない状況が多くあることが示唆されており、プログラムが変更され、ファイナライズされ、 そのUIとテストは、プログラムの内部ロジックをテストするために書かれており、単に新しいUIの欠陥を見つけるようには設計されていません。

-新しいプロジェクトをゼロから作成するとします。 開発者、デザイナーを見つけ、現在、テストのスペシャリストを探しています。 この分野には何人の専門家が必要ですか？

質問はそれほど単純ではありません。 もちろん、簡単に言うと、多ければ多いほど良いということです！ 実際、答えはプロジェクト、プロジェクトの要件、開発プロセス自体に大きく依存しています。 場合によっては、開発者ごとに2人のテスターで十分ではありません。場合によっては、この比率は多くなります。

-そしてまだ-テスターの仕事は退屈ですか？

私の意見では、テスターは完璧主義者である必要があり、プログラムのどんな小さな欠陥でも、彼を中心に動揺させるべきです。 そして、これらは悪名高い単一ピクセルのレイアウトエラーだけでなく、特定の場合、全体としての何らかのフォームのレイアウトです。たとえば、最初に2つの入力フィールド、付随するテキストとOKボタンが配置され、ユーザーの観点からは、便利でわかりやすい。 後で、プログラムの機能を拡張する過程で、同じフォームにさらに12個のUI要素がスローされ、それらは非常に単純な方法で接続されませんでした。ほとんど確実に、テスター以外は誰もフォームが使用に不便になったとは言わないでしょう：開発者は、フォーム自体が正しく機能すると確信しています。 正しく動作しますが、不快です。

したがって、テスターはシステム全体の動作を全体として認識している必要があり、各部分の動作を理解することは非常に良いことです。 私にとって、テスターの仕事の特定の基準は、開発者ではなく人々が「システムのこの部分をここで変更すると、これがシステム全体にどのように影響するか」という質問をすることです。

私たちは、「フライ」のトレーニングを手配し、インターンの若くて経験豊富なテストスペシャリストをトレーニングすることで、私たち自身の解決策を見つけました。 とりわけ、この準備により、「稚魚」と私たちは、彼らの気質のために誰がテスターとして働くのに適しているか、そしてそのような仕事（そして一般的には考え方）が喜びではない人を理解することができます。

ニキータマカロフは、アウトソーシングおよび食品会社で働いていました。 Linuxベースの組み込みオペレーティングシステム、ビジネス、ソフトウェア、およびハードウェアシステム向けの複雑なVPNソリューションの自動化に従事していました。 2012年1月以来、彼はOdnoklassnikiプロジェクトのテスト自動化グループの責任者です。

-ニキータ、まず最初にお願いします。購入者に「箱」の形で配信されるソフトウェアではなく、オンラインサービスがあります。 この状況により、欠陥を見つけやすくなりますか？ これらのオプションはテストの点でどのように異なりますか？

まず最初に、開発およびテストされている製品の使用がどのように管理されているかを理解することが私たちのためです。

クライアントは箱入りソフトウェアを購入し、それが適切であると思われるようにインストール、構成、使用します。 これは、開発者が作成の過程で持っているアイデアと一致しない場合があります。したがって、購入者側の不満を避けないでください。 これを防ぐために、私たちは事前に座って、最も信じられないほどのユースケースでさえすべてを考え出し、この多様性をすべて考慮してソフトウェアをテストします。 プラスのアプローチは、「通常の」使用では決して発生しなかった欠陥を含め、非常に多くの欠陥をキャッチすることです。 少ない-このような開発にかかる力はかなり多くかかり、これは作業のコストと期間に反映されます。 クライアントソフトウェアのインストール後にすでにバグが見つかった場合、問題の診断とキャッチに時間がかかることがあります。

独自のオンラインサービス用のソフトウェアでは、状況が異なります：動作条件を完全に把握し（さらに、物理サーバー、ネットワークインフラストラクチャ、使用するソフトウェアのバージョンから制御します）、必要なテストをいつでも実行できます、「戦闘」作業中であっても。 同時に、たとえば、サービスの訪問者のごく一部についてのみモジュールの新しいバージョンを起動し、実際の負荷の下で作業中の2つのバージョンを比較することができます。

例として、私たちは生産のために率直に言って粗野なコードをリリースする余裕はありません。それについての否定的な意見は、サービスからのユーザーの流出をもたらす可能性があるからです。 同時に、当社のサービスは非常に大きな負荷で機能するため、非常に大きいため、それらを再現できるテストベンチを組み立てることはほとんど不可能です。 このような状況でテストを実施する方法は？ 幸いなことに、新しいコードを別のサーバーグループに展開して、すべての訪問者ではなく、ごく一部のユーザーにリクエストを送信する余裕があります。何百もの新しいバージョンを受け取ります。

-プロジェクトで手動でテストするものは何ですか？また、自動化を肩に移しますか？ このような動的なプロジェクトでは、手動テストは必要ですか？ どのようなエラーが手動でキャッチされますか？

私たちは、私たちのサイトのユーザーが正しい方法で何かをすれば、彼が理解している正しいことを手に入れることを自動的に検証したい（そしてこれを達成しようとします）。 言い換えれば、アルファテストを自動的に実行しようとします-アルファテストで自動的にチェックできるものすべてです。

手動では、逆に、自動化ができないことをキャッチします：特に、ユーザーが不満を持っているという欠点に対処します。サブシステム。

-UIの欠陥とレイアウトのキャッチをテスターの仕事に帰する価値があるのか​​、デザイナー、レイアウトデザイナー、テスターが技術的な意味でパフォーマンスを扱うべきなのか？

を含めてテストしてみます UI、そして最初はすべて一緒に-デザイナーとテスターの両方。 その後、テスターはデザインとユーザーの間にレイアウトがあるため、テストを個別に実施します。最も美しく、便利なデザインは厳しい現実に陥ることがあり、同じ思慮深く検証されたデザインが少し異なって見えるか、異なる上で少し異なって動作しますデバイス、およびデバイス、私たちが理解しているように、今日の市場には非常に多くのデバイスがあります。 さらに、ユーザーの利便性は私たちにとって重要であり、私たちはそれがより便利になる方法を研究し理解することに時間を費やしています。

-テスターの品質を評価する方法は？ 単位時間あたりに導入されたバグの数ではありませんか？

ここで小さな余談をしなければなりません。 実際、内部の大規模なプロジェクト全体は、リリーススケジュール、開発へのアプローチ、およびテストの優先順位を持つ、かなり独立したチームに分割されています：どこかで、最初からどこかですべてのアクションの詳細な計画を実行することが重要です-アルファテストの結果を処理し、それらに基づいて結論を導き出します。

通常、ラインナップは一定であるため、製品のビジョンは頭の中で保持され、チームメンバーは「うまくいく」ことができるかどうかを理解します。

そのため、テスターの仕事の質を、チームがスケジュールどおりにリリースすることを保証するために必要なすべてを行う程度によって評価します。

-計画と、おそらく財政の問題：12人の経験豊富なテスターの代わりに、同じ量の（たとえば50人）の訓練生を、スキルではなく数を「奪う」ことを期待して、何らかの感覚がありますか？修正を並べ替える2人の経験豊富な専門家ですか？ これは「愚かで失礼」ですが、おそらく将来的にはより効果的ですか？

私はそうは思いません。 まったく逆です。「問題を肉の上に投げる」ことは、問題が単純な場合にのみ少なくともある程度意味があり、原則として、頭を含めずにこのように「投げる」ことが可能です。 私たちのシステムは複雑すぎるため、このオプションが機能するにはシステムについて多くを知る必要があります。 私たちが採用したばかりの経験豊富なテスターの中でも、さまざまなプロジェクトシステムをすぐに理解できる人はほとんどいません。そのため、6か月かけて何がどのように機能するかを理解するだけでした。職業を教える必要はありません。

はい、私たちはインターンを受け入れて喜んでいます-そして彼らが本格的なテスターに​​なるために彼らの意欲を見るまで彼らを教えます（そして彼らは自分自身の強さを感じません）。

-テスターは、実際に修正されるよりもはるかに多くの欠陥を見つけます。 確かに、これは修正の速度に対するある種の個人的な態度を生み出します-しませんか 「バグが見つかりました-作業が完了しました」または「バグがある間-リラックスできません」とテスターに​​近い関係は何ですか？

もちろん、開発中のプロジェクトには常に新しい欠陥が発生するため、テスターは安心する必要がありません。 しかし同時に、見つかったすべてのバグが最終的に次の改善の理由になります。つまり、結果として世界を少し良くすることができます。

---

それで、このインタビューは終わりました。 最後に、ニキータとジュリアは、12月8〜9日に開催されるハイゼンバグ2017モスクワ会議で会うことができます。 ジュリアはテスターツールに関するレポートを持つでしょう、そして、Nikitaはホワイトボックスをテストするトピックを明らかにするでしょう。 ディスカッションゾーンは会議で開催されるため、あなたが立ち上がってスピーカーに質問をすることができます。