配送は危険な​​ビジネスです

プログラム委員会コメント：

私たちの世界でのテストに関するSelenium WebDriverの意見を聞きたいですか？ 一緒に来て！

企業は、そのためにソフトウェアを書いたりリリースしたりしません。 ビジネスニーズを満たすためにコードを記述します。 もちろん、バグのないソフトウェアはなく、エッジケース、逃した機会、通常のエラーの散在がないプロセスはありません。 つまり、各リリースは、リリースのリスクが本番環境へのプッシュ失敗のコストを上回ると判断したリスク評価の結果です。 私たちは人間であるため、その評価はリスクへの恐怖だけでなく色分けされています。

カナリアリリース、機能の切り替え、注意深い監視、および明確に定義されたロールバック手順はすべて、このリスクを軽減するための技術的なアプローチですが、他に何ができるでしょうか？ 特に、リスクを可能な限り低く抑えるために、プロジェクトの存続期間中、テスターは何に貢献できますか？ この講演の過程で、ソフトウェア開発のライフサイクルをリスクに関する会話として作り直します。 チーム内のテスターの位置、テストの役割、およびリスクに対する恐怖を和らげるメカニズムとしてのソフトウェア開発である会話における自動化の役割について説明します。

Simon Stewartは、オープンソースのブラウザ自動化ツールであるWebDriverの作成者であり、Seleniumプロジェクトのリーダーです。 以前は、Facebookのビルドツールチームを率いて、グラフベースのビルドツールBuckを開発し、monoreposの強力な支持者でした。 Facebookに入社する前、彼はGoogleでほぼ5年間、ThoughtWorksで3年間過ごしました。 彼は多くのコードを見てきました。

サイモンは信じられないほどの速度でバイト単位の再現可能なビルドに興味を持ち、「紛れもなく毛深い」と自分自身を説明しています。

テストにおけるクラウドソーシング

プログラム委員会コメント：

これ以前にITとは関係のない多くの人がテストを行うとどうなりますか？ これから何か良いことがあるでしょうか？ たぶん！

Yandexがクラウドソーシングを使用して手動回帰テストのタスクをスケーリングする問題をどのように解決したかについてお話したいと思います。

回帰テストは、製品品質に取り組む上で非常に重要な部分です。 そして、より多くの製品を開発し、それらをより速く開発するほど、より多くの労力を費やす必要があります。

過去1年間、私たちは評価者の助けを借りてほとんどのYandex製品の手動テストのタスクをスケーリングすることを学びました。遠隔地の従業員は1人ずつパートタイムで働いており、現在では、700人以上の評価者がフルタイムのテスターに​​加えて製品のテストに参加しています。

レポートでは次のことを伝えます。

• 手動テストのタスクを可能な限り形式化し、何百人ものリモート従業員を訓練することが可能であった方法。
• プロセスを工業用レールに配置し、さまざまな環境でテストを提供し、SLAの速度と品質に耐えることができた方法。
• どのような困難に遭遇し、それらをどのように解決するか（そしてまだ決定していないものもあります）。
• Yandex製品の開発において、評価者によるテストはどのような貢献をしたのか、リリースの頻度と見逃したバグの数にどのように影響したのか。

TolokクラウドソーシングプラットフォームおよびYandexエキスパート評価部門の責任者。

現在、彼は、Yandexのさまざまな分野およびプロジェクトでクラウドソーシングの自動化、スケーリング、およびアプリケーションを担当しています：人工知能のトレーニング、コールセンター、ユーザーサポートサービス、コンテンツのモデレート、地図、翻訳などの多くのデータの作成のためのデータの収集。
最近のプロジェクトの1つは、クラウドソーシングを使用した手動テストプロセスの構築です。

彼の関心のある分野は、専門家の評価の世界における数学、このトピックに関するレポートおよび記事の著者です。

ペトリネットに基づいたテスト

プログラム委員会コメント：

テストを作成するための数学的な装置の使用は、Testing 2.0と安全に呼ばれます。 Alekseyは、この問題が彼のプロジェクトでどのように解決されたかを説明し、グラフ理論を使用してテストを開発するための代替方法を示します。

通常「エッジケース」と呼ばれる、テスト対象のシステムの異常な状態で発生するエラーをテストで根本的に検出できない場合はどうすればよいでしょうか。 不要なテストを作成したり、実行時間を犠牲にしたりせずに、テストカバレッジを増やしてより多くのエラーを見つけることは可能ですか？

このレポートでは、Toptalでこの問題にどのように遭遇し、従来のテストからモデルベースのテストへの移行を開始したか、その過程で遭遇した問題、ステートマシンの代わりにペトリネットを使用する理由、および最終的にはどうなるかについて説明します。 このレポートには、ペトリネットと多くのRubyコードの例が示されています。

彼は11年以上にわたってテストを行ってきましたが、過去5年間で、高度なスキルを持つ専門家の世界最大の分散コミュニティであるToptalの品質向上に貢献してきました。 貢献者Mozilla。 開発者のワティル。 Seleniumコミッター。Rubyの部分を担当しています。

繰り返してはいけません：Web、iOS、AndroidのUIテストを同時に

プログラム委員会コメント：

マルチプラットフォームテストを成功させることはそれほど難しくありません（成功事例）。

この製品にWebバージョンとモバイルアプリケーションがあることに驚かないでしょう。 同時に、UIテストはほとんどの場合、プラットフォームごとに別々に記述されます。 多くの場合、さまざまなフレームワーク、テストランナー、場合によっては言語を取得し、同時にこの動物園をサポートしています。 次に、製品の動作を変更すると、同じことをいくつかの場所で変更する必要があります。

オープンソースソリューションに基づいて、Webアプリケーションとモバイルアプリケーションの両方で機能するE2Eテストをどのようにすばやく整理できるか、およびそのようなソリューションでどのような問題が発生するかを見てみましょう。 このアプローチはPythonスタックで実証されますが、別のスタックに簡単に移植できます。
#python #web #mobile

昨年、IgorはUptickスタートアップで自動テストに従事しました。 彼は主にUI（Web +モバイル）とAPI（REST + GraphQL）のPythonテストと、.NET（コンポーネントと統合テスト）の少しを書いています。 それ以前は、New Cloud Technologiesで働いており、Ruby、Watir、Cucumberで1,000を超えるWebテストを作成およびサポートした経験があります。

1日あたり10,000,000テスト

プログラム委員会コメント：

多くの自動テストがある場合は便利ですが、その数がさまざまな理由で合理的な制限を超えると少し難しくなります。 セルゲイは、多くのプラットフォームで膨大な数のテストを同時に実行するというユニークな経験があり、それを共有します。

かつて、小規模なQAチームに、2日間ですべてのテストを実行するタスクが与えられました。その数に関係なく、成長、成長、成長し続けています。 テストレポートの時点で数千万人がすでに存在しています。 そして、これは私たちがプロセスとインフラストラクチャを構築し、そこに水たまりを入れて回った方法についての物語であり、最も重要なことは、恐れることを止めて多くの人を愛したことです。

Zulu OpenJDKを担当するAzul SystemsのTimlid QA /リリースチーム。 それ以前は、Oracleで長年働き、そこでQA JavaFXとJava2Dを学びました。 会議やstackoverflow.comでの経験を共有したい

検証のロジック

プログラム委員会コメント：

マイケルはコメントを必要としません。

ウィキペディアによると、ソフトウェアテストは「検証と検証」と呼ばれることもあります。「ウィキペディアによると、ソフトウェアシステムが仕様を満たし、意図した目的を満たしていることを確認するプロセス」です。 しかし、検証の概念とロジックを調べると、チェックおよび検証できるものとできないものに重大な制限があることがすぐにわかります。 これは、チェックが悪いことだと言うことではありません-それどころか、 チェックは非常に価値があります。 それでも、テスターとそのクライアントは、チェックの基本的な制限を認識し、テスト戦略でそれらの制限に対処することが重要です。

この講演では、Michael Boltonが検証の論理と、虚偽の前提とそれに関する誤解を招く結論に対して脆弱になる可能性のある方法を概説します。 また、テスト、実験、批判的思考の大規模なシステムに検証を組み込むことで、これらの問題に対処する方法を特定します。

テスター、コンサルタント、トレーナーのMichael Boltonは、Rapid Software Testingの共著者（James Bachと共同）です。このコースでは、不確実な条件および極端な時間的プレッシャーの下でソフトウェアを専門的にテストするための方法論と考え方を示します。 Michaelは、ソフトウェアに関するテスト、開発、管理、および執筆の20年の経験を持つ、コンテキスト駆動型のソフトウェアテスト運動のリーダーです。 現在、彼はトロントに拠点を置くコンサルタント会社DevelopSenseを率いています。 DevelopSenseの前は、MichaelはQuarterdeck Corporationにいました。 Michaelのホームページはwww.developsense.comです。

開発者は、テストピラミッドの構築方法をどのように学ぶことができますか？

プログラム委員会コメント：

自転車や松葉杖なしでピラミッドをテストします。

テストを迅速、簡単、信頼できるものにするために、ピラミッドを構築することがいかに重要であるかを、世界中から聞いています。 しかし、なぜ誰もこれをしないのですか？ 以下について説明します。

• ピラミッドを構築するために、どのレベルのどのテストを作成する必要があるか。
• 今日の多くのプロジェクトが実際には2つのサブプロジェクトで構成されていることを考えると、いくつかのピラミッドを作成する方法：バックエンドとUI。
• より低レベルのテストを作成できるようにするために、アプリケーションのアーキテクチャはどうあるべきか。
• どのmokaが役立ち、どれが品質テストの構築を妨げますか。

このレポートは、開発者とプロジェクトマネージャーを対象としています。

2008年以降、主にJavaで開発されました。 常にテストとコード品質に引き寄せられます。 ある時点でプロセスの最適化に関与し始め、2013年にCI / CDアクティビティに切り替えました。 AQAの仕事に完全に満足することはなかったので、2015年にテストに入り、すべてがより良くできることを証明しました。 彼は証明し、ビジネス分析に入りました。

まだレポートを見ていますか？ それから私たちはあなたに行きます！

プログラム委員会コメント：

真新しい魅力3.0。

Allureの2番目のバージョンのリリースから1年が経過しました。 この間、テストの数を大幅に増やし、新しいツールに移行し、テストの品質に関する情報を視覚化する方法を学びました。 これらの変更はすべてアリュールに反映され、レポートの新しいメジャーバージョンをリリースしました。

このレポートは、アリュールレポートに精通していないユーザーとアクティブユーザーの両方にとって同様に興味深いものになります。 かなりの数の新機能が追加されました。 さあ、それは面白いでしょう！

Webアプリケーションのテストの自動化に8年以上従事しました。 この間、彼はさまざまなチームとさまざまな役割で働いていました。テスト自動化、テストツール開発チームのマネージャー、テスト自動化グループの責任者です。 Artemは、一般的なツール（Selenium、HtmlElements、Allure、Jenkins）での幅広い経験があります。 主にJava、Groovyでプログラムします。

最後までテストする：スマートレスポンシブインターフェイスデザインパターン

プログラム委員会コメント：

レポートでは、UXが製品にどのように影響するかについてのすべての複雑さについて学び、テストする際に注意すべき点を理解できます。

レポートでは、Vitaliyはインターフェイスの一般的なコンポーネントとレスポンシブユーザーインターフェイスの問題に関する詳細な調査を実施します。
理想的なアコーディオン、日付と時刻のインジケータ、比較表、保険計算機、自動車コンフィギュレーターなど、すべてが何であるかを検討してください。

注意！ プレゼンテーション中に学習したすべてを忘れることができない場合があります。

Vitaly Friedmanは美しいコンテンツを愛し、決してあきらめません。 もともとベラルーシのミンスク出身のヴィタリーは、ドイツでコンピューターサイエンスと数学を学び、タイポグラフィ、ライティング、デザインに興味を持ちました。 デザイナーおよび開発者として6年間フリーランサーとして働いた後、彼はデザインとWeb開発の大手オンラインマガジンの1つであるSmashing Magazineを設立しました。 Vitaliyは、すべてのSmashing Booksの著者、共著者、および編集者です。 彼は現在、ドイツの美しい都市フライブルクでSmashing Magazineの編集長を務めています。

Webセキュリティテストスターターキット

プログラム委員会コメント：

研究者、賞金稼ぎ、Facebookを含む多くの重大な脆弱性を発見したトレーナーからのWebアプリケーションのセキュリティテストの紹介。

レポートでは、Webアプリケーションをより安全にする簡単な手順について説明します。

脆弱性を探す方法、それらがユーザーとサービスに与える脅威を説明します。

最も一般的なもの、XSS、SQLインジェクション、SSRF、XXEについて説明します。

脆弱性を見つけるプロセスを促進するツール（Burp Suite）について説明しましょう。 そして、他のいくつかの便利なツールについて。

レポートは、開発者向け-脆弱性の本質とその発生理由の理解に役立ち、テスター向け-これらの脆弱性の検索方法の理解に役立ちます。 リーダーは、脆弱性によってもたらされる脅威を理解し、アプリケーションセキュリティプロセスの価値を確認できます。

レポート後、聴衆はWebアプリケーションのセキュリティをチェックするために必要な初期知識を受け取ります。

過去10年間、彼はWebアプリケーションの脆弱性を探していました。 多くのバグバウンティプログラムのメンバー。 何よりも、プログラマーが意図したとおりではなく、プログラムが作成されたとおりに動作する場合、ビジネスロジックエラーが大好きです。 SEMrushでは、製品および作業インフラストラクチャのセキュリティなどを担当するセキュリティチームで働いています。

VKベータ

プログラム委員会コメント：

1つのソーシャルネットワークでのテスト開発におけるユニークな経験。 また、ジェームズ・バッハが何であるかもわかるでしょう。

VKベータテストに関するストーリー：すべてがどのように始まり、ジェームズバッハがそれとどう関係するか、大規模な更新と完全に新しい製品をテストする方法、使用するツール。

私たちは、12,000人のテスターのコミュニティを開発し、何万ものバグレポートを処理し、ベータテスト段階を開発プロセスに統合した経験を共有します。 他のチームによるアプローチとプラットフォームの使用例を見てみましょう。

キエフで生まれ、BIT部門のITMOで学ぶ。 Game | Changersプログラムの卒業生。 彼女はYota Lab、Corus Consulting、i-FreeおよびDocumaticで働いていました。 2014年、彼女はテスターとしてVKontakteチームに参加しました。 2016年以来、彼はVKテストの管理とVKテスターベータテストプログラムの開発を行っています。

最悪の敵としてのテスター

プログラム委員会コメント：

マイケルはコメントを必要としません。

時には、一部の組織では、テスターが自分が尊敬されていない、または認められていないことを訴えます。 プロジェクト管理は、テスターをタイムリーなリリースの障害と見なします。 開発者は、テスターを知識のない技術的に無知な害虫と見なします。 テスター自身が、テスターの役割、テストの使命、仕事を遂行するために必要なスキルを誤解することにより、専門的および対人的なタールピットに足を踏み入れます。

このセッションでは、マイケルボルトンがテスターが自分の評判とテストの職業のイメージを損なういくつかの方法について話します。 リフレームと解毒剤を提供して、テスターがこれらの問題を特定して解決するのを支援します。また、テスターの有効性を高め、テストへの敬意を高めることができる技術的スキル、社会的スキル、そして最も重要な思考スキルの開発への道を示します

テスター、コンサルタント、トレーナーのMichael Boltonは、Rapid Software Testingの共著者（James Bachと共同）です。このコースでは、不確実な条件および極端な時間的プレッシャーの下でソフトウェアを専門的にテストするための方法論と考え方を示します。 Michaelは、ソフトウェアに関するテスト、開発、管理、および執筆の20年の経験を持つ、コンテキスト駆動型のソフトウェアテスト運動のリーダーです。 現在、彼はトロントに拠点を置くコンサルタント会社DevelopSenseを率いています。 DevelopSenseの前は、MichaelはQuarterdeck Corporationにいました。 Michaelのホームページはwww.developsense.comです。