イベント概要

カンファレンス： Heisenbug 2017 Moscow

日付：2017年12月8-9日

無料放送（最初の部屋のみ）：公式ウェブサイトの放送ページ。

Habréのコメントで最も一般的な質問は何ですか？「録音はありますか？」すぐに角を叩きます。録音は、いつものように、3〜4か月後に行われます。しかし、質問をした人のうち、半数はそれを見ないでしょう。

これが起こる理由を理解するには、会議からビデオを見る方法を理解する必要があります。なぜこれが必要なのでしょうか。

ビデオは単なるショーであり、何かを一緒に議論する機会ではありません。また、最高の種類のドキュメントの1つと見なすこともできます。

開発者として、ドキュメントを書く方法はいくつかあるとは思わないことがよくあります。 Runetの出現の夜明けに、 Vlad Balin はこれについてよく書きました。

ドキュメントには、少なくとも次の種類があります。

「契約」-複数の人が重要な何かを等しく理解する必要がある場合。
「参照」は参照情報であり、頻繁に確認されます。また、あらゆる種類の国際標準、辞書、さらにはPOSIXのようなAPI記述も含まれています。これには、コード内のJavaDocとコメントも含まれます。
「学習教材」-新しい知識を構造化された理解可能な方法で伝達する。

会議レポートは、いくつかの役割を一度に組み合わせます。最初は、これは一種のライブパフォーマンスであり、トレーニングに役立つ情報が集中しています。

しかし、Seleniumの作成者がSeleniumに関するレポートを読んで、将来プロジェクトが特定の方法で開発されることを宣言した場合、これはビデオに記録された一種の契約です。あなたはそれを友達に見せて言うことができます：「ハ、見て、サイモン・スチュワート自身から、このように機能するという約束があります。」カンファレンスにライブで参加した幸運な人たちは、特別なディスカッションゾーンでこの約束について議論できます。

スピーカーがシステムの一部を完全かつ包括的に説明している場合は、将来、これを参照として使用できます。コードを作成するとき、または独自のドキュメントをコンパイルするときに、このビデオに何度もアクセスし、熟考し、修正し、そのデータを使用できます。

明らかに、レポートとそのビデオ素材には一定のライフサイクルがあります。このレポートは、開始時に最大の価値を持ちます。これは、すべての情報をすばやく簡単に吸収し、すぐに実践できるようになるときです。会議が終わった後、それは徐々に教科書から参考書に変わりつつあります。ビデオはパブリックドメインですが、これは会議の訪問者のみがアクセスできる特別なノウハウを備えたガイドです。 3〜4か月後に開いてYouTubeに公開すると、公開情報になり、友人にリンクを投げて、正確な視聴時間を示すことができます。リリースから6か月から1年で、時代遅れになり始めますが、次の会議でバトンを取り上げます。陳腐化はフレームワークと特定のテクノロジーに関心がありますが、コンピューターサイエンス、開発およびテストプロセスの構築などに関する基本的なレポートは、正確に数年間使用し続けることができます。自然界では、このようなレポートのグローバルサイクルが判明しています。

講義の形式で情報を配信し、ドキュメントと教科書を書くことの主な問題は、 通常、組織内にそのような講義を実施できる人がいないことです。または、彼らはそうですが、他の何かで忙しいです。または、彼らは単に会議の講演者ほど良くはありません-地球上のセレニウムの生きた具体例であるサイモン・スチュワートよりもセレンについてもっと詳しく話すことができる人はほとんどいません。

そのため、4か月後に会議のビデオテープを見たくなく、この会議にライブで参加したいのです。 これは完全に論理的な願望であり、提案された資料を最大限に活用する方法です。

残念ながら、誰もが世界の半分をライブで飛べるわけではありません。すべての雇用主が手放すわけではありません。最終的に、誰かが予算を使い果たす可能性があります。

時には、オフィスの大きなプラズマの前に集まって同僚とレポートを話し合うことは、ロシア語とロシア語マットのすべての力を使って、誰かを邪魔することを恐れずに、フルボイスで話し合うことがはるかに便利です。

そして時々、私は大画面の前で家に座って、大勢の人々に参加してどこかに行く必要がないようにしたいだけです。ホテルではなく、自宅で静かに眠りましょう。結局、会議は丸2日続きます。

これらの問題はすべて、オンラインブロードキャストによって解決されます。何でも何でも見ることができます。カンファレンスにライブで参加してディスカッションエリアに参加すると、カンファレンスが最大のメリットをもたらすという事実にもかかわらず、オンライン放送には多くのユニークな利点もあります。

ブロードキャストへの接続方法

以前は、YouTubeのさまざまなプレイリストへのHabrリンクに投稿し、「このリンクは1日目に、このリンクは2日目に、これは何か別のもののために」と警告していました。このハブサイトへのリンクを保持し、その更新に従う必要がありました。

もっと簡単な方法があります。こちらのリンクから、当社のウェブサイトから直接無料放送を視聴できます。

https://heisenbug-moscow.ru/online-free/

このリンクは、究極の真実の源です。そこに最新の現在のプログラムが表示されます。また、大きなオレンジ色のリンク「参加者と話し、スピーカーに質問する」があります。これは、テレグラムにつながり、参加者はそれを有料だけでなく公開放送でも使用できます。

変更履歴

会議の開発は、ソフトウェアプラットフォームの開発と非常によく似ています。私たちの言語とプラットフォームは常に競合しています。たとえば、Javaはメイン言語の構文で.NETを追いかけ、.NETはクロスプラットフォームでJavaに追いついています。新しいアイデアが登場するとすぐに、このアイデアの実装がすべての一般的なテクノロジーに登場し始めます。

会議の作成は、ソフトウェアプラットフォームの開発と非常に似ています。 JUG.ruグループには独自のプラットフォーム、基本機能のリストがあります。会議の1つで何かが改善されるとすぐに、他の全員が更新を受け取ります。今年、この秋を含め、多くの会議があり、多くのことが改善されました。

ライブストリーミングは、まさに私たち全員が望んでおり、優れた会議から期待されるものです。ブロードキャストを改善するには、多くの場合、より高品質の機器を追加して正しく構成することが非常に簡単です。したがって、この秋に受信したブロードキャストは、有用な更新の最大数になります。

音質の改善。マイクは正しく立ち上がって動作し、部屋の音響は考慮され、小さな技術的な問題は解決されます。
1440pのビデオ-スピーカーとFullHDスライド（またはライブコーディングの場合はラップトップ画面）を1つの画面に同時に表示するために追加のスペースが使用されます。非常に便利な技術機能。
ビデオを操作するためのインフラストラクチャはクラウドに移行し、機器の故障の可能性が減少しました。これはSBTG.ruで行われ、会議の記録に役立ちます。私たちは彼らの仕事の恩恵のみを享受します。
サービスインフラストラクチャもAmazonに移行しました。以前は単なるヘッツナーでしたが、高品質で中断のない放送がより重要です。
レポートの合間に、プラットフォームのスピーカーと参加者がディスカッションエリアに向かうと、オンラインブロードキャストレポートの視聴者と、スピーカーとスポンサーへのインタビューを表示します。今回はインタビューがより活発になり、2人のプレゼンターがそれらを実施します（ @phillenniumと@olegchir -Habréの投稿を定期的に見ることができます）。
多くの小さな技術的な問題は解決されましたが、大多数は気付かなかったものの、そこにありました。一般的に、放送を見ている感覚は良くなるはずです。

制限事項

公開放送では、基調講演を含む最初の部屋のみが利用可能です。他の部屋で起こっていることを見ることができなくなります。そして、多くの興味深いことがあります。次回サインアップして、制限なしですべてを確認します。
ビデオはありません。 つまり、彼らはもちろん、フィードバックを残した会議参加者のみになります。それ以外の場合は、従来から3〜4か月で投稿します。
オープン放送は現状に基づいて提供されます。すべてがうまくいくと確信していますが、突然何かがあったとしても、私を責めないでください！有料のプライベート放送の参加者には特別なサポートが提供されます-彼らはまさにサービスを購入します。

プログラム

会議は2日間開催されます。最初の日は10.00で始まり、2日目は10.30で始まります。毎日は最後の基調講演で終わります（それぞれ17.35と18.15）。最初のホールの現在の番組は放送ページで見ることができます。

初日。 12月8日。

パンドラのホワイトボックス

ニキータ・マカロフ /クラスメート

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

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

このレポートでは、これらの質問やその他の質問に対する回答を、例と視覚的なデモンストレーションとともに表示します。

ニキータマカロフ

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

テスターツール

ジュリア・アトリギナ / ALM Works

レポートの目的：同じ日に使用できるツールを表示します。これにより、手動テスト担当者や開発アナリストなどの作業が加速されます。多くの人は、手動テストは自動化によってのみ加速できると考えていますが、これはそうではありません:)

このレポートでは、より少ない時間でテスト範囲を広げることができるシンプルなツールを紹介したいと思います。対象読者：ハンドテスター、および少なくとも時々分析して自分の手で何かをする必要があるすべての人。

ジュリア・アトリギナ

彼女がALM Worksで最後に過ごした9年以上のテストで、Atlassian JIRAおよびConfluenceのプラグインを開発しました。テスターの役割は、製品所有者およびSAFeコンサルタントの役割と組み合わされます。 JIRAについて質問がある場合は、お気軽にお問い合わせください！

ブラウザ側でWebアプリケーションのパフォーマンスをテストする（JavaScript、レンダリング、それだけです）

ウラジミール・シトニコフ / Netcracker

多くの場合、「パフォーマンステスト」という言葉は、サーバー側のテストのみを意味します。ブラウザを直接テストする可能性ははるかに低くなります。単純なケースでは、Yandex.Metricaおよび/またはGoogle Analyticsを接続して、行きます。ただし、微妙な違いがあります。企業環境では、NM / GAにデータを送信できない場合があり、NM / GAを接続するだけでは、アプリケーションのパフォーマンスに関する適切な情報を収集するには不十分です。

レポートでは、ブラウザでの操作の継続時間を測定する方法を見ていきます。 Seleniumから受け取った時間が天気を示している理由を見つけ、パフォーマンスを測定するためにどのようなSeleniumテストができるかを見つけます。 boomerang.jsを見て、そのようなライブラリをプロジェクトに統合するときに探すべきポイントを見つけましょう。このレポートは、ブラウザー/サーバーの最適化の問題には対応していません。

ウラジミール・シトニコフ

彼は10年間、NetCracker OSのパフォーマンスとスケーラビリティに取り組んでいます。NetCrackerOSは、通信事業者がネットワークおよびネットワーク機器管理プロセスを自動化するために使用するソフトウェアです。彼は、JavaおよびOracleデータベースのパフォーマンスの問題に興味があります。彼の責任には、負荷測定の計画、結果の分析および説明が含まれます。 VladimirはApache JMeterのコミッターです。

システムを起動せずに確認する方法

アンドレイ・サタリン /ヤンデックス

私たちが開発するシステムは日々複雑になっています。そして、すべてに浸透する遍在する複雑さから逃れることはできないようです。この複雑さの1つの側面は構成です。一方では、構成はシステムの安定性とアクセシビリティに大きく影響し、他方では、その正確性を検証することにほとんど注意が払われません。

レポートでは、構成をどのようにテストし、プロジェクトでどの程度有用であったかを説明します。このレポートは、運用中のシステムの安定性と可用性を向上させる簡単な方法を学びたい人に役立ちます。

アンドレイ・サタリン

彼はYandexで分散システムのテストに従事しています。彼の経歴の中で、彼はまったく異なるプロジェクトで働くことができました。彼は、ドイツ銀行の通貨価格を計算するシステムであるカスペルスキーのクラウド検出システムであるMail.ruでゲームをテストしました。彼はバックエンドと分散システムのテストに興味があります。

（Ab）テスト自動化の使用と誤用

アラン・ペイジ /ユニティ

コードを記述しているテスターの場合、ほとんどの場合、作業にはテストの自動化が含まれます。特に、ユーザーのワークフローを自動化するテストの記述が含まれます。自動テストのベテランであるため（20年間、この数字は増え続けています！）、アランペイジは何度も何度も自動化を試みる試みが完全に失敗した多くのチームを見ました。それでも、彼は成功した少数のチームに参加することができました。このレポートでは、彼の知恵と実際に機能するパターン（そして価値のないパターンの束-彼も共有します）を共有します。

アランは、不安定なテストに対処する方法に関する成功した自動化戦略を示し、UI自動化の危険性を調べ、多くの優れた製品でのテスト自動化の長年の経験に基づいて他のヒントを提供します。あなたは上級テスターになることもできますし、逆にキャリアをスタートすることもできます。このレポートには、すべての人に役立つヒントがあり、そのようなヒントはすぐに実践できます。

アラン・ペイジ

アランペイジは約25年間ソフトウェアテスターとして働いていました。彼はマイクロソフトのソフトウェアのテスト方法の主な著者であり、美しいテストの作成とテスト自動化の経験：ソフトウェアテスト自動化のケーススタディに貢献しました。さらに、彼はブログでさまざまなエンジニアリングトピックに関する記事を書いていますが、彼の投稿はインターネット上のどこにでもあります。彼の最新の「本」は、「The A Word」という一般名での自動テストのトピックに関するエッセイのコレクションです。 AlanはMicrosoftに入社し、Windows 95チームの一員となり、その後、Internet ExplorerとOffice Lyncの以前のバージョンで、さまざまなWindowsリリースに取り組んできました。特に、AlanはMicrosoftでテストディレクターとして2年間過ごしました。 2017年1月、アランはMicrosoftからUnityの品質ディレクターを辞任しました。

開発者の観点からのテスターの世帯分類

ニコライ・アリメンコフ / XPインジェクション

テスターは、開発者との対立や対立についてよく話します。しかし、誰もが平和と調和の中で生活しているチームがあります。どうやら、ここで何かが間違っている？開発者自身がテスターをどのように見ているかについてお話したいと思います。面白い分類がレポートに記載されます。有名な猿のテスターに加えて、ハエのテスター、ナチのテスター、パンダのテスター、および他の多くのヒーローが紹介されます。

あなたは外からどのように見られているかをもう一度考え、おそらく状況をより良く変えることができます。このレポートは、プロジェクトマネージャーやチームリーダーにも役立ちます。テスターの行動の特定のパターンをすばやく認識し、チームワークのレベルを改善するための対策を講じることができます。さあ、それは面白いでしょう！

ニコライ・アリメンコフ

Java techlideおよびDelivery Managerの練習。 Java開発、アジャイルプラクティス、およびプロジェクト管理の専門家。複雑な分散スケーラブルシステムの開発に特化して、Javaで12年以上開発を続けています。多くの国際会議の積極的な参加者および講演者。 XPインジェクショントレーニングセンターの創設者およびトレーナー。会議の主催者およびイデオロギー家は、Selenium Camp、JEEConf、XP Days Ukraine、およびIT Brunchです。匿名開発者クラブの創設者。

二日目。 12月9日。

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

Artyom Eroshenko /独立コンサルタント

AllureおよびHtmlElementsツールの作成者によるWebインターフェイスの自動化に関するレポート。

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

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

アルチョム・エロシェンコ

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

開発者+テスター=品質++

ニコライ・アリメンコフ / XPインジェクション

アジャイルアプローチでは、テスターの品質と役割に対する態度が変わりました。現在、チーム全体がテストと製品品質を担当しています。しかし、これらのアプローチが実際にどのように機能するか、テスターが開発者とどのようにやり取りするか、タスクが要件から顧客の受け入れまでどの段階を経るか、誰が異なる段階で何をするかを想像する人はほとんどいません。

開発者がテスターと密接に連携するチームはそれほど多くありません。プロジェクトによっては、開発者の時間を節約するためにこのアプローチが回避される場合もあれば、テスターの意見の独立性を維持するために回避される場合もあります。また、開発者は、テスターが実際に何を支援できるかを常に理解しているわけではありません。それでも、この組み合わせにより製品の品質が大幅に向上し、多くの問題を回避できます。

レポートでは、開発者のテスターとのペアリング作業の動機、タスクの作業のさまざまな段階での具体的なプラクティスとアプローチ、およびそのような作業から双方が学べる利点について説明します。

ニコライ・アリメンコフ

Jenkins Pipelineとライブラリを使用してテストフレームワークを構築する

オレグ・ネナシェフ / CloudBees

Pipelineの登場により、特に並行ビルドとテストの場合に、Jenkinsのタスクを自動化するアプローチが変わりました。その中に独自のテストフレームワークを構築し、ライブラリのセットとして自動化チームに提供することができます。

Javaプロジェクトを例として使用して、QAタスク用のPipelineライブラリを構築し、プロジェクトを新しいプラットフォームに転送する方法を示します。 Docker、Maven、JUnit、FindBugs、overityを統合し、テストの動的並列化を実装します。また、落とし穴と、このようなフレームワークを効果的に開発、テスト、および保守する方法についても説明します。

オレグ・ネナシェフ

CloudBeesの開発者は、Jenkinsプロジェクトの中核チームのメンバーです。 2008年以来、彼はJenkinsおよび他の多数のツールを使用して、大規模なソフトウェアおよびハードウェアプロジェクトの自動化、インフラストラクチャ、およびフレームワークの構築に携わっています。彼はコードを書き、Jenkinsのコアとプラグインをサポートし、サンクトペテルブルクや他の都市で会議を開催しています。

Googleによる開発とテスト

Vsevolod Brekelov /グリッドダイナミクス

学習に興味のあるテスターと開発者向けのレポート：Google Cloud Standard Environmentを使用する際に発生する可能性のあるレーキ、それらを回避（テスト）する方法、プロジェクトで使用および使用できるGoogleツール。また、GAE、Memcache、タスクキュー、Objectify、Protobuf、Bazelについてもう少し学習します。

ヴセヴォロド・ブレケロフ

ソフトウェアテスト/テスト自動化で5年以上。昨年、フルスタック開発者/技術主任が働いています。モバイル、デスクトップ、Webプロジェクト（主に金融会社向け）のテスト自動化をゼロから構築した経験。ハッカソンに参加し、賢い同僚と仕事をしたい。彼は、テスト自動化エンジニア、開発者、およびアナリスト向けに多くのインタビューを実施しました（200人以上、すでにカウントを停止しています）。ここ数年、彼はグリッドダイナミクスで働いています。現在はカリフォルニアに住んでおり、Googleの契約の下で働いています。

不安定なテスト

アンドレイ・ソルンツェフ/コードボーン

不安定なテスト-自動テストの頭痛。昨日、テストは緑色でしたが、今日は突然赤色に変わりました-理由はありません。誰も何も変えませんでした。月が間違った位相にあるというだけです。マトリックスが冗談を言っています。

私の家のコレクションからの不安定なテストの実例の束を分析します。そして、テストが安定し、開発者のカルマから独立するようにテストを記述する方法を見つけます。このレポートは、テスターと開発者の両方にとって興味深いものです-セルフテストに夢中になっているか、解決できないパズルを解くのが大好きな人なら誰でも。

アンドレイ・ソルンツェフ

Andreyは、エストニアの会社Codeborneの開発者です。 Selenideフレームワークの作成者、会議で頻繁に講演を行うTallinn Devclubの主催者。極端なプログラミング、自動テスト、ペアプログラミング、クリーンコードを熱心に支持しています。

最終基調講演：技術テストに関する真実