私たちは古いパターンに従います：私はあなたのために連続して10のレポートを見て、あなたがそれを興味深く投げることができるように内容の短い説明をします。さらに、サイトからスライドと説明へのリンクを収集します。私はそれを分類し、評価を上げる順にそれを与えます-つまり、一番下に最もクールなレポートがあります。評価はYouTubeでは好きではありませんが、独自の評価システムであり、好きよりも格好いいです。

前のパート： JBreak 2017 、 JPoint 2017 （両方のカンファレンスはJavaについてでした）。

今回は、テスター（およびサイトのメインページに記載されているプログラマーとチームマネージャー）の有名な会議であるHeisenbug 2017 Moscowを研究対象とします。

投稿には膨大な数の画像とYouTubeへのリンクがあります。 注意トラフィック！

免責事項 ：すべての説明は私の個人的な意見です。書かれたものはすべて私の病気の想像力の結果であり、スピーカーの歪んだ引用ではありません（この警告はスピーカーが私をbeatらないように書かれています）。誰かが誤って気分を害した場合-個人的に書き込み、それを把握します。しかし一般的には、このように考えてみましょう。BadComedianが毎回Cinema Foundationに何を言ったらいいのか、何を言わないのかを尋ねたら、少なくとも1本のビデオを作るでしょうか？

10. セレン化物パズル

スピーカー ：アレクセイ・ヴィノグラドフ、アンドレイ・ソルンツェフ。 推定値 ：4.31±0.14 プレゼンテーションへのリンク。

Puzzlersは、すべての視聴者がショーの直接参加者になるクイズレポートです。プレゼンターは、6つ以上の興味深いタスクを思い付きます。そのほとんどは、実際の設計の実践から取られています。各タスクのオプションのリストが示されており、それぞれに有利な説得力のある引数が与えられています。

このパズルのテーマは、Selenide UI Testing Frameworkです。フレームワークの表面的な知識を持つ初心者向けの質問が用意されていますが、一部の専門家でさえ、それらの一部について歯を折るでしょう。

ところで、Andrey SolntsevはSelenideの作成者であり、Alexey VinogradovはRadio QAのVinogradovと同じで、それ自体が配信します。

ここではパズルのピースの答えを台無しにしませんが、いくつかのタスクを提供します。

最初のパズルは非常に簡単です（答えを見たなら）：

しかし、ここではそれほど明白ではありません。

最後まで喜んで聞いた。パズルがプログラミング会議でしばしば役に立たない場合（しかし、魔法の知識がプログラマーに信じられないほどの喜びを与える場合）、このレポートには直接的な実用的な価値があるのは面白いです。著者がStackOverflowを使用して最も奇妙な上位10の質問をGoogleで検索しただけでなく、実践からタスクを取得しただけであることはすぐにわかります。

9. セレニウムのスケーリング

スピーカー ：サイモン・スチュワート。 推定値 ：4.33±0.13。プレゼンテーションへのリンク。

サイモン・スチュワートは、控えめに言っても有名人です。最初にWebDriverを作成し、Seleniumを引きずり続けたのは彼でした。

レポートは、ロケーター、長いXPath、およびスリップに関するいくつかの非常に基本的なことから始まります。サイモンは、一般的な問題を回避するような方法でテストとアプリケーションを作成する方法について話します。

しかし、その直後（24分以内）に、レポートの主なトピックであるスケーリングについて話が凝縮されます。

彼は、 static

およびThreadLocals

が悪い理由と、コードが不安定でステートレスであるべき理由を説明します。さらに、これらの説明は、高性能コードをプログラミングするための標準的なアプローチ（ここでは、一生懸命やれば静的関数の使用を証明できる）からではなく、テストから来ています。

これはすべて、彼のMacbookでのライブデモによって強化されています。

著者は体系的に問題にアプローチし、 独立した場所からテストを開始することを検討しています。一般的に、そのような質問はインタビューに最適で、人が書いて働いただけなのか、働いたのかをすぐに判断できるように思えます:-)

典型的なWebアプリケーションを例として使用して、テストが失敗する可能性がある状況を検討しますが、キャッチしようとした理由ではありません。

途中で、SimonはSeleniumアーキテクチャの適用可能性の詳細に踏み込むことをheしません。彼がそれを開発したのも不思議ではありません。

そこで彼は、Selenium Gridを使用して、実際のデモでそれを見せてくれました。

もちろん、Dockerです。 Dockerの最初のルール：常にDockerについて話してください！

そして、それはすべてクラウドプロバイダーで終わります。

レポートの最後に、発生する可能性のある標準エラーの説明があります。

過去に、DevOpsを実装しましたが、レポートに記載されているフルスタックの問題は非常に親しみやすく、身近なものでした。私自身は、テストスケーリングのいくつかの基本的な問題に関するSimonの公式の立場（実際には、Seleniumチームの立場）を取り上げました。これにより、将来ツールをより正確に処理できるようになります。

8. 白いパンドラの箱

スピーカー ：ニキータ・マカロフ。 推定値 ：4.34±0.07。プレゼンテーションへのリンク。

Nikita MakarovはOdnoklassnikiの自動テストグループの責任者です。彼はハイゼンバグプログラム委員会のメンバーでもあります。時々私たちはインターネットでコミュニケーションを取りますが、彼の報告を見るのは特に面白かったです。

まず、レポートは、ニキータが既にプレゼンテーションを投稿し、その上にQRコードを与えたという事実から始まります。それが素晴らしいと言うことは、何も言わないことです。私見、これはすべてのスピーカーが一般的にすべきことです。 YouTubeで会議の記録を見ている私たちにとって、これはそれほど重要ではありません。

要するに、テスト業界は「ブラックボックス」について多くを語っていますが、「ホワイト」について言及されることもあります。これは、「ホワイトボックス」のテストが常にプログラマの特権であると考えられてきたという事実によるものです。

このレポートは、いくつかの書き込みに関する質問に答えます。

プログラマが間違ったコードを書くのを防ぐ方法は？
コードにクラッシュを実装して、ひどく傷つけないようにする方法
なぜソースコードを解析する必要があり、これから何を得ることができますか？
ソーシャルコード分析とカバレッジ-なぜ、なぜ？

当初、ニキータは、ホワイトボックスに関する情報がほとんどないのではないかと考えています。彼は関連する歴史的背景とこのトピックに関する彼の研究について話します。

その後、詳細に進みます。 Nikitaが、DevOpsに関する前回の講演で使用したものと同じコールスタックのスクリーンショットを使用しているのは面白いことです。

ブラックボックスの観点からこの一連の呼び出しを入力しようとすると、多くのテストを実行できません。すべてのJavaプログラマーはこれを知っており、（期待したい）すべてのJavaテスターですが、これは通常は考えたくないことです。

それは動機付けの部分でした。次に練習があります。ニキータは、既成のソリューションはないことを事前に警告し、原則を伝え始めます。

解析された質問は、Javaコードの特定の例で説明されています。

ある時点で、彼はアイデアを発見し、すべてを見せ始めました。

このレポートでは、さまざまな種類のテストとそれらのツールについて説明しています。

そして、これはすべて、スピーカーのラップトップでのライブデモで示されています。情報の集中度が非常に高いため、言い直すのは無意味です。

実際、レポートはトピックの特定の「没入レベル」に分かれています。それは最も単純なものから始まり、最も恐ろしいもので終わります。たとえば、ソース解析と抽象構文ツリーについてもあります。

最後に、ニキータは、ホワイトボックスは戦略であり、それをどのように実装するかは私たちのビジネスであり、特定のプロジェクトに依存していると要約しています。あなたは頭で考えなければなりません。

そして、私が特に気に入ったのは、レポートが人生を肯定するメモで終わることです。コードを読む必要があります！（テスターにこれをさせる方法、しかし、私はまだ理解していません）。

7. A / Bテストが壊れています

スピーカー ：ロマン・ポボルキー。 推定値 ：4.36±0.13。プレゼンテーションへのリンク。

JBreakおよびJPointカンファレンスの準備中にRomanに会いました。この小説は、私のスライド（およびレポート全般）を、私が一人でできるほどだらしないようにするのに役立ちました。また、RomanにはA / Bテストなどのトピックに関する信じられないほどの深い知識があり、彼が講演するのを楽しみにしていました。彼はそこにいます。

この小説では、テストに隣接する領域について説明しています。機能が正常に実装されていることを確認した後、ユーザーが新しいバージョンを気に入っているかどうかを調べるための実験にロールアウトされます。

通常、実験の責任者は、データを解決するには不十分であると言っていることに気づきましたか？多くの場合これは真実ですが、多くの場合、実験システムの内訳とユーザー統計の考慮にすべてがあります。

このレポートでは、そこで発生する典型的な故障について説明しています。その結果、職場に戻って、少しデータ科学者になり、自宅で間違いを見つけることができます。それらのいくつかはおそらくそこにあります。

一般に、私は数学の知識が非常に乏しく、さらにマットスタットの知識も乏しく、ローマの報告から何も得られないのではないかと心配しました。 IQが十分ではないからです。しかし、いや、理解できない方法で、レポートの内容は実際に非常に理解可能で適用可能であることが判明しました。

レポートは、草がより緑だった時期にマイクロソフトが行ったテストの1つに関する話から始まります。

最大の間違いは、テストがまったくない場合、製品に何かを展開できるため、後悔することです。

多くの場合、人々はそこで何が複雑なのか理解していない-ユーザーによってそれを壊し、みんなに見せて、結果を計算して-これで完了だ！

実際には、dofigよりも複雑になる可能性があるという事実に関するローマの全報告書。

たとえば、人は私たちのサービスの小さな変更よりも自分の習慣に依存しています。

したがって、分離画像はそうではありません：

そしてここにそのようなものがあります：

実際、私たちの実験に来た人は非常に少なく、研究の結果は一般のすべての人に適用する必要があります。そして、これは古典的な統計タスクです。

レポートの中心的な行は、いくつかの大きな間違いです。

まったく実験しないでください
ユーザーの手でパラメーターを確認する
悪い実験が多すぎる
再計算の可能性がある実験ログを保存しないでください
測定された指標自体が時間とともに変化することを考慮しないでください（これは季節性と呼ばれます）

結果はほぼ同じです（そして、それらは前述の問題から続きます）。

私にとって、このレポートは結果としてではなく、調和のとれた推論システムとして価値があり、この資料を基礎として、この方向で独立して考え続けることができました。

そしてもちろん、数学はまだ引き上げる必要があります。

1つのスライドでレポート全体を表現しようとすると、おそらく次のようになります。

6. Arduinoを使用した電話のテスト

スピーカー ：アレクセイ・ラブレニュク、ティムール・トルバロフ。 推定値 ：4.38±0.14。プレゼンテーションへのリンク。

次のレポートは、Yandexの2人の開発者が実施しています。 Alexeyは、 Yandex.Tank 、 Pandora 、 Overloadなどに関与しています。 Timurはテレコムで4年間、Yandexで最後の4年間働いていました。

これは、ライブでの参加が判明した数少ないレポートの1つでした。私は彼に不純な動機から来ました。現代のアプリケーションがどのようにバッテリーを消費するかをgloります。この報告書の利点は、全社的にこれと勇敢に戦っている人々からの正確なものです。

大まかに言えば、サーバーアプリケーションのパフォーマンスのみをテストする方法を知る前に、今では全世界が携帯電話に切り替わっています。特に、Yandexは電話のエネルギー消費量を測定します。 AlexeyとTimurは、エネルギーメトリックをハードウェアで組み立てる方法を学んだ方法を説明します。Arduinoに基づいて電流を測定する小さな回路を組み立て、それと連携するライブラリを作成しました。彼らはライブラリをオープンソースに投稿しました。さらに、このレポートでは、電話の準備方法、テストボックスの組み立て方法、およびライブラリの使用方法について説明しています。

もちろん、これはすべて、まず第一にまっすぐな腕を持っている人にとって興味深いものです。私は、実稼働環境でこれを本当に実行できるかどうかはわかりません。これには、顕著な持続性と才能が必要です。しかし、専門家がそれをどのように行うのか不思議に思うことは常に興味深い。

レポートは、テストが実際の電話で行われる場合の複雑さから始まります。

誰がこれを必要としているのか、そして彼ら自身のエネルギーソリューションにはどのような特性があるのかについて、いくつかの研究を行ってきました。

レポートの概要は次のとおりです。

つまり、最初にマルチメーターを使用しなかった理由が説明され、次にティムールが登場し、オープンソースの内容とその使用方法を示します。

電話機でできることとできないことに関するいくつかの問題があります（およびiPhoneの1/20メトリックの意味）

ターンキーソリューションの研究方法について説明します。

したがって、彼らはビジネスに取り掛かりました！

作業中に生じた純粋なハードウェアのマイナーな問題だけでなく、

しかし、ソフトウェア開発の問題：

レポートの2番目の部分は、既製のソリューションであるVoltaとVoltaBoxに当てられています。

ソフトウェアはpip install volta

を使用してpip install volta

されます。これはソフトウェアが内部でどのように見えるかです：

実際、図は、内部のすべてが非常によく考えられていることを示すためだけにここにあります。

Timurは、これらすべてを実際に構成して使用する方法を説明します。すべてがJupyter Notebookで機能し、それからあなたの手に従ってください！

一般に、結果は次のようになります。

報告書は、エネルギー消費の測定はある種の空想や遠い未来ではないという感覚を残していますが、今すぐに行うことができます。そして、これらすべては、物理科学および数理科学の医師である必要はありません。もちろん、これは、アレクセイやティムールのような人々が私たちのためにすべてをしてくれたからこそ可能であり、私たちは既製のものしか使用できません。

5. 「エラーが発生しました」とユーザーに通知する方法

スピーカー ：アントニーナ・キサメトディノバ。推定：4.40±0.10。プレゼンテーションへのリンク。

通常のプログラマー（およびテスターも）は、幸せな道だけをテストすることを好みます。幸せではないものすべてが私の神経に乗りすぎています。したがって、通常、エラーシナリオはほとんど注目されません。

多くの場合、ユーザーがどのように感じるかを考えずに、「エラー番号392904」や「おっと、何かがおかしい」などの同じ種類のインターフェイスウィンドウを作成します。しかし、彼は動揺し、製品に対する自信を失います。さて、または路上で追いつくとビート。

このレポートは、普通の人の目を通してエラーを示しています。アントニーナは、ユーザーを怒らせないように、エラーとクラッシュを正しく報告するようにインターフェースを教える方法を教えます。

ストーリーは、エラーシナリオの概要から始まります。

そのようなシナリオを処理するビジネスを正当化する方法について少し：

これはすべて実際のお金に変換されます。

それは良いエラーメッセージです：

サポート負荷を軽減
ユーザーがコンバージョンファネルで迷子にならないようにする
製品の操作方法をすばやく教えます。
困難な時期にサービスに対する信頼を維持するのに役立ちます

さらに、さまざまなタイプのエラー、それらに対するユーザーの反応（World of Tanksの例を含む！）、およびエラーメッセージの形成に寄与するすべてのニュアンスが体系的に説明されています。

ユーザーの連絡先チャネルと、エラーについてユーザーに正しく通知する方法について少し説明します。

チェックリストの形式で、アプリケーションを改善するための具体的なヒントが提供されています。

これはすべて、非常に多くの実例で示されています。

視覚障害者向けのインターフェースなど、非常に珍しいアプリケーションでも考慮されます。

一般に、このレポートは単に集中した情報に圧倒され、すべてをこの絞り込みの形で伝えることは不可能です。

ただし、特定の中央計画を投げることができます。

グローバルクラッシュを報告する方法
特定のバグ
ユーザーエラー
接続サービスの問題
外部の問題
非常に珍しいユーザーまたはサービスの動作

最後に、生命の宇宙の主な問題が提起され、一般的に：

また、これらすべてをどう処理するか、トピックで何を読むべきかについての明確なチェックリストもあります。

「読み方」に関するスライド-90分の3。 93枚のスライド、カール！

ビデオを見た後、これは単なるレポートではなく、スマートで高度な研究の本である本だと感じました。たぶんいつか彼女は本を書くでしょうか？いいですね。

確かに、そこにあると言われたことはすべて、明らかに、そしてビジネス上、非常に有用です。 146％で適用される数少ないレポートの1つ。

4. シンプルさ、信頼、制御-Webテスト自動化の3つの柱

スピーカー ：Artyom Eroshenko; 推定値 ：4.45±0.08。プレゼンテーションへのリンク。

Artyomは、AllureおよびHtmlElementsの著者として知られています。 Webテストの自動化に関連するプロジェクトに長い間携わってきた彼は、最初のテストから数千までのプロジェクト全体を通して、彼と彼のチームにとって快適な作業を保証する一連のルールを作成しました。この一連のルールは、「開発のしやすさ」、「結果への信頼」、「品質管理」の3つのグループに条件付きで分割されています。

このレポートは、Artemとチームがテストをできるだけ簡単かつ明確に作成および編集できるようにするツールを扱っています。チーム全体でテストに合格した結果、テストの品質管理がどのように実行されるかについての信頼を得るのに役立つアプローチが検討されます。

最も正しいのは、このレポートを計画の形式で提示することです。

実際、このレポートでは170枚以上のスライドが使用されています。これについて詳しく説明し始める場合は、別のハブポストが必要になります。ハブポストは必要ありません。

全体として、次のようになります（会話がスムーズに進むため、入れ子のレベルとどこかで混同した場合は申し訳ありません）：

シンプルさ
- 開発ツール
- ブラウザで作業する
  - PageElements
  - アイテム構成
  - ページ構造
  - テストはどのように見えますか？
  - HtmlElementsのデメリット
  - Ajaxページの痛み
  - サイドチェック
  - パラメータ化の欠如
  - ロギングの欠如
  - クラスではなくインターフェース
  - パラメータ化
  - 検証試験
  - ページテンプレート
  - アイテム説明
  - 手順は実質的に必要ありません
- データ準備
  - 通常のHTMLリクエスト
  - パスパラメーター
  - クエリオプション
  - リクエスト本文
  - ヘッダーを操作する
  - テストUserServiceでの説明、作成、および使用
- テスト構成
  - テストを実行する
  - テスト構成
  - 構成の説明
  - プリミティブ型
  - 拡張タイプ
  - リストと配列
  - 複数のソース
  - 値のオーバーライド
  - WebConfig設定
  - ApiConfigの構成
  - 構成の初期化
  - テストで使用する
- 依存性注入
  - 依存グラフ
  - 基本クラスが悪い
  - 静的フィールドが悪い
  - 本当に必要なものは何ですか？
  - ProviderWebConfig
  - ProviderWebDriver
  - MainPageプロバイダー
  - モジュール構成
  - ユーザープロバイダー
  - JUnitとの統合
  - テストはどのように見えますか？
信頼
- テストにおけるチームの信頼
  - ショートテスト
    - チャートの例
      - サービスはどのように見えますか
      - テスト実行はどのように見えますか？
      - 本当に
      - なぜこれが起こっているのですか
      - 異なるエントリポイント
      - 行動する方法
  - スタブサーバー
    - 広告を確認する方法
    - フィルターの確認方法
    - 実装は何ですか
    - サービスはどのように配置されていますか
    - スタブサーバー
    - プロキシモード
    - テストの仕組み
    - テストではコードはどのように見えますか
    - そして、複数のスレッドにある場合は？
    - テストID
    - HTTPリクエストヘッダー
制御
- タイプを起動します
- グラファナ
- チャートの例
- テスト数
- テスト実行ステータス
- テストステータス
- テスト開始時間
- 再起動の回数
- 再起動とステータス
- 再起動と時間
- 起動の問題
- ファイル「categories.json」
- 問題のカテゴリ
- 設定方法
- どのように機能しますか？
- InfluxDBへのエクスポート
- InfluxDBデータ形式
- アリュールプラグイン

実際、これはこのトピックに関する最も包括的なリファレンスレポートの1つであり、追加する特別なものはありません。これは非常に大きなチェックリストであるため、一貫して従う必要があります。

TOP-3

3. Badooでの位置情報のテスト：バンプ、石、松葉杖、自撮り棒

スピーカー ：アレクサンダーホスト、ニコライコズロフ。 推定値 ：4.57±0.10。プレゼンテーションへのリンク。

ロケーションの操作は非常に重要であり、そのプロセスには事前に予測するのが難しいポイントがたくさんあります。スピーカーは、このトピックの問題とニュアンスを強調し、役立つヒントを提供し、使用するツールについて話します。このトピックに関する情報はそれほど多くないので、このレポートはほとんどの人に役立ちます。