「武装」のための5つのアイデア、またはモスクワの「ハイゼンバッグ」の印象

チケットを受け取っている会議が「面倒」にならないようにする方法は？ 私の意見では、最良の方法は、同じ主催者の会議の1つで講演者になり、自分に関するレポートの選択と準備をテストすることです。 春、私はJUG.ruグループが開催した会議で講演を行いました。それ以前に起こったことはすべて、学位の防衛を連想させます。 実行のたびに質問とコメントの長いリストを受け取った後、私のレポートはプログラム委員会によって何度か聞かれました。 委員の1人が「反対者」になり、Slackでの絶え間ない議論で、レポートで話したいことの有効性の無条件の証拠を得るために追加の実験が必要になりました。 報告書が承認されたというニュースが来たとき、それは最終的なものではありませんでした。 このテストを行った後、JUG.ruグループのメンバーは会議で混乱を許さないことを知っています。 そして、私は彼らを信頼しています。今年、彼らの会議のほとんどに参加しました。



私にとってモスクワハイゼンバッグは、繁忙期を締めくくる今年最後の会議です。 開会の挨拶でプログラムディレクターのアンドレイ・ドミトリエフが表明した統計から判断すると、ハイゼンバグの人々のほとんどはプロのテスターです。 コミュニケーションの感覚は、主に熱心なQAチームを持つ大企業で働く人々です。



私はハイゼンバグの典型的な訪問者ではありません。 私たちの会社には約25人しかいませんが、多くは役割を兼ね備えています。 私は技術リーダー、プロジェクトマネージャー、そして単なる「問題解決者」でなければなりません。テスト自動化に関与しているのは数人だけです。 当社の存続は、文字通りチームの効果にかかっています。 効率を上げることは、新しい知識を得て視野を広げることによってのみ可能です。そのために私と同僚2人はハイゼンバッグに行きました。

1日目

カンファレンスオープニング

会議の開幕から良い雰囲気が生まれました。 オープニングの際、プログラムディレクターのアンドレイ・ドミトリエフは、観客に課題を与えました。 会場はすぐに大きな音でいっぱいになりました。 とても便利な仕事でした！ 結局のところ、会議は最大限の利益を得るために巧みに使用する必要があるツールです。 会議の主な構成要素はレポートであるように見えますが、実際には、レポートに座って総利益の約40％しか得られず、残りの60％を自分で取る必要があります。 あなたがITの内向者である場合、新しい人と会話を始めるためには、自分でやり直す必要があります。 しかし、これは最初から難しいことです。あなたと同じように、ここにいる全員が何か新しいものを求めて来たことがすぐにわかります。会議でコミュニケーションをとることは本当に簡単です。



ノイズが落ちたとき、アンドレイは別のタスクを与えました。少なくとも5つの重要なアイデアを思い出すために、会議から持ち出し、次の2日間で実践することができました。 私はこれに注意し、報告は3つの部屋で始まりました。

1

最初のタイムスロットでは、 Dmitry Buzdinのレポート「オートテスト用の独自のフレームワークを構築する方法」に行きました。 理論上のISTQB汎用テスト自動化アーキテクチャアーキテクチャに基づいて、Dmitryは、テストプロセスのすべてのタスクを完全にカバーするようにオープンソースソリューションを組み合わせる方法について話しました。 個人的には、レポートには既製のレシピは含まれていませんでしたが、一方で、ISTQBモデルについて知り、テストフレームワークを構成する詳細についての知識を真剣に注文しました。







同時に、平行した部屋には、 TestContainersに関するSergey Egorovの報告がありました。 非常に簡単な理由のために行きませんでした：JEEConfで春にTestContainersに関するSergeyのレポートを初めて聞いたのは、初秋にこのテクノロジーを実装し、10月にJokerでSergeyと詳細にコミュニケーションを取り、成功しました出会った機能。 TestContainersのアイデアはシンプルで強力です。たとえば、既存のDockerインフラストラクチャとダウンロード可能なイメージを使用すると、たとえば、クラスをインスタンス化するだけで実際のOracleデータベースへのJDBC接続を取得できます。これは、ある種のHashMapほど複雑ではありません ブラウザ、データベースなど、クラスをインスタンス化するだけですぐに使用できます！ テスト環境の複雑な設定とテスト自体の構成が必要だったものは、3つの単純な要件に要約されます。マシンにはJDK、Maven（Gradle）、Dockerが必要です。 TestContainersの作成者は素晴らしい仲間であり、幸運を祈ります。

2

それから、 Simon Stewartの「Scaling Selenium」レポートに行きました。 Simonは、UIテストが成長し、より複雑になるにつれて発生する一般的な痛みの問題について話しました：脆弱なロケーター、期待、クラウドを含むSeleniumでのスケーリング。 私はこのトピックに深く没頭しているとは感じませんでしたが、サイモンが私が絶対に自宅で応募したい最初のアイデア、 「前提条件の確認」を表明したことに突然気付きました。 システムテストを開始する前に、システムが依存するすべてのサービスが実行されているかどうかを確認します。 データベース、認証サーバー、およびアプリケーションが作業に依存するその他のコンポーネントは動作しますか？ 実際、少なくとも1つが「嘘」である場合、テストする意味はありませんが、問題を明示的に停止して報告する価値があります。 そうしないと、多数の無関係なエラーがログに記録され、テスト結果自体の信頼性が損なわれます。



同時に、私の同僚のニコライは、アレクセイ・ヴィノグラドフとアンドレイ・ソルンツェフのセレニド・パズルラーを訪れました 。 クイズレポートは、あなたの心の速さで輝き、Tシャツを獲得するための素晴らしいアイデアです。 そこから戻ると、コリアは力を尽くして手を引いていると言いましたが、彼は一言も与えられませんでした。 繊細なKolyaと、通常「パズル」で起こる誇大広告を知っているので、手を強く引っ張る価値があったと思います:-) Selenideは、「裸の」Seleniumの問題のほとんどを解決する素晴らしいフレームワークです。 試してみましたが、今は別のものを使用しています。 ハイゼンバグの後、彼らは彼らの選択の正しさについて考えましたが。

3

次に、 ウラジミールシトニコフのレポート「ブラウザ側でのWebアプリケーションのパフォーマンスのテスト」に進むか、ラウンドテーブル「2018年にテスターが知っておくべきこと」に行くかを考えて、ブラウザ側のパフォーマンスにまだ依存しないことを決定し、ラウンドテーブルに。







そこにはテーブルはありませんでしたが、5人のスピーカーが並んで座っていて、プレゼンターと聴衆とテレグラムチャンネルからの質問がありました。 議論は主にテクノロジーではなく、テスターのキャリアパスと会社の組織構造についてでした-私たちのようなフラットな構造を持つマイクロ企業にはあまり関係ありません。 スピーカーは5人でしたが、ニコライアリメンコフが最も積極的に話し、1時間で複数のレプリカを挿入した方が良い人もいました。 NikolayはIT分野で最高の専門家およびトレーナーの一人であり、気の利いたかっこいい男だと思います。 しかし、この会議で彼はすでに2つのレポートを持っているので、他の人にもっと話す時間を与える価値があったのかもしれません。



私はそのようなことを理解しました。専門家のグループに尋ねたい特定の質問がある場合にのみ、「ラウンドテーブル」に行く価値があります。 「リッスン」に行くと、会話のスレッドが期待どおりに行かない場合があります。 スピーカーは、ディスカッションエリアやパーティーで特定の質問をする方が便利な場合があります。これにより、円卓という考えがかなり疑わしくなります。



しかし、この時間帯で私たちは悪い時間を過ごしたと言うわけではありません。 私が同僚の隣にいたとき、私は彼にいくつかの落ちるUIテストを見せました。そのため、ジェンキンスは私にメールで迷惑をかけました。そして来週の顧客へのショーの前に私は緊張しました。 一緒になって、これらのテストが失敗した理由をすぐに突き止め、私は会場を満足させました。 カンファレンスでは、仕事が必要な場合があります。 そして、私たちは間違いなくビデオでウラジミール・シトニコフの報告を見るでしょう！

昼食

私が言えることは皮肉にも扱われますが、昼食はあらゆる会議の質の最も重要な指標であると考えています。 一日中過ごしたり、出張に行ったり、深夜に帰宅するだけで、常に知識を得ることに集中します-これはエネルギー集約型です。 会議での食べ物は、食べ物や渇きについての考えが気を散らさないようにし、食べ物に特定の要件があるかもしれないという事実を考慮してください。 この点でJUG.ruグループはよくできており、パンクもありますが、食品の品質は良好です：Habréの電報とkamentyは、Joker 2017でキヌアについて長い間見られていました:-)今回、私が夕食にいたとき、私はそれを見つけましたすべての人はすでに明らかに満腹でしたが、テーブルはまだスナックや温かい料理でいっぱいでした。 これは私に自信を与えてくれました。 野菜とegg子とチーズの 下で魚をもう一杯食べることを否定しませんでした。その後、続ける準備ができました:-)

4

前のサンクトペテルブルクで、ハイゼンバグアンドレイ・サタリンは、C ++コード実行を分析するための特別なツールについて話しました。 私たちはJavaで書いているので、彼の現在のレポート「システムを起動せずにチェックする方法」は私たちには関係ないと思いました。 それでも、私はアンドレイ自身に行って彼に尋ねました。 レポートはC ++に限定されていなかったことが判明し、私は留まりました-そして、それを後悔しませんでした。 したがって、結論は、報告書の内容について、講演者またはプログラム委員会のメンバーで事前に指定することをためらわないでください。 あなたはすぐに答えられ、これは会議での娯楽の効率を高めます。



Andreyが述べた考え方は、同時に実装するのに安価で効果的です。分散システムの構成ファイルは、自動的に検証することができ、また検証されるべきです。 チェックできる最も簡単なことは、これらのファイルが一般に存在し、有効なJSON / YAML / XMLであることです。しかし、より複雑なチェックが可能です。たとえば、ノード/ラック/データセンターによるサービスの配信がシステムフォールトトレランスの要件を満たしていることです。 または、ホストとポートが単一のネットワークに接続されている場合、そうでない場合、たとえば、ポート設定が正しくないために、クラスターの接続インスタンスが思ったより少ないことがわかります。



しかし、私にとっては、写真は一か所にまとめられませんでした：Andreiは、構成ファイルが完成した形でバージョン管理システムにある場合について話しましたが、たとえば、構成ファイルは動的に作成され、Ansibleを使用する仮想マシンと仮想コンピューターに配置されていますそれらはもう利用できません。 ディスカッションエリアに移動し、少しの「ブレインストーミング」が解決策につながりました。ansible-playbookの実行中に別のフォルダーで構成のコピーを実行し、その直後に結果の構成の確認を開始するだけで十分です。 そして、Andreiが述べたリスクは私のプロジェクトにとって重要ではありませんが、時間が経つにつれてそれらが重要になり、これらのチェックを実装できる必要があることを知っています。 したがって、「武装」の2番目のアイデアを受け取りました。

5

次のレポートの著者であるテスト自動化の悪用と誤用、アランペイジは 、研究所でBorland C ++でhello worldを書いた当時、Microsoft Windowsエディションに参加していました。 それだけで彼に行く価値がありました。 レポートでは、「テストピラミッド」というよく知られた概念に言及しましたが、これはしばしばこのようなとんでもない「アイスクリームコーン」に退化する傾向があります。







「テストピラミッドは、できるだけ少ないUIテストを記述する必要があることを意味します」とアランは言いました。 UIテスト1）書くのが難しい、2）膨大な計算リソースを必要とし、まだ遅い、3）信頼性がない（不安定） 最も信頼性が高く、最も安価なテストは単体テストであり、最もテストが必要です。 また、バグを検出した場合、テストピラミッドの可能な限り低いレベルでテストを作成する必要があります（理想的には、ユニットテストの場合）。



それは思われる-これは非常に基本です！ しかし、私がこれほど明確な形でこれを自分で処方しなかったことは奇妙です。 したがって、テストピラミッドの本質に関する最新のアイデアは、会議の「武装」という別のアイデアでした 。

6

初日は、 ニコライアリメンコフによるレポート「開発者の観点からのテスターの分類」で締めくくられました。テクノロジーよりも組織内で効率的に働く人々に大きく依存します。そのようなレポートは、おそらくチームで何が起こっているかを誰かに目を開かせ、マネージャーが非 従業員のciency行動。

パーティー

会議の締約国は主に、報告間の休憩の時間枠に制約されることなく、仲間の専門家と会って話をすることができるように開催されます。 したがって、そこには飲み物、食べ物、そしてあなたが話すことができる非常に静かで快適な場所が必要です。 ジョーカーのような巨大な会議では、騒々しい群衆が形成され、人気のあるスピーカーの周りにフリーマーケットがあり、コミュニケーションは容易ではありません。 この点で、私はあまり多くの会議を好まず、ハイゼンバッグはこの点で良いことが判明しました。 ウラジミール・シトニコフとSQLに関連するトピックについて素晴らしい会話を交わした後、ニコライ・アリメンコフを中心に結成されたグループに移りました。 人々の問題を「修正」することは、最も複雑なバグよりもはるかに困難な作業であることに全員が同意しました。 また、ニコライと話をして、私たちの会社でプロセスの変革を実行し、目標を設定し、配送コンベアを構築する最良の方法について何かを学びました。 会話は、プロセス制御のトピックでのテストのトピックからはほど遠いものでした。これは素晴らしいことです。会議の名前に必ずしも限定されない、あなたに関係のあるトピックの専門家と通信するために会議に行きます。

2日目

1

二日目が来ました。 私は眠い最初のスロットに来て、最初の日に受け取った情報ですでに頭が腫れています。 また、何かをコーディングしてプルリクエストを行う必要がありました。 したがって、 Artem Eroshenkoによるレポート「シンプル、信頼、コントロール-Webテスト自動化の3つの柱」のホールにいましたが、私の焦点の半分はIDEにありました。 PageElementsはクールで正しいです。 Retrofitは、HTTP APIをJavaインターフェースに変換します。 ホステスへの注意：彼の改良された化身のYandex htmlelementsはgithubnik Artyom eroshenkoamから取られるべきです。



申し訳ありませんが、Artyom、私はあなたの報告の最高の聞き手ではありませんでした。 おそらく、このレポートはビデオで何らかの形で修正する必要があります。 会議のスロットの1つを見逃すことは問題ありません。すべてをキャプチャすることは不可能です。 食べ物などの情報には消化が必要です。

2

「開発者+テスター=品質++」というレポートの中で、 ニコライアリメンコフは、組織内のプロセスを改善するための闘争に関する昨日のトピックを続けました。 ニコライが「テスト部門」の存在の強力な敵対者であるのはこれが初めてではありません。そこでは、開発者はレンガの壁のように、しばらくしてテスターから製品を取り戻すために製品を「投げます」。 ニコライは、開発者とテスターの共同作業によるアジャイル機能チームの利点、およびそのようなプロセスの主なプラクティスの実装中にテスターと開発者が行うことができる「効率の主な要素」、およびその結果として、品質保証のイデオロギーから品質支援のイデオロギーへの移行について話しました。

3

私たちはJenkinsの長年のユーザーであるため、私は間違いなくOleg Nenashevによるレポート「Jenkins Pipelineとライブラリを使用したテストフレームワークの構築」に行きました。 確かに、mitapsのレポートからわかるように、私たちはJenkinsの使用レベルに遅れをとっています。JenkinsはPipelineの使用を提案していますが、まだFreestyle Jobs / Maven Build Jobsに座っています。 オレグは、平文の報告書の結論の中で、すべての仕事をパイプラインに移す必要性について話した。



しかし、オレグのジェンキンスのレポートに示されている例は非常に複雑であり、私たちが知らないGroovyコード、私たちが知らないAPIへの参照が多く、デバッグが難しいハックの印象を与えます。 しかし、一般からの質問の深さから判断すると、「最大限に」これを使用する人がたくさんいます。 単純なケースでは、エントリのしきい値はいくぶん怖いです。 しかし、Jenkinsからはそれほど必要ありません。Mavenプロジェクトを収集し、アーティファクトを公開し、同時にバージョン管理コードで完全に構成するために。 どこに行くか-これらすべてを学ぶ必要があります。githubでOlegの例を扱う必要があります。



また、レポートを残した一部の人々が、「すべてが明確であるため、TeamCityに切り替える必要があります」と言っていることも聞きました。 CIシステム間には深刻な競争があり、ジェンキンスはまだ競争していません...

4

SeveloidレポートでのPavel Senin-数百の並列UIテストは 、Selenoidシステムを使用して、信頼性が低く拡張性の低いSeleniumハブを、コンテナーでブラウザーを起動し、テストへのセッションを発行し、十分なリソースがないときにセッションのリクエストを作成する美しいソリューションに置き換える方法を迅速かつ簡単に実証しました順番に、そして最も重要なことは、自分が持っているSeleniumテストを書き換える必要がないことです。



プロジェクト作業の性質上、ブラウザーはすべてのリソースを食い尽くすことができる獣であることをよく知っているので、「ケージ」に入れて他のプロセスから完全に隔離することをお勧めします。Selenoidのアイデアは本当に気に入りました。 これは間違いなく会議からの別の持ち帰りです。 Selenoidサーバーを、社内のUIテストの共通リソースとして展開しようとします。



レポートの過程で、Pavelは彼のチームの多くに共通する組織上の問題を意図せずに明らかにしました。 組織の問題の解決策は、このハイゼンバッグの赤い線で私に渡されたものです。

5

私の意見では、 「Flaky tests」という短いタイトルのAndrei Solntsevのレポートは、会議で最高のものであることが判明しました。 彼に行って、「ええ、はい、なぜうまくいかないのかわからないテストなどがあります-私は何を言うことができますか？」そして本当に何が言えますか？ アンドレイは、このような状況をなくすための既製の簡単なレシピを提供しませんでしたが、それらとの闘争の主な領域を概説しました。



しかし、彼は彼自身の実践から、時には何ヶ月も何年も続く多くの真に探偵的な物語を語った。 たとえば、ボタンが押されなかったため、ポップアップの進行状況バーによって一瞬閉じられた「緑のボタンの呪い」。



または、最高：「Chromeがハングする理由」-Andreiが2年間丸ごと解決できなかった謎、ログ、タイムアウト、デバッグ...一度、彼が最もクレイジーな仮説をうまく行かなかったとき、娘が電話をかけましたキューブでそれを再生します。 彼はしぶしぶ仕事から気をそらし、残念ながらモニターを見ていた。 テストは約20分間放置されました。 突然、以下が画面に表示され、解決策が現れました。







アンドレイは、ニコライが話していたのと同じことを締めくくりました。開発者はテスターの仕事に参加し、「相互浸透」を通じてチームが相互に豊かになるようにしなければなりません。



プロジェクトの1つに対するテストの「フレークネス」の理由の1つは、テストベースのデータが以前のテストの結果によって「汚染されている」ことです。 ディスカッションの領域では、各テストの前に、データを含むデータベースの新しいコピーをすばやく作成する方が良いメカニズムをAndreyに尋ねたいと思いました。 近くにはこの分野で経験を積んだ人たちがいて、話し合いが行われ、数分で私たちに適した、私たちの場合に最適なソリューションを考え出しました。 そして、近い将来に実装します。これは確かに「武装のための」別のアイデアです。 そして、会議のエンジニアリングの問題を解決するのに、まさにその分野の最高の専門家が助けてくれるのは素晴らしいことです:-)。

6

会議は、 アラン・ペイジ「技術テストに関する真実」による報告で終わりました。 アランは、「開発者」と「テスター」の専門性の区別が消去される変革の世界でテスターを待っているものについて話しました。



たとえば、「テスト担当者」は確かに「UIテスト自動化ツール」であるという現在のステレオタイプは、特にテストピラミッドの原理により、できる限り少ないUIテストを記述することを強いられるため、破らなければなりません。 代わりに、テスターは開発プロセスに可能な限り統合する必要があります。 アランはニコライとアンドレイが彼の前のこの部屋で話しているという考えを直接続けているように見えたので、たとえば、ニコライは開発者とテスターのチームの間で「壁を介して製品を投げる」スライドを持ち、アランはパントマイムを投げることをばかげて描写した。



アランは、彼が開発者だったとき、新しい機能を作成したときではなく、ある種のバグを見つけたときに最大の満足を感じたと言いました。 彼の報告と会議の公式終了後、アランは会議の最後の議論エリアへの空の廊下に入り、これらのトピックについて少し話しました。

おわりに

閉会の挨拶で、アンドレイ・ドミトリエフは一般市民に「会議から持ち帰る人は何人いますか」と尋ねました。 正直なところ、私はこの時点で数えませんでした。 しかし、その一方で、私は私が最も重要な主要な持ち帰りを奪っていることを正確に知っていた、私は彼についてTwitterで書いた：