DevOpsがあります。 すべてのテスターを発射しましょう

何かを自動化することは可能ですか？ もちろん、すべてのテスターを解雇します。 なぜ今必要なのか、「手動」のテストは残っていません。 結局のところ？



これは、DevOpsの観点からのテストの未来に関する物語です。 具体的な数字と純粋に実用的な結論があり、優れた専門家が常に仕事をしていることがわかります。 （または、何の作業もありません！シェークスピアの写真を見て、恐れてください、あなたの運命は今決定されます）。







この資料は、JFrogの開発者擁護者であるBaruch jbaruch Sadogurskyによる報告書の写しに基づいています。 レポートのテキスト版とビデオはカットされています。







みなさんこんにちは！ 上の写真でシェークスピアからの引用をご覧ください。 これは、すべての弁護士を殺すという提案であるヘンリー6世です。 それ以来、間違った職業を取り除くためのよりベジタリアンな方法があります。 私たちは誰も殺しません。



より正確には、そのような機会があります。 誰かを解雇しますか？話しましょう 。







これがヴァシャです。 ある朝、彼は仕事に来て、メイン会議室を通り過ぎます。 そこで、彼の上司は新しいコンサルタントを歓迎します。 効率コンサルタントが会社に来て、こう言います。「Netflix *のようにDevOpsを行います。 私たちは特にカンファレンスのためにシリコンバレーに飛びました。そこで、彼らはnetflixでどのように活動しているかを伝えられました。」

*免責事項：この記事では、NetflixはDevOpsの到達不可能な理想としてよく使用されます。 この使用法は一般的な言葉です。



Netflixが実際に完全なDevOpsを備えているかどうかについての議論は、この記事の範囲を超えています（ちなみに、おそらくそうではありません）。

SpinnakerをインストールしてからChaos Monkeyを起動すると、すべてが自動化されます。 そして、私たちはこれを行い、非常に効果的です。



上司は尋ねますが、テスターはどうですか。 「そして、ここでは、Netflixのように、 自由と責任があります。 開発者は自分でテストを作成します。」



そして、Vasyaは体調不良になります、なぜなら彼は彼の名刺を見て、そこに...







Vasyaは心配し始めます。効率コンサルタントが最後に来たとき、システム管理者として働いていた友人のナターシャが解雇されました。 どこでもDevOpsだから。 そして、彼はすぐにすべてが非常に悪いことに気づきます。



しかし、もちろん、ヴァシャは目を覚ます。







私の名前はBaruch Sadogurskyです。私はJFrogの開発者支持者です。 この記事の編集者は、テスターを解雇する方法を教えてくれる私の権限を誰も疑わないように、いくつかの段落を書くことを特に求めました。



JFrogはシリコンバレーの新興企業であり、最後の評価額は10億ドルを超えていました。 私たちは公式にはユニコーンであり、DevOps自動化を行っています。 当社の製品-Artifactory 、 Xray 、 Mission Controlなど -は、オムスクの食肉加工工場をnetflixに変える非常に自動化のためのツールです。



私自身はテスターではないので、たぶん、ナンセンスを言うでしょう。 このレポートが最初に読まれた会議のプログラムには、特別な指定があります-モロトフカクテルの写真。 だから、スピーカーはある種の異端を持ち込み、聴衆は燃えるでしょう。 これは私のことです。 Twitterでは、 @ jbaruchです。 すでに理解しているように、私は非常に元気な男です、私は緊急に従う必要があります。



ニュースがあります：開発者の80％がテストを書いています。 開発者はあらゆる種類の投票に満足しています。 JetBrainsは、非常に優れた開発者エコシステムレポートの状態に満足しています。 彼らは誰が単体テストを書くかを尋ねます。

• 59％が自分で書いて、
• 11％はコードに単体テストが含まれており、どこから来たのか分からない。

合計で、開発者の70％が単体テストを使用しています。 これはすごい。



開発者の助けを借りたテストについて、Hubstaffによるより詳細な研究があります。それは少し古いです-2014年。 彼によると：

• 85％の開発者が単体テストを作成し、
• 15％いいえ。
• 40％はテスト駆動開発手法に従って動作します。
• カバレッジが良好-31％の開発者が34〜66人。

開発者の大多数は、ペンでも何かをテストすると主張しています。 もちろん嘘はつきますが、統計は次のとおりです。



2011年以来、私たちのお気に入りの引用は「すべての会社はソフトウェア会社です」です。 もちろん、ヴァシャが働くオムスクの食肉工場も含まれます。 どこにでもソフトウェアがあり、このソフトウェアの誰もがお金を稼ごうとしています。 企業は何を望んでいますか？ シャベルで戦利品をRowぎます。 お金はどこから来ますか？ 満足した顧客から。 顧客は何を望んでいますか？ 新機能。 そして、いつ新しい機能が必要になるのでしょうか？ 今！



漫画本のCEOであるディルバートは、ヴァシャのボスチーフです。 彼はまた、あらゆる種類の興味深い報告を聞いた。 彼は、顧客が新しい機能を必要とする場合、新しい機能をより頻繁にリリースする必要があると考えています。 論理的です。 これを行うには、チームの摩擦を減らします。



もっと頻繁にリリースすべきですか？ たとえば、2017年にJavaはより頻繁なリリースに切り替わりました。誰もが機能を求めているため、より高速にリリースする必要があるように思えます。 6か月ごとに新しいJavaが登場します。 しかし、誰もそれを使用しません。



最近、Jokerがあり、 Javaパズルをホストしていました。 最初は、どのパズルピースを尋ねるべきかを理解するために、誰がどのJavaで誰に質問するのです。



状況は変わっていません。80％以上が、100年前にリリースされたJava 8に残っています。 誰も9番目、10番目、または11番目を取りません。







彼らが使用していない理由を理解するには、更新を行うかどうかについてどのように決定するかを理解する必要があります。 オペレーティングシステム、アプリケーション、ブラウザなど、必要なものを更新する方法を想像してみましょう。

更新はどのように配置しますか

更新が行われたという通知が届きました。新しいオペレーティングシステムをインストールしましょう。 これが欲しい？ そこに何か便利なものはありますか、それともWindows 98 Embeddedで動作するレジがありますか。他に何も必要ありませんか？



この更新が必要な場合、次の質問はそれがどれほど危険かということです。 Facebookが更新されると、スクロールが発生し、いいね！を追加できなくなります。 病院で生命維持システムがオフになっているとき、それはまったく別のことです。 リスクについて気にしないなら、更新しましょう。 リスクがある場合、問題は更新を展開している人を信頼することです。



Appleには以前に問題はありませんでした：新しいオペレーティングシステムがあります-それを取りましょう。 それは以前のことでしたが、今では更新を恐れています。以前の信頼はありません。 信頼できる場合-問題ありません。更新中です。 信頼できない場合は、テストする必要があります。



受け入れテストと呼ばれるものを行います。 ここでは、新しいJavaが登場しました。たとえば、私たちはBaiduです。 高負荷、100,500台のサーバー、クラウド、あらゆる場所のJVM。 サーバーの一部を取り、Javaの変更を開始します。 多くのエンジニアが何かをして、すべてをチェックする必要があります。 3年に1回は正常ですが、6か月に1回...乱れていますか？ 6か月間のみ確認します。 もちろん、これを新しいJavaとは見なしません。



したがって、すぐに確認できる場合は、更新する価値があります。 ただし、長時間チェックする必要がある場合は、いくつかのバージョンをスキップできます。 8番目のバージョンからすぐに12番目までクロールしても、何も起こりません。



問題は信頼されています。 信頼できない場合、更新は困難になります。 信頼の問題が解決した場合、更新に問題はありません。 機能があるか、気にしません。



Chromeを使用してください。 彼は、あるバージョンから始めて、だれにも尋ねることなく更新します。 リスクは小さいですが、まだあります。 しかし一方で、Chromeを書いている人を信頼しています。 たいていの場合、新しいChromeリリースがリリースされても、何も中断されません。 実際、信頼に問題はなく、この道を歩んでいます。







更新があります、リスクは重要ではありません、信頼しています-更新します。 そして、彼らは私たちが望むかどうかを尋ねないので、常に更新します。 これがまさに行われていることです。



netflixが新しいアップデートをリリースし、キャプションやスクリーンセーバーだけでなく、すべての退屈な場所もスキップできることを想像してください。 クールなアップデート？ かっこいい。 彼が欲しい？ したい。 機能しますか？ おそらくそうです。 極端な場合、YouTubeにアクセスし、netflixが壊れている場合は漫画を見てください。



信頼の問題は重要です。 どのように解決しますか？ 「私たち」という言葉は、JFrogの2人の共同創立者、フレッドサイモン（フレッドサイモン）、ヨアフランドマン（ヨアフランドマン）、および謙umbleな召使を指します。 この問題を解決する方法をアドバイスする本を書きました 。



CEOを説得し、Liquid Softwareを読んだとしたら、なぜ彼は更新が必要なのかを理解したことになります。 彼はコンサルタントに、より頻繁に更新する方法を尋ねます。 アジャイル！ DevOps！ DevOpsとは何ですか？

Devops

DevOpsが収益を上げるので、DevOpsが何であるかを少し説明します。 写真を見てください。これらのグループ、チーム、部門がありました。





開発者がいます。Ops-開発者が書いたものを受け取って製品に投げるシステム管理者がいます。 また、Ops開発者の中間には、テスト中のQAがあります。 つまり、開発者は座って書き、それをテスターに​​渡してテストし、システム管理者に割り当てて、製品にアップロードしました。 このために、別々の部門がありました。



ロシア語は美しいです。部門は常に分離されており、これが単語のルートです。 英語では、この魅力はそうではないので、これらの異なる部門はサイロと呼ばれます。 この単語のロシア語への最良の翻訳は、DevOopsで最高の講演者であったアントンワイスによって与えられました。 彼はサイロを「井戸」と呼んでいます。 さまざまな部門-深い井戸。 そこにいくつかの作業をロードするには、下に行ってから、そこから作業を引き出す必要があります-上昇します。 これをグループで行うのが最も便利です。 井戸から出るものをどのようにグループ化するのですか？



当然、バケツの中に。 つまり、このような「仕事のバケツ」があります。 開発者は井戸に何かを書いて、それをバケツに入れて、井戸から取り出し、バケツをテスターに​​運んで、井戸の中で彼らに降ろしました。



異なるウェル間で作業を転送するために、多くのアクションが実行されます。 この作業を保存するためにタスクをグループ化すると、これらのバケットのロードを開始します。 もちろん、バケットが大きくなればなるほど、この転送プロセスを節約できます。 したがって、バケットは大きくなります。



大きなバケットの問題は何ですか？ 彼らが長い間満たすという事実。 したがって、生産のために緊急にリリースする必要がある重要な機能がある場合、お金のある顧客がいるため、これを行うことはできません。 井戸があります。バケツにもっと集めましょう。 したがって、これを十分に満たす限り、重要な機能はすべてのナンセンスを待っています。 あなた自身が理解しているように、これは悪いことです。 これは、これらすべてのウェルを取得して混合するという事実によって解決されます。



それは私のせいではありません！ オリジナルの3色を取り、それらを重ねて配置したところ、この色が判明しました。 今、私たちはすべて何でもします。 私たちには、Shvet、Reapers、Dyurasの両方のエンジニアがいます。 これらは、開発、QA、および運用です。 彼はコードを書いてテストし、それから彼はそれをすべて実動でレイアウトしました-そのようなユニコーンです。



ユニコーンの問題は何ですか？ それらが存在しないこと。 そして、存在するものは、長い間netflixに雇われてきました。 したがって、混合物を作ることは私たちに残っています。

混合物

共通の文化、共通の目標があります。 私たちは井戸を去りました、私たちはすべて一緒になりましたが、まだ深い専門性があります。 開発者はOpsよりも開発者であり、テスターは開発者よりもテスターです。 それにもかかわらず、彼らはすべてを理解しています。 彼らは、自分が何をしているか、なぜそれをしているのか、どのように機能するのかを理解しています。



つまり、T字型の人々、「文字Tの形をした人々」がいます。



彼らは深い専門性を持ち、何をしているのかをよく知っています。 彼らは非常によく知っていて、他のすべても知っています。 たとえば、開発者は、正しくテストする方法、製品のレイアウト方法などを少し理解しています。



DevOpsは：

• 現在共通の目標を持っていることの文化、私たちは一緒に何をするかを理解しています。
• より頻繁にリリースする自動化。

スピードと品質

速度と品質の間に反比例の関係があるという仮定について話しましょう。 大まかに言えば、リリースが速ければ速いほど、品質は低下します。 逆もまた同様です。急いでいない場合は、すべてを徹底的にテストする時間があります。 トレードオフがあります！



この依存関係が本当に存在するかどうかを理解するために、科学論文に目を向け 、DORA組織からのDevOpsの状態レポートについて話しましょう。 このレポートをよくご覧になることを強くお勧めします。



彼をどれだけ信頼できますか？ 報告書によると、5年で5000人以上がインタビューされ、2018年には約2000人がインタビューされました。 これは非常に大きなサンプルであり、そのような量に基づいて、たとえば、米国の選挙で予測が行われます。 したがって、研究は信頼できます。



さらに、DORAを率いるニコールフォースグレンは、私たちとは異なり、科学者なので、すべてが深刻です。 DORAがこの逆相関について教えてくれることを見てみましょう。



まず、すべての回答者を低パフォーマンス、中パフォーマンス、高パフォーマンスの3つのグループに分けました。



さらに、エリートがいます。 これはNetflixです（実際には上記の免責事項を参照してください）。







ご覧のとおり、比率は変化しています。 当然、5年前には低パフォーマーが多くいましたが、今では高パフォーマーがさらに多くなっています。



これはなんとなく奇妙です。 低以上のハンドルでMediumがテストされていることがわかります。 なんで？ はい。Lowは何もテストしないためです。







Jカーブと呼ばれるグラフであるトレンドには、速度と品質の相関関係または逆相関関係が示されています。 そして、ここではすべてが非常に奇妙です。 ある時点で、この逆相関の確認が見られます。 つまり、リリースが速ければ速いほど、品質は低下します。



しかし、相関は逆ではなく、直接です。 リリースが早ければ早いほど、品質は向上します。 私たちが中型で、ペンでテストするとしましょう。 すべてが悪いわけではありませんが、ゆっくりです。急いでいない場合、すべてをより良くテストできると信じているからです。 次に、DevOpsのコンサルタントが来て、次のように言います。「それで、今は自動化しています。 そして、テスターは必要ありません。 すべて順調です。」



しかし、テストがなければ、それは一種のナンセンスです。 すべてをテストする必要があり、正しく自動化する必要があることに気付いた後、正しく自動化を開始し、空の高さを目指して努力を続けます。







多くのバグが発生するこの失敗は、正しく克服する必要があります。 どのようにそれに入るか、私は質問がないと思います。 問題はそこから抜け出す方法です。



手動テストなしで生活する方法の質問に答える必要があります。 答えは、サーバーを設定せずに生きる方法の質問と同じです。 明らかに可能です。 何が変わっていますか？



以前は、製品を製品化するシステム管理者がいました。 彼は座って、開発者が書き終わるのを待ちました。 その後、彼はこの製品を取り、CD-ROMを挿入して配線を貼りました。 この時点で他のすべての人はどうなりますか？ 他のみんなが待っています。 これはボトルネックのプラグです。







適切な自動化でこれを解決します。 プロセスを自動化し、事前に準備されたパイプラインを用意し、書き込みが終了するとすぐに製品が自動的に展開されるようにしました。 今、これらの人々は必要ないということですか？ いや これは、それらが必要であることを意味しますが、彼らは別のことをしています。



テストでも同じです。 製品をテストするテスターがいます。 彼らは製品を書くまで待ちます。 書いた-それはテストする時間です。 テスト中に他の人は何をしますか？ 彼らは何もしません、彼らは待っています。 これをどうやって解決しますか？





繰り返しますが、適切な自動化。 私たちはプロセスを構築しています。 彼は製品の品​​質を保証します。 このプロセスを事前に準備しておくと、製品が自動的にテストされます。

• これには、たとえば、 部門横断的なチームが必要です。 ここで井戸から立ち上がって一緒に座った。 羊と一緒に横たわるライオンができました。テスターはプログラマーと協力します。
• 継続的なテストを行っています 。 自動テストに似ていますが、よりスマートです。
• 開発プロセスでは、 「脳テスト」が行われます。 手動テストは手ではなく脳に関するものであるため、これは「手動テスト」よりも正しい用語です。 FacebookのAlexey Vinogradovの双子にこの言葉をありがとう。 脳のテストは開発プロセス中に行われます。 何かが表示されるとすぐに、そのフローを確認することがすでに可能になり、それがどのように機能するかをすでに理解できます。また、いくつかのコーナーケースの概要を示し始めることができます。
• 現在、開発者をフォローしています。 彼が最初にテストを書いていない場合、私たちは彼に顔を平手打ちすることができます。 これはテスト駆動開発です。
• 瞬時のフィードバックが重要です。 何かが壊れるとすぐに通知するパイプラインが必要です。 すぐに行ってすぐに修正する必要があるからです。
• デザインへの参加 。 何かを見て、このたわごとをどのようにテストするかを考えることが起こります。 しかし、すみません、誰もがたわごとがあると決めたとき、あなたはどこにいましたか？ あなたは会議に来て、同意しないと言って、無意識にそれをしなければなりません。 後でテストできるようにするには、設計に関与する必要があります。
• ツール、ハーネス、スタンド -あなたが今日することの多くはどこにも行きません。 それどころか、これはもっと多くなります。 したがって、誰かがこれを書く必要があります。
• カオスエンジニアリング 。 特にWindows 95にATMのネットワークがある場合は、本番環境でChaos Monkeyを起動することを常に夢見ていました。ここにチャンスがあります。
• そして最後に、 テストを設計するために無知を教える必要があります 。 開発者は少なくともテストを書いていると主張することにしました。 今、彼らにテストを書かせてください、我々に彼らにそれをする方法を教える必要があるだけです。 誰が彼らに教えますか、彼らはどのようにテストを書くかを知っていますか？ あなただけ。 誰もいない。

すべてを自動化するために残っています。 実際、テストを自動化できます。 問題は、特定の部分を自動化できることです。









, , , 0 , 99999999999 , , -1 … , asdfgh, .



. , . , . . — , , .







, , , , . . , , , — , , , . , , , , , . , , , .



, , , . DevOps. , . T- — , .



, - . « », , . , , , . , Selenium . , .



, .







— . , , . . , , Ops- , , , , , , , .







Developers in test — , , . , . , ; — , ; TDD , , , , . , , .







« ». , , , , , — . , , , , , , , , , , Continuous Testing .



end-to-end , . , , DevOps, .



, - , . , 70- : « DevOps, ». , , .



. -, , , , , . : ( EVP Engineering, SignalFx) , , .



70- . . , , . , . , , , , . , , , , — , netflix .



, , , , , , , , , . . , .



, . . « , », — , , .







«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».



, — , . , . ? 今！







DORA: , , , .







New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .



.

Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).