🧣 🙇🏼 🌮 テスト環境の進化：Igor Khrol（Toptal）およびAnton Semenchenko（COMAQA.BYおよびCoreHard）へのインタビュー 🏺 🥝 ✍🏽

私たちは並んで待つのが好きではありません、オンラインで注文したい、私たちはチケット売り場でチケットを購入する準備ができていません、すべてを電子形式でアプリケーションに入れましょう。そして、ここに重要な「しかし」があります！私たちは今ここで欲しいのですが、これが時計のように必ず機能するように。ピザの配達は時間通りに行われ、映画館の場所は確認で受け取った場所と一致しました。こうしたさまざまなアプリケーションやサービスのすべてで重要な役割を果たしているものは何ですか？

もちろん、これはテスト環境であり、それなしでは高品質の製品を迅速にリリースすることは不可能です。最新のテストツールがハリケーンのように私たちの生活に飛び込み、文字通り数年で私たちの能力を変えました。仮想化とコンテナ化を飛躍的に進め、Seleniumシリーズを試し、Dockerの長所と短所について議論しました。

なぜこれがすべて必要なのか、私たちは何に来たのか？

どんな未来が待っていますか？

「テストのために」専門家の第一人者と話しましょう。ツールキットでAからZに進みましょう。イゴール・クロールとアントン・セメンチェンコがこれを手伝ってくれます。

コーヒー、紅茶、その他の飲み物を買いだめし始めます。会話は長くなります。

したがって、Igor KhrolはToptalのテスト自動化スペシャリストです。 Igorは、最も一般的なツール（Selenium、HP QTP、TestComplete、JMeter）での幅広い経験があります。

-イゴール、こんにちは。 会話を始めることを提案します。 最初の質問は次のように定式化されます。ますます多くの企業が「コンピューターでチェック」オプションから、この分野の優秀な専門家による本格的なテスト部門の作成に移行しています。 これに傾向がありますか、それともテストを続けますか？

いいね私は、質問の定式化そのものに異議を唱えることができます。テストのために製品の特定のアセンブリを取得し、欠陥のリストを発行する従来のテスト部門は、現在のビジネスおよびソフトウェア開発の速度を満たしていません。開発を迅速に支援する準備ができているテストスペシャリストがプロジェクトチーム内にいる場合、私たちはよりアジャイルになります（その言葉はすでにかなりハックされています）。もちろん、テストエンジニアは相互に通信しますが、そのため、独自の管理構造を持つ部門はありません。多くの大手企業がこの形式で作業しています（例として、Spotifyについて非常によく書かれています）。テストは開発プロセスにますます統合されています。

人生は非常に速くなっているので、すぐに変更し、新しいリリースをすぐに展開する必要があります。顧客は1週間待ちたくありません。正式な手順は、収集され、配られた場合、1週間でテスト結果を受け取りましたが、あまりうまくいきません。

保存について。特に環境の文脈で、それが存在するとは言いません。近年の鉄のコストは下がりました、そして、かなり。また、バグによって会社が失う可能性のある金額は、不均衡に大きくなります。そのため、場合によってはコンピューターでのみチェックするオプションが見つかる場合がありますが、決してトレンドではありません。経済のために、サーバーを購入したり、お金を寄付して良いテスト環境を作成したりできなかった企業は知りません。

-最初のテストツールは90年代半ばに登場し始めました。 積極的な開発はまさにこの時期に始まったという声明に同意しますか、それとも今日のハイテク製品の「構築」の基礎になっただけですか？

最初のxUnitシステムはかなり前に登場し（ Wikipediaによると1989年について）、これまでのところそれほど多くのユーザーインターフェイスはなかったので、おそらくこれで十分でした。その後、1990年代後半、2000年代の初め、ユーザーインターフェイスが増えたとき、UIの最初のツールが登場し始めました。私のプラクティスの最初の1つは、 WinRunner （1995年に登場）とWatir （ 2005年からのバージョンがあります）でした。

それからそして今

テストは常に行われてきました。何かを書いたり実行したりした場合は、必ず確認する必要があるからです。これに敬意を表して、1945年に始まったテスターの日です。

テスト環境のトピックについて話す場合、テスト環境を準備するための特別なツールがあるとは言いません。私たちが行うことは、Docker、Puppet、Ansible、およびその他の関連ソリューションなど、実稼働環境をデプロイするためのアプローチを適用することです。再現可能な結果を得るために作成されました。効果として、本番環境のクローンを作成し、できるだけ現実に近い状態で安全にテストできます。

以前は、これらは数百枚の指示であり、新しいテスト環境が数か月間導入されていましたが、現在ではアプローチははるかに優れています。すべてが自動化され、すべてがコードに含まれています。スクリプトを起動しました-環境が構成されています。したがって、これらのことをテストツールとは呼びません。むしろ、DevOpsのトピック、管理です。

-イゴール、あなたの最初の「知り合い」について、この分野での決定について教えてください。 たとえば、いつVMwareプラットフォームを知ったのですか？ 現在これらのソフトウェア製品を使用していますか？

VMwareについて話すと、さまざまなオペレーティングシステムで製品をテストする必要があるときに、本当に役立ちました。現在まで、AmazonやGoogle Cloudなどのクラウドに進化しています。テスト環境が必要な場合は、スクリプトを起動するか、Slackボットを作成しました。動作するサーバーがあります。

数時間/数日/数週間使用して、このことをくぐもった。 Toptalでの継続的な統合のために、これらすべても最大限に自動化されています。 githubのコードがプッシュされ、Google Cloudで必要な数のサーバーを持ち上げ、テストを実行し、リグレッションの問題があればプルリクエストで私に書き込みました。ローカルでは、特定のことをテストするために仮想マシンを上げる必要がある場合があります。たとえば、Windows上のMicrosoft Officeでxlsxレポートがどのように表示されるかを理解します。

-多くの開発者は、テスト環境をクリーン（プリインストールされたOSと最小限のソフトウェアを使用）とダーティ（できるだけprodバージョンに近い）に分離することを好みます。 この区別は適切だと思いますか？ 膨大な数のこのようなオプションが存在する可能性があると思いませんか？また、このような選択肢のみを考慮しない方が良いでしょうか？

どのタスクを監視しています。単体テストを実行する場合は、最小限のソフトウェアセットが必要です。コード（JVM、インタープリターなど）を実行するもので、それだけです。個別のマイクロサービスまたはシステムのコンポーネントをテストする場合、おそらく多くのことを実行する必要はなく、興味のあることだけを実行する必要があります。練習では、ある種のステージングまたはプリプロダクション（彼らが呼ぶように）を戦闘環境にできるだけ近づけることが、最終チェック、受け入れテストに非常に役立つことを示しています。最大の近接性はすべてです：同じハードウェア、ソフトウェアのマイナーバージョンとパッチ、完全なデータセットなど。

-以前と現在のテスト環境を準備するプロセスは大きく異なりますか？ どのツールが適切で、どのような場合ですか？ つまり 会社の規模に応じてソリューションを選択する必要がありますか、それともツールは現在スケーラブルですか？

私が働き始めたとき、いくつかの指示に従ってテスト環境が作成されました。または、一般的には不明な管理者もいます。年をとるにつれて、テスターはすでにこれらの指示を確認し、展開プロセスをテストし始めています。徐々に、すべてがより大きな自動化に向けられ、結果として、結果の再現性、人的要因の削減になりました。最近では、環境のセットアップが手作業で行われることはめったにありません。ほとんどの場合、それはansible、puppet、またはそれに類似したものです。その結果、テスト環境は本番環境に可能な限り近く、prod'eに含まれないものはテストしません。

-日常業務でコンテナテクノロジーを使用したか、使用していますか？ Red Hat rancherOSまたはAtomicソリューションを見ましたか？

Docker / Containersおよびアドオンのトピックは今活況を呈しています。これはテスト環境に影響しますか？もちろんそうです。数回クリックするだけで、テスト用の作業システムをすでに取得できます。これは良いことです。 Toptalでは、当社のコンテナは主にテストに使用されます。

高度に準備されたコンテナにより、打ち上げの準備時間が短縮
統合テストに複数のコンポーネントが必要な場合は、互いに接続された複数のコンテナを実行することで簡単に取得できます

-同一の構成とアプリケーションを作成するすべてのステップの後、データを転送するという疑問が生じます。 どの場合、prodのミラーバージョンとしてテスト環境をサポートすることをお勧めしますか？ 重要なポイントは、データを使用したデータベースの非個人化です。 テストに提出されたとき、このプラクティスについてどう思いますか？

最終結果を確認する必要がある場合、受け入れテストには完全なデータセットが最も頻繁に必要です。一部の問題は、データがほとんどない場合や、実際の問題のように見えない場合は見つかりません。多くの場合、パフォーマンステストは実際のデータでも実行されます。

非人格化は、必要な良い習慣です。パスワードハッシュや顧客リストでさえ、テスト環境から外の世界に侵入したくないのです。

セレン

-現在、テスト環境でのSelenium（製品ライン）の積極的な実装と使用があります。 このプロジェクトがどのように変更され、新しい機能で成長しているのか見てきましたか？ 現在の状態のSelenium WebDriverについて何が言えますか？

Selenium'aの開発を積極的に監視し、バージョン0.8以降で使用しています。サイトselenium2.ruは非常によく書かれているため、ストーリー全体を語る意味がありません。

プロジェクトの現在の状態について言えば、最も重要なことは、プロジェクトがブラウザのw3c標準になり、ブラウザの主要メーカー自身がドライバを実装しているという事実です。

WebDriverを取り巻くエコシステムも静止していません。おそらく、WebDriver APIよりもさらに高速に開発されています。以前にテストを自動化するプロジェクトがカスタムフレームワークの作成から始まった場合、自己記述ソリューションの使用は不適切な形式と見なされます。ほとんどすべての言語には、ページ上の要素を正しくチェックしたり、AJAXを使用したりする方法を再度記述できないようにする既製のライブラリが既にあります。 Javaの場合： HtmlElements 、 Selenide 。 Rubyの世界では： Capybaraとpage-object 。 PythonのWebium 。

Seleniumに捧げられた優れたリソースのうち、 SeleniumCampカンファレンスの録音についてアドバイスできます。私は定期的にそこに参加しており、毎年テーマが発展するのが好きです。

-過去数年間で、テスト環境を作成するための特定のツールを5つまで完全にどのように管理しましたか？ 今すぐ試してみる価値のあるサービスは何ですか？ たぶん、あなたが今注意を払うべき開発プロジェクトがありますか？

テスト環境の作成に関するトピックは、DevOpsと密接に関連しているため、テスター向けの個別のツールは何とか発生しません。環境がますます同じになるにつれて、「そして、それは私のために働く」というフレーズがあまり一般的ではなくなったことは、驚くべき成果だと思います。この点に関するキーワードは、ansible、puppet、docker、vagrantです。展開スクリプトは、プロジェクトと配信の不可欠な部分になっています。

クラウドソリューション（AWS、Google Cloud、DigitalOcean）に言及するしかありません。以前は、誰もがサーバーを購入し、サードパーティに何かを提供しようとすると大量のinりが生じました。現在、独自のデータセンターを購入できる企業はほとんどないため、必要はありません。

有望な分野の中で、私は一般的にサーバーを持たないクラウドベースのソリューションを指摘することができます。サーバーは過負荷になり、アップデートをインストールし、あらゆる可能な方法で時間を費やす必要があります。 Push'nulコード-テスト環境またはprod'eのこのコード。これがGoogle App EngineのHerokuです。

-答えてくれてありがとう。 次の公演をお待ちしています。

アントン・セメンチェンコは、自動化コミュニティwww.COMAQA.BYの活動家であり、C ++およびwww.CoreHard.byの「厳しい」開発です。主な専門分野：自動テスト、C ++以下での低レベル開発。

-アントン、こんばんは。 会話のトピックは「テスト環境の進化」です。 スペシャリストとしての養成の歴史について少し触れてみてください。開発ではテストについてお話します。

いいねわかった

「このストーリー全体でどうやって終わりましたか？」 テストへの移行プロセスは、あなたが働いていた会社でのこのセグメントの開発プロセスと並行して行われましたか、それとも専らあなたの選択ですか？

すべてが偶然に判明しましたが、これは確かに私の選択です。私は、他の幅広いITスペシャリストと同様に、間接的にテストに関与しました。最終製品の品質保証は複雑で複雑なプロセスであるため、コーディング標準、コードレビュー、単体テスト、ペアプログラミング、コードの主要なセクションの正式な議論、ERDとの連携、PRDはすべて品質保証の同じ要素です（以下） QA）開発者が参加します。そのため、一般的なQAサイクルは明確でした。私は確かに品質の確保に参加しました。

たとえば、単体テストなど、QAに完全に関連するプロジェクトがありました。たとえば、Symantecから、80年代初頭に純粋なCで開発されたフラッグシップ製品のコアを単体テストでカバーする要求がありました。一方では、これは開発のための難しい技術的課題であり、他方では、100％QAです。原則として、テストを目的としていないユニットテストのみを扱いました。 250以上の循環的複雑度を持つ関数が存在する場合がありました。それで、テストでそれをカバーする方法を理解するために、たった1か月で1つの機能だけを扱うことができます。だから、もちろん、私はQAに関連付けられていましたが、具体的には間接的に関連付けられていました。

自動テスト

ISsoftでの彼の最後の仕事で、このアイデアは独立した自動化されたテスト部門を開くようになりました。会社には自動化がありましたが、まず、サービスとしてではなく、リソースとして自動化を提供しました。専門家がいて、あなた自身が目標、タスク、プロセスを策定し、「掘ることができます、掘ることはできません」というスタイルで働いています。サービスの品質とソリューションの技術的コンポーネントの両方の新しいレベルに到達するというビジネス上のニーズがありました。第二に、同僚が長年直面してきた仕事のために、プロフェッショナリズムに敬意を払って、これらの「課題」に取り組む準備ができている人は会社にいませんでした。

そのような部門をゼロから組織する提案を受けました。この役割には、ソフトウェア開発と人と仕事をする能力の両方に異なるスキルが必要でした。素晴らしいチームを編成する必要があったためです。そうでなければ「山を動かす方法はありません」。技術的な要素だけでなく、さまざまな要因の組み合わせにより、その選択は私にだけではありませんでした。「予定」は、私にとっては興味深かったように思えましたが、間違いではなかったようです。テストの自動化は無条件の傾向です。

私は約4年前にこの方向で働き始めました。私は非常に幸運でした、私はすぐにチームに完全にフィットする人を見つけました、お互いを補完しました、実際には、バックボーンが組み立てられました：Andrei Stakhievich、Vadim Zubovich、および多数の会議、出版、トレーニング、その他の活動、専門家で知られている他の多くの専門家。チームがいなければ、これらのタスクに物理的に対処できません。

当然、明日自動化とは何か、専門知識を適切に開発して販売する方法を理解するには、今日の自動化を理解する必要があります。最も単純で最も正しい解決策は、専門家に尋ねることです。会議に積極的に参加し、リスナーの役割に参加し、さらにプロトタイプを開発し始めました。たとえば、現在トップにある20個のツールを使用して、特定のタイプのアプリケーションのプロトタイプをそれぞれ作成し、比較分析を行って、結論を導きましょう。大部分の企業が単に持っていなかった、良い概要情報が判明しました。

他の企業の代表者は、1つまたは2つの方向を非常に深く知っていましたが、20年間、そのような幅広い報道はありませんでした。さらに、少なくとも4年前に、情報の真空の問題を目の当たりにしました。専門家のユニットは、今日の自動化を知っており、「秘跡」の知識を共有する準備ができていました。私たちは自分でプレゼンテーションを行い、情報を「ファンブル」にしたので、アイデアはテスト自動化に直接または間接的に関連する専門家間のコミュニケーションのための効果的なプラットフォームを構築することを目的とするコミュニティwww.COMAQA.BYを組織することになりました。

この地域は非常に動的で非常に広く多面的であるため、1つの会社の支援ではカバーできないことは明らかでした。これには、さまざまな企業のさまざまな専門家、さまざまな国のより良い専門家の仕事が必要です。今、私たちは積極的にCISを動き回り、協力しようとしています。秋になって初めて、ロシアとベラルーシの隅々にある25のイベントに参加します。このような何か私はこの興味深いエリアに来ました。私の特別な選択だったとは言えません。そのような申し出を受けなかった場合、素晴らしいチームを結成できなかった場合、これは起こりませんでした。多くの点で、私が自動化に取り組んでいるのは人のメリットです。

-正しいテスト環境の準備とテストプロセス自体が、製品の準備とリリース中に徐々に標準になると言うことはできますか？

これは非常に複雑で物議を醸す質問であり、いくつかの質問に、全体の質問のグループに分割する必要があるように思えます。私は主観的な意見を表明しますが、おそらく多くの専門家は彼に同意しないでしょう、それは白熱した議論を見るのがより面白いです。私の意見では、特定のプロセスを組織化するアプローチにおいて概念的に新しいものをもたらすことは事実上不可能であり、封建的な城の管理について話しているのか、ソフトウェア開発プロセスについて話しているのかは関係ありません。広義では、プラトンの定式化におけるソクラテスは最初のオブジェクト指向プログラマーでした。彼には、アーキタイプ、カテゴリー（階層）、私たちの世界におけるアーキタイプの不完全な実装などがありました。このアイデアが開発されてITに適用される場合、ここにはクラス、メタクラス、オブジェクト、およびその他の技術属性を持つOOPがあります。

実際、50代には、スタンドの設置と組織、正式なテスト環境、深刻なテスト計画、その他のドキュメントを担当し、今日よりもはるかに厳格で標準化された形式の専門家がすでにいました。これは、「ハードウェア」が非常に高価であるため、「マシン時間」が非常に経済的に費やされたため、実際の達人がコンピュータに許可され、環境を非常に慎重に正しく構成しました。

信じがたいことですが、フレデリックブルックスが彼の正典「Mythical Man-Month」で説明したハードウェアとソフトウェアの開発は、人類史上2番目に高価な科学プロジェクトであり、最初はアメリカの宇宙計画です。今日、私たちはenvを誤って整理し、欠陥をスキップすることができます。過去には、標準の「マイナス」に加えて、専門家は「マシンタイム」が高価な「スペース」であったため、ここで数十万ドルが浪費される状況を受け取りました。

一方、今日、非常に根本的に変化しました。ソフトウェア製品の数は指数関数的に増加しており、平均的なソフトウェア製品の複雑さは指数関数的に減少しています。 60年代に非常に巨大で非常に複雑なソフトウェアが基礎科学、銀行システム、軍事用に開発された場合、今日ではペットのWebページになり得るため、作業は非常に簡単です。しかし、3番目の「コインの側面」があります。量が増え、異なる環境が発達しているという事実により、ヘーゲルによると量から新しい品質への移行があります。

ヘーゲル曲線の新しいラウンドへのまさに「跳躍」は、セドフの「階層的補償」の法則のおかげで必要性によって決定されます。「適用された」思考、多くの異なるオペレーティングシステムとそのバージョン、ブラウザ、その他の「ユーザー指向」バインディング、およびそれらの開発。 JVMや.Net Frameworkのバージョンなど、広い意味でのコンポーネント、物理環境と仮想環境、非常に異なるハードウェア-これらは今日の現実です。

60年代の仮想化と今日の革新的なテスト環境は、1つの弁証法的なスパイラルのちょうど異なる回転であるように思えます。最適なものを探すために、ITスペシャリストと最終消費者は、根本的に異なる新しい技術レベルにアクセスしながら、極端なものから別の極端なものへと投げかけられます。移行は非常に「急性」であるため、快適ゾーンからの非常に急な出口の問題に遭遇し、実際には長い間忘れられていたITコールを解決する新しい方法を模索し始めますが、それらの関与を伴う新しいコンテキストで確実に理解する必要があります他の専門家。

一方で、「基本的な」変化について話すことはできません。他方では、「定性的な」成長を否定することはできません。なぜなら、さまざまな環境の数が指数関数的に増加し、常に統合と統合の問題があったからです。環境のバリエーションがn個ある場合、それは1つです。eのn乗とはまったく異なり、それらを「接続」し始めます。組み合わせ論と動的環境の全体としてのこの問題は、今やすさまじいものです。

このような複雑な最初に定式化された質問に明確な答えを出すことはできませんが、おそらく次のような、言い訳に似た理論的に重要なものを除いて：トレンド、次のラウンドの「ターニングポイント」を見ることができます。新しいコンテキストで過去の開発を使用し、時間内に準備します。主なことは「弁証法的垂直」に行くことではありません。環境の領域で「パンノフ-スヌーク垂直」に行くのではなく、ロジックで、スカイネットを構築するか、または最上位に登ります。膨大な数の抽象化層を導入することにより、組み合わせの複雑さに対処します。「実践的な」システム管理とは何か、「上から下へのすべての道」、両方のシナリオは理想的です-悲観的です。

仮想化

現在ほとんどのクラウドサービスが構築されているのと同じ仮想化を採用し、仮想化の開発の段階としてコンテナ化を採用します。 50年代に仮想化のプロトタイプが登場しました。私のメモリが役立った場合、最初の産業用シリアル仮想化は64年目に登場しました。

これは、仮想化が新しいもの（50年の新しい、「時代遅れ」）であると言うことではありませんが、一方で、現在の形式では、多くの異なる仮想化エンジンがあり、それらすべてを互いに「接続」する必要がある場合、「チャレンジ」は根本的に異なります。別のクラスのアプリケーションも登場しましたが、その唯一のタスクは、単一の管理APIを構築するために、異なる仮想化エンジンを均一かつ効率的な方法で「友達にする」ことです。低レベルのCLIでも共通UIでも構いません。

いくつかの間接的な個人的な例を挙げましょう。長年にわたり、データ保護ソリューションの開発に取り組みました-データのバックアップとリカバリの無限のバリエーション。最近、今日、そして明日、非常に人気のあるタスクの1つは、「cな」ベアメタル復元です[2]。

「頭から」抽象的な状況：Windows 2000を搭載した32ビットIntelベースのハードウェア上の物理マシン。バックアップとベアメタルリストアにより、数十分で、理想的にはワンクリックで、Windows Server 2008の64ビットAMDハードウェアに転送されます...そして、この「リッチ混乱」にさまざまな仮想化エンジンを追加した場合...そして消費者の「サービス」の観点からマシンをオフにせずに、問題「ホット」を解決しようとしていますか？そのような非自明な変換が非常に求められています。

3年前に本物のITクロンダイクがあり、多くの大企業がこの金市場に参入しようとしました。これには、DPI.Solutionsスタートアップ（私の「若々しい最大主義」が肉眼で見える）を含むベアメタル復元ソリューションのサブセットが含まれます。 Windows XPが公式にサポートを停止するとすぐに、銀行は、内部ポリシーにより、関連するセキュリティパックなしで「OS」に留まる権利がなかったため、新しいOSへの大規模な移行の安全で高速かつ実行可能な方法を必死に探し始めました。

大規模な組織の慣性とOSの更新に莫大な費用がかかるため、銀行は最終日まで、MicrosoftによるWindows XPの継続的なサポートを望み、移行を開始しませんでした。その結果、銀行にとって「致命的な」状況が発生しました。2か月または6か月以内に、各小さな従業員の数十万台の車をOSの次のバージョンに移行します。すべてを撮影できます。

特殊なベアメタル復元は、指定された「ひどい」制限で同様の問題を解決しました。 Windows XPでバックアップマシンを作成し、セキュリティパックの更新プログラムが公開される新しいWindowsまたは古いハードウェアにすべての「履歴」情報および設定とともに、完全に動作可能な状態で展開しました。多くの企業がこの分野に特化しています。これは間接的ですが、鮮やかな状況であり、「環境」の現在の複雑さを示しています。

若者の問題

主にCISのITが「若い」専門分野であるため、テスト環境の正式な準備が今日になってようやく伝わったようです。教師/教師の記憶に世代間のギャップが生じています。

第一に、非常に強力で活気に満ち、長所と短所を備えたソビエトのITは、控えめに言っても、今回の判断は困難です。これらは「間違った側から」の話です。その後、ITがまったくなかったか、ほとんどありませんでした。急速な開発は2千分の1で始まりました。最初の企業はどこにでも作成されましたが、規模は大きくなく、ITは主流ではなく、給与、したがって有能な人材の流れは比較的低く、他のエンジニアリング分野に匹敵しました。

2005年以降、活発な成長が始まり、業界は10年間発展を続けています。正直に言うと、私たちはまだ10代の若者であり、無知と過大評価の古典的な「10代」の問題を抱えており、父親が長い間知っていたことを再発見しています。何をすべきか、同僚を見てみましょう。物理的にITの量が少ない国を取り上げましょう。たとえば、モルドバの「ビジネスアナリスト」の概念は数年前に登場しました。この機能が常に存在していることは明らかですが、役割の概念はほんの数年前に現れました-CISの私たちは「1つのジュースで煮沸している」ため、「職業の若者」の鮮明な図解です。

, «» . IT — , , . , ; IT- – , , .

, , IT , IT- , , , «», .

DevOps-, ? , . «» IT- . , IT- , , .

, , , meet-up, IT-, IT- , .

. , , QA. , , , Quality Assurance , 1-2 , 3-4 SQA Days 20-40 . , , . , , , , « » — meet-up-.

, . COMAQA.by 4 , QA Automation, , IT-, meet-up- . 5-6 : 2 , 2 , 8 -, 16 , 500 , - . - Docker-. . .

. CoreHard, «» , ++ . 4 . 22 : 11 , 350 , - . CoreHard speak-: – Boost, «Boost C++ Application Development Cookbook», ++ ; — 8 Microsoft, Bing; — , PVS-Studio C C++ ; – 20- , OpenSource- C++; - . , .

, . , . , .

«» , , .

— — , , ? ?

. , - , – , , .

, «» . , «» , . , ISTQB.

(, , « »), . , ISTQB -, , , .

, , . COMAQA.by - , , , . , «» « », Software-Testing.ru , - «».

, 6- - SECR . , QA- «» .

— ? ? ?

. -: « !» :) , , , , — . . , .

: ROI, ROI, Calculator / stakeholder-. , , , . , , , .

, , , , . , , , , .

— — , — « », ?

, — IT-, DevOps-. , , -, , Docker- , , «» -«». , , .

, , - , «» , , , Java stack, Web, Angular, , , 25.

ExTENT 2015. , DPI.Solutions EPAM. , , , , , , « », - , .

— . ? , ? ?

, , . ?.. . , ? , , . ! .

— Docker? , , OpenVZ — ? . «» ? ?

, , Docker — . , , , OpenVZ . Docker .

UI, , - «» , , . . , , , . , API, , , , , best practices.

— — -. , , . - -? ? ? , , ?

, . production, test- env , , .

, ; - , , , , .

, , . . . , , .

— , , , / ? , ?

: ? , «», – ! ! , , .

60- . , , « ». , , «», , Selenium- , , «» , Desktop- .

– .

, .

( «: , » ) ( «» «» Selenium WebDriver ) :

テスト環境の進化：Igor Khrol（Toptal）およびAnton Semenchenko（COMAQA.BYおよびCoreHard）へのインタビュー

それからそして今

セレン

自動テスト

仮想化

若者の問題

More articles: