しかし、最初に、彼の伝記からいくつかの事実。 アラン・ペイジはほぼ25年間テストの自動化を行ってきました。 Microsoftでのソフトウェアのテスト方法とテスト自動化の美しいテストと経験：ソフトウェアテスト自動化のケーススタディの主執筆者。 自動テストに関する多くの論文とメモの著者、「The A Word」。 彼は開発とテストに関するブログを持っています。 アランは、MicrosoftのWindows 95チームに加わり、その後Internet ExplorerとOffice Lyncの以前のバージョンに取り組みました。 彼は2年間、Microsoft Test Excellence Centerを率いていました。 2017年1月、彼はMicrosoftをUnityで品質管理責任者として退職しました。
現時点では、アランは、 2017年 12月に開催されるハイゼンバグ2017モスクワ会議の基調講演者の1人であり、これに関連して、すべての自動化に切り替える必要性の主な兆候について尋ねることを急いでいます。
-アラン、自動テストへの移行に対するチームの準備状況をどのように評価しますか？ チームに専門知識があるかどうかを理解する方法と、そうでない場合は新しい人を探す方法とトレーニングを構築する方法
Alan Page：専門知識に関しては、appiumやセレンなどのフレームワークを使用できることが重要ですが、最重要ではありません。 私のチームの目標は、 クライアントが受け入れられる品質の達成を加速することです。そのため、テストと目標品質においてチームをより効果的にするものを検討します。 もちろん、これには自動テストケースの作成に関する専門知識が含まれますが、本格的なテストを作成し、チーム全体の効率を向上させることを目的としたテストツールを理解できることがはるかに重要です。
-テクノロジーについて：最も高度な必須ツール、IDE、およびプラグインは何ですか？ そして、あなたはそれについて何を読むことをお勧めしますか？ 誰がテストについて良い品質を書いていますか？
アラン・ペイジ：ここでは、驚くべきことは何も言わないでしょう。 セレンはどこにも行きません。 私は個人的にPythonとpytestが好きです（ そして著者として彼に同意します ）が、私の心のどこか深いところにはまだCがあります.IDEについては、さまざまな言語で長年Notepad ++で書いて、6ヶ月前に切り替えました崇高なテキスト。 したがって、私はここで私は顧問ではないと思います。
ブログについて：Richard Bradshaw（twitter @friendlytester）を購読する価値はありますが、彼は自動化のアイデアに満ちています。 そして彼は多くの興味深いものを借りることができます。 ところで、ここに彼のブログがあります： thefriendlytester.co.uk 。
-多くのプロジェクトは、レガシーコードの問題に苦しんでいます。コードの一部は維持が難しく、変更することは事実上不可能です。 レガシープロジェクトでの自動テストのプロセスはどのように変化しますか（特に多くの場合）。 レガシーコードをテストでカバーすることの利点は何ですか？
アラン・ページ：もちろん、いくつかの要因があります。 レガシーが変わらない場合、コードは十分に古く、バグは間違いなく修正されません。自動テストに時間を浪費しません。
他のすべてのケースでは、おそらくテストが必要です。 Michael Feathers著の「Working Effectively WIth with Legacy Code」はそのような状況を詳細に説明しており、一般に、開発チームが状況を理解するのに役立ちます：アイデアと戦略-コードを簡単に変更およびリサイクルできるようにする方法、必要なテストを書く方法。
-プロジェクトの作業のどの段階で自動テストを表示する必要があり、どの時点でそれについて考える価値がありますか？
Alan Page：プロジェクトやボード上の図を含むドキュメントを見るとすぐに、自動化について考え始めます。 しかし、時にはもっと早く-作成しようとしているものについて議論が始まるとすぐに、「これをどのようにテストし、テストするのでしょうか？」という質問をすぐに自問します。私たちは座ってこれをチームと話し合い、接続図（ Mindmap ）を作成します。 そして、物理的に「触れる」ことができる何かが現れる頃には、すべてが私の頭の中ですでに考え出されているので、プロセスは滞りなく開始されます。
-自動テストシステムは、プロジェクトの成長に合わせてどのようにスケールアップしますか？ 小規模プロジェクトと大規模プロジェクトのテストの質的な違いは何ですか？
アラン・ページ：いい質問です。 そして、これが自動テストのピラミッドに目を向ける大きな理由です。 ベースには小さなテストのグループがあります（ 著者から：このレベルは「下位」とも呼ばれます ）。 テストスイートは、プロジェクトの規模に比例して成長します。 プロジェクトロジックが複雑になり、中間レベルに達すると、統合（または中）テストが成長し始める可能性があります。 私は可能な限り依存関係を制限しようとしますが、このレベルのテストでは、プロジェクト自体の成長は通常は重大な問題ではありません。
エンドツーエンドテスト（ 注：またはトップレベル、「大」、「拡張不能」テストという用語も使用されます。この用語自体は、多くの場合、外部インターフェイスを介したテストとして理解されます ）-大規模プロジェクトでは、ほとんどの場合追加の注意が必要です。 システム全体を駆動および分析するテストが必要です。 そして、これは完全に自明ではありません（自動化の観点からも、テスターの立場からシステムを理解する上でも）。 多くの場合、大規模なプロジェクトはシステム内のシステムであるため、ユーザーの動作オプションの大部分をカバーする高品質のテストセットを作成することは可能ですが、単純ではありません。
-テストプロセスに問題があることをどのような兆候で理解できますか？
Alan Page：この状況の主な原因は通常「奇妙な」テストまたはあまり信頼性の低いテストではなく、チームが偽陽性の結果を処理する方法がここで大きな役割を果たします。 彼らがすぐにそれを理解し、テストがこのように動作する理由を理解できれば、心配する理由はありません。 そして、理解がない場合、またはさらに悪いことに、そのようなテストが単に無視される場合、これは常に何かが明らかに間違っているという疑念を引き起こすはずです。
また、チームが定期的にテストを実行しない場合も、注意を払う価値があります（おそらく、これは前の側面と関係があります）。 チェックイン前の単体テスト（ 〜SVNからコミット-約編 ）、ブランチをマージする前の統合テスト、またはリリース前のエンドツーエンドテスト。 チームがビジネスの決定を行う際に自動テストに依存しない場合-さらに広範なテストに投資するかどうか、ここで私はおそらく自動テストシステムでは思ったよりもさらに悪いのではないかと疑い始めます。
-現在の自動テストの主な傾向は何ですか？テストと開発の境界線はどこですか？
アラン・ペイジ：今日、この境界線はかつてないほどぼやけていると思います。 私のチームのテスターは実稼働中のバグを物事の順に修正し、仲間の開発者が自動化されたテストの大部分を書いています（私が少し前に話した中小規模のテスト）。 テスターが開発者と一緒にブレインストーミングテストを編成し、ペアでテストし、一緒にデバッグする方法を定期的に確認しています。 新しいテスター-新しいシステム機能を扱うチームのテストと品質のスペシャリストの役割で、本当に効果的な作業はこのぼやけた境界線上にあるべきであり、品質はこの境界線をぼかすことによってのみ向上すると思います。
テストのトピックがあなたと私たちの両方に近い場合、 2017年 12月のHeisenbug 2017モスクワ会議でこれらのレポートに興味があるでしょう。
- 技術テストに関する真実 （Alan Page、Unity）
- World of Tanksでの自動テスト：品質を守るボット （Alexander Shukov Wargaming.net）
- Badooでのジオロケーションテスト：バンプ、石、松葉杖、自撮り棒 （Alexander HostおよびNikolai Kozlov、Badoo）
- システムを起動せずにチェックする方法 （Andrey Satarin、Yandex）
インタビューは、セルゲイ・パラモノフ・ヴァラジアンの参加を得て準備されました。