あるべきかどうか：モバイル開発でのテストに関する議論

Androidのミートアップでは、10〜15分間の短いディスカッションを手配しました。そこでは、Avito、Citymobil、Revolutの専門家と一緒に、さまざまなプロジェクトでのテストの必要性についてさまざまな見解を共有し、回帰とユーザーのテストについて話します。



ビデオを見て、トランスクリプトを読み、コメントに声の質問についてあなたの意見を書いてください。一緒にそれを理解しましょう：あるかどうか？

一番の議論

タイムコード



0：56-テストは常に必要ですか？

2：00-機能をできるだけ早く市場に展開する必要があるかどうかをテストするのはなぜですか？

3：24-基本的な機能またはアプリケーションの一部のみをテストすることは可能ですか？

5：29-機能をテストするための基準

7：28-スタートアップまたはアウトソーシング会社が機能のリリースを停止し、テストに時間を浪費し始めるべき時点

会合はすぐに熱いものから始まりました-議論で。したがって、オンラインディスカッションの参加者を紹介します。

• スピードチーム（Avito）のリードエンジニア、DmitryVoronin。
• Yuri Chechetkin、モバイル開発者（Revolut）
• Dmitry Manko、Android開発者（Citymobil）
• Nina Semkina、シニアプログラマー（Yandex.Money）
• ウラジミールジェノビッチ、リードプログラマー（Yandex.Money）
• ドミトリー・ザコフ、テスター（Yandex.Money）

Nina Semkina：多くの人がテストをプロジェクトに導入する必要があると言います...しかし、誰もがそれが非常に高価であることを理解しています。開発者の時間とすべてのコードをテストでカバーする大量のリソースを費やすのは非常に費用がかかります。テストは常に行う必要がありますか？



ドミトリー・マンコ：何をテストするつもりですか？



Nina Semkina： Androidアプリケーション。100％テストする必要があることをいつ理解する必要がありますか？



ドミトリーマンコ：市場が機能の出現を期待していない場合、開発の観点またはカバレッジの観点から、テストを簡素化するか、完全に無視することができます。それはすべて製品によって異なります。 2つの機能を備えた計算機を作成している場合、一連のテストケースを複数回実行した可能性があります。したがって、テストを省略でき、アプリケーションをより早く市場に出すことができ、市場投入までの時間を短縮できます。



ニーナ・セムキナ：私たちは常に市場投入までの時間の競争があり、市場は常に多くの機能を必要とし、それらを遅くすることはできません。特に、今すぐ市場に出す必要のある、まだ始まったばかりのプロジェクトに関しては、名前がなく、他社と競争しています。現時点でテストについて何を気にしますか？アプリケーションに機能を提供し、それらをより早く破棄する必要があります。そうしないと、3週間で廃止されます。なぜそれらをテストするのですか？



ドミトリーボロニン：実際、ある時点での開発速度は、テストの対象範囲に依存し始めます。たとえば、ビジネスがすべての主要機能が存在する1つのメイン画面にアーキテクチャ的に関連付けられており、そこで何度も変更が加えられた場合、テストを行わなくても、大きな「機能パイプライン」があっても、ゆっくりと移動を開始できます。しばしば退行に戻るという合図があるとすぐに思われます。つまり、コーティングに何か問題があり、反応的な行動をとっていないという事実について考える理由です。たとえば、何かが壊れることがよくあります。これは、この場所が適切にテストされていないことを意味します。



ニーナ・セムキナ：基本的な機能のみを常にテストする必要があり、機能は「1つのポイントで」接続する必要があるという結論を下すことができますか。これらの個別の機能にはバグがありますが、おそらく今日は存在し、明日は存在しません。アプリケーションの一部のみをテストできますか？



Dmitry Manko：重要な部分はテストする価値があると言いたいです。この製品のビジネスの観点から重要なこと。また、バグのある機能がある場合、それらは別々の場所にあり、共通の何かに影響を与えないので、理想的にはリモートトグルでそれらを閉じます。また、分析によると、実際にバグがあり、ユーザーが不満を言っていることがわかった場合は、この機能をオフにしてください。



ドミトリーボロニン：Dimaは、開発者が持っている品質管理ツールはテストだけではないという良いトピックに触れました。ユニットテストと統合テスト、手動テストに加えて、監視があり、監視する必要があることを常に覚えておく必要があります。また、変更をロールアウトおよびロールバックする方法があります。これらすべてのエンジニアリング手法がある場合、速度がこれから恩恵を受けるのであれば、原則として、いくつかのツールを無視して他のツールを優先することができます。しかし、一般に、開発者がテスト文化を持っている場合、それは常に良い形式と見なされます-彼が実行しなければならない機能をテストするために、変更を提供することがより快適で信頼性が高いということです。私たちの会社では、そのようなコードを残しておくのが通例です。このコードでは、簡単に変更を加え、テストをすばやく実行して、すでに起こったことを台無しにしていないことを理解できます。



Nina Semkina：チャットで、彼らはあなたが何が収入をもたらすかをテストする必要があると書いています。また、テストコストが機能していない機能による損失よりも少ない場合。原則として、これは正確にテストする必要があるものを理解するための良い基準です。特定の機能をテストするための他の基準を挙げてください。



Dmitry Manko：基準は分析を使用して特定できます。たとえば、最も頻繁に使用される機能を修正する場合は、ユーザーがバグに遭遇しないようにそれらをテストすることもお勧めします。バグがまれな場所にある場合、これは小さな問題です。また、禁止が承認画面に表示されている場合、それは重大ではないかもしれませんが、それでも誰もが目にするバグです。そして、これはすでに評判のリスクです。



ドミトリー・ザコフ：一般的にテストが必要です。テストは、製品に課す要件のテストであることを忘れてはなりません。何かが要件を満たしていない場合、これは問題、バグ、問題です。すべてのテストケースとテストは自動化できます。十分な時間がない場合は、最初に重要な瞬間をチェックし、次に他のすべてをチェックする価値があります。たとえば、明日のリリースがあり、ビジネスが明日の機能を必要としている場合は、最も重要な機能を確認します。また、十分な時間があれば、中程度のローケースをチェックする余裕があります。テストが手動か自動かという問題です。メトリックであろうとUIテストであろうと、ロボットによって完全に検証可能です。



ニーナ・セムキナ：私たちは今、多くのリソースと機会を持つ大企業を代表して話し合っています。そして、時間とリソースが限られている中小企業や新興企業の視点を考えれば。最初は誰もがそこでのテストを犠牲にするだろうと思います。これが、機能のローリングを停止および停止し、テストにリソースを費やす必要がある重要なマイルストーンであることをどの時点で理解できますか？



ドミトリーマンコ：私はアウトソーシング会社から来ているので、私の意見を共有することができます。アウトソーシングは主に人員がどこで売られるかについてであり、テストはそこで本当に高価です。機能自体の開発よりもコストがかかる場合があります。このようなアウトソーシング会社は、顧客がアプリケーションを待って「サイドでキック」する場合、テストで有名ではありません。私たちのチームでは、次のような状況に直面しています。この商品はバー向けのメニューで、プロモーションが多数のケース（誕生日、2対1、学生など）で使用されていました。そして、このストック機能が1年間毎月壊れていることに気づきました。そして、ユニットテストは理想的にはすべてのケースを説明しました。すべてがどのように機能するかを理解しました（約70のテストケースがありました）。私たちはこの製品を打ち負かしましたが、もちろん、どこでもこれを行うことは不可能です。



ユリ・チェチェトキン：フィンテックで大企業（Yandex、Alfa-Bank、Revolut）で働いた私の経験では、バグの重大度はスケールから外れています。そうは言っても、私はスタートアップの経験があり、そこでもテストは絶対に必要でした。開発者が自分のコードに責任を負わなければならず、テストはこのコードが機能することを保証するものであるため、スタートアップであるかどうかは問題ではないと思います。開発者は主に、開発中の製品を担当するエンジニアです。したがって、テストを作成する必要があるのは、必要だからではなく、役立つはずだからです。これらがショー用に作成されたテストである場合、これにより開発が遅くなる可能性があります。また、テストが必要で、それを自分で理解している場合は、テストを作成する必要があります。開発者がコードを作成し、それがテストなしで機能することを確信している場合、これはリスクであり、彼の選択です。しかし、私はまだ思います開発者はそのリスクを冒してはならず、自分自身をカバーし、すべてをテストでカバーする必要があります。



Nina Semkina：それで、どういうわけかコードをテストする必要があると判断しました。このトピックをより詳細に分析します。私は今、ウラジミール・ジェノビッチに彼の報告で発言権を与えます。

2番目の議論

タイムコード



0：09-リリース前にQAから回帰負荷を取り除く方法は？企業にはアプリケーションの安定性を向上させる戦略がありますか？

4：25 -UIテストでモックまたは偽のオブジェクトを使用することは理にかなっていますか

8：05-ユーザーでのテスト：許容できるかどうか？

ニーナ・セムキナ：レポートの中で、チャットで質問がありましたが、彼から話し合いを続けたいと思います。リリース前にQAから回帰負荷を取り除く方法は？テストする場所を選択する際に、スピーカーはどのような方法を使用しますか？企業には、アプリケーションの安定性を向上させ、QAスペシャリストをオフロードする戦略がありますか？



ドミトリー・ザコフ：私たちの戦略は、すべてをテストすることです。私たちはユーザーの前の従業員として、最後のフロンティアだからです。したがって、このようなアプリケーションのみをクライアントに提供します。これは、いつでもどこでも安定して動作します。唯一の問題はスピードです。当初、手動実行には長い時間がかかりました-最大1週間。しかし、自動化のおかげで、リリースは平均24時間続くことが達成されました。したがって、機能を開発している場合は、自分またはテスターのいずれかがすぐに自動テストを作成することに同意する必要があります。また、自動化できないモバイル固有のケースの中には、回帰時にチェックするだけでよく、ロボットが残りをチェックするものもあります。したがって、テスターをアンロードし、テスターはより興味深い研究作業に従事し、ロボットにルーチン全体（スクリプトをクリックする）を与えます。



Yuri Chechetkin：ほとんどの大企業は、QA、手動テストを拒否しています。これはまさに革命的な道ではありませんが、過去のちょっとした遺物です。そして、例えば、私が今働いている私の会社では、回帰のような言葉は発音さえされていません。 QA部門はありません。



ウラジミール・ジェノビッチ：おそらく自動化したのですか？



Yuri Chechetkin：正確には、彼はプロジェクトの初期段階に過ぎず、その後、まったくいなくなっていました。



ウラジミール・ジェノビッチ： UIテストを実行しますよね？



Yuri Chechetkin：もちろん、UIテストはあります。



ウラジミールジェノビッチ：そしてユニットテスト？では、リリース時にこれらのテストを実行することは回帰ではありませんか？



ユリ・チェチェトキン：はい、これは回帰ですが、私たちが話していることに慣れている手動テストはありません。そして、それは非常に興味深いアプローチです。それは、開発者を落ち着かせ、コードを書いてテスターに​​渡す「子供」から、彼自身のコードを担当するより成熟した独立したエンジニアに変えます。視覚的なものに関しては、レビューはデザイナーまたはPOが行うことができます。そして、スクリーンショットテストのようなものがあります-Facebookのように。ですから、今や食品会社はQAなしでできるようです。そして、テスター自身がもっと面白い仕事をすることができます。もちろん、アウトソーシングには少し異なる話があります。彼らは人時間を販売し、QAは追加サービスとして販売することができます。



ドミトリー・ザコフ：あなたには退行があり、それは単に自動化に引き継がれ、あなたのアプリケーションの研究作業に従事している人々がいることがわかりました。テストはUIだけでなく、異なる場合もあります。



Yuri Chechetkin：はい、たとえば、ユーザーのテストです。



Nina Semkina：この非常に危険なトピックに触れる前に、リスナーからの次の質問を読みたいと思います。 UIテストでモックまたは偽のオブジェクトを使用することは理にかなっていますか？



ドミトリーボロニン：それは理にかなっています、そしてそれらなしではどこにもありません。完全に統合されたUIテストは非常に信頼性が低いためです。また、30のシステムがあり、それぞれがプルリクエストの実行に失敗したポイントが多数あるテストに依存することはできません。そのようなテストは実行可能ではありません。そして、どの会社の誰もそのようなことを機能させることができませんでした。したがって、UIテストはモバイル開発の悩みの種です。可能であれば、UIなしでテストすることをお勧めします。しかし、私たちはフレームワークと一緒に暮らすことを余儀なくされており、唯一の選択肢はある種のロボティクスであり、iOSではこれでもそうではありません。そして、私たちにとって重要なシステムの少なくとも1つとの相互作用をチェックするために、すべてをデバイス上で実行します。開発が未熟であるため、ユーザーがどのようにクリックしたかを確認するために可能な限りキャプチャしたい限り、UIはここにあります-私たちはとても落ち着いています。私にはそう思われる、しばらくすると、これは過去のものになり、モックやクリックを恐れなくなり、システムと戦ってすべてをチェックすることはありません。とにかくすべてをチェックするわけではないからです。 UIテストではチェックされない視覚的なバグがある可能性があります。したがって、UIテストでのモックは実行可能であり、実行する必要があると思います。これの主な目的は、このツールの安定性を高めて、便利な状態にすることです。そして、この場合の本当の利点は、回帰がないことを確認することです。そして、フラッシュする楽器は、信頼をやめると、ウラジミール・ジェノビッチの前回のレポートから2番目の「D」に変わります。これは、膨大な数のランダムな値がテストに到着し始めたときに発生します。そして、そのようなテストは自信を与えませんが、何かがテストされたという誤った希望を与えるだけです。



Dmitry Zhakov：私たちのケースの約70％は自動化されており、アプリケーションで単一のモックを使用していません。それらをバックエンドに移行する方が簡単な場合があります。たとえば、カード番号を参照している場合、3DSが要求されないことが期待されます。つまり、アプリケーションはロックされていることを認識していません。これはインフラストラクチャの問題だと思います。



Nina Semkina：次のレポートに進む前に、1つの滑りやすいトピックであるユーザーテストについて説明したいと思います。多くの人がこれに罪を犯します：彼らは常に欲しがり、注入します...あなたはこれについてどう思いますか？ずる賢いユーザーにロールアウトし、ユーザーからクラッシュを収集して、自分で修正できるようにすることは可能ですか？そして、それらをテストした後、優れた本格的なバージョンを展開します。それとも一般的に許可されていませんか？それとも合理的な境界がありますか？



ユリ・チェチェトキン：私たちRevolutは、直接戦闘に参加するのではなく、実際のユーザーに対してこれを少し練習します。デモはユーザーに対するテストでもあり、デモ中にフローなどに関する質問が発生します。この段階で、設計と一般的なメカニズムについて質問があるかもしれません。とりわけ、内部ローリングがあります。会社は大きく、1000人以上であり、同僚の間でロールアウトできます。これはユーザーテストですが、外部ではなく、安全のようです。そして、外部の実際のユーザーのごく一部にロールアウトできますが、トグルでこの機能を閉じることができます。これらの段階で何がうまくいかないと思いますか？



ドミトリーマンコ：私たちの現実では、物事はうまくいかない可能性があります。これらの段階をうまく実行しようとしても、クラッシュ分析を監視する必要がある場合は、いずれにせよ、ケースが急増します。リリースは、ストアに送信したという事実で終了するわけではありません。すべての段階が経過し、すべて問題ありません。アプリケーションがどのように動作するかを監視し続ける必要があります。



Yuri Chechetkin：もちろんそうです。私たちの場合、手動テストの代わりに、デモ、内部ロールアウト、および5％のユーザー向けのテストがあります。もちろん、機能のリリース後は確認する必要があります。ローリングはすぐに100％であってはなりません-これが主要な防御メカニズムです。



ドミトリーボロニン：ユーザーテストの倫理的な問題は、Googleが処理します。 Appleはこれを持っていないようです。ご存知のように、特別な流通チャネルがあります（アルファ、ベータ...プロダクション）。誰でもベータテストに参加でき、理解しやすいフォームに同意します。これは、不安定なバージョンの製品を受け取る可能性があることに正直に同意していることを示しています。そして彼はボランティアをして会社が製品をより良くするのを手伝いたいと思っています。これについて公然と人に話すとすぐに、この問題は削除されるべきであり、100％確実ではないバージョンをそこに展開することを恐れてはいけないと思います。そして、そこからフィードバックがあればさらに良くなり、そのような不安定なリリースごとに、このプロセスを改善します。企業がベータ版の品質傾向を追跡するプロセスを持っている場合、状況は改善されるはずです。そして、これはユーザーにとってもプラスです-彼らは機能を最初に受け取るでしょう。これらは主にあなたの製品に意欲的で忠実なユーザーであり、彼ら自身がアプリケーションに現れる新しいものをテストしたいと思うでしょう。そして、彼らはそれのために何かを犠牲にする準備さえできているでしょう。



Nina Semkina：忠実な聴衆について話すとき、それが個人的な利益に影響を与えない限り、それは忠実であることを私たちは理解しています。これは、追加の小さなパンで機能を展開する方法です。それらが落ちても、これらのユーザーはそれほど動揺しません。しかし、この人がテストバージョンを取得する準備ができていることを確認したが、何か深刻な問題が発生した場合（たとえば、余分なお金が帳消しになるなど）、彼はもはや忠実ではなくなります。そして、会社が大きくなればなるほど、ユーザーは製品についてより厳しく反応します。



ウラジミールジェノビッチ：しかし、会社がどのように混乱したとしても、あなたを愛している早期採用者はどうですか？そして、おそらく、この会社は損失を取り戻すことができるでしょう。同意します。何かを展開する場合は、ユーザーに次のように言います。「聞いてください。私たちは非常に恐れています。そして、あなたは1000ルーブルを失う可能性があります。しかし、私たちはあなたに払い戻しをします。」ほとんどの場合、そのようなユーザーは自分の危険とリスクでそれを行い、お金が失われた場合、後で彼に「まあ、あなた自身が責任を負わなければならない」とは言いません。したがって、バンキングアプリケーションの場合でも、ユーザーを支援できると思います。



ドミトリー・ザコフ：また、ベータテスターが少なすぎる場合は、構成を使用してA / Bテストを使用して一部の機能を有効/無効にできるため、クラッシュが発生した場合は、すぐに何かを無効にして、必要に応じてテストできます。私たちが覚えているように、モバイルでロールバックするのは非常に難しいので、リリース前にすべてを最大限にチェックすることをお勧めします。



ウラジミール・ジェノビッチ：またはReact Nativeで書いてください））



ニーナ・セムキナ：次のレポートの時が来たので、会話を中断します。ディマ、私はあなたに床を与えます。

3番目の議論

タイムコード



0：05-回帰テストを改善する方法は？機能の開発でテストはいつどのように導入されますか（Avitoの経験）

10：43-ユニットテストはどこで追跡されますか：CIで、またはプッシュする前にローカルで？

Nina Semkina： Dima Voroninに連絡して、彼の意見と、会社での回帰テストをどのように改善したか、機能を開発するときにテストを導入したときの経験について聞いてみたいと思います。



ドミトリーボロニン：私は本当に共有する何かがあります。これは、手動回帰に対処してきた5年の歴史です。そして、これは部分的に、最初の2つのレポートの間にあった質問への回答の続きです。この質問は、手動で回帰した場合の対処方法についてです。誰もがRevolutの経験を繰り返すことができるわけではないからです。彼らは素晴らしいです、彼らは肩から切りました、そして彼らはそれを確実に行うことができました。多くの勇気と優れた開発文化が必要であり、最も重要なことは、このアプローチに夢中にならない開発リーダーを理解することです。これは、私たちの仕事に慣性があり、特に大企業では、基盤を変更することが難しい場合があるために発生します。 Revolutの例は、それが機能する場合、少なくとも手動の回帰よりも高速であり、すべての開発者が自分自身に正しい質問をし始めることを証明しています。つまり、彼はリリースサイクルの大部分を担当し始めます。つまり、変更をコミットする瞬間までではなく、他の成人エンジニアと同様に、リリース段階でも製品を主導します。



私たちに何が起こったのですか？私たちは、5人が12営業日にわたって手動でリグレッションを実行し、それがないとモバイルアプリが回転しなくなった時点でした。 2015年でした。そしてその時点では、自動化されたUIテストは1つもありませんでした。ユニットテストはほぼ最初から作成し、非常に積極的に作成しました。ウラジミールは彼のレポートで約10秒と1000回のテストについて話しました-2014年にそのような瞬間を過ぎたときを想像するのは怖いです。現在、12,000のユニットテストがあり、10秒もかかりません。これも、無料のピースではありません。すべてのエンジニアがテストを理解して作成しているにもかかわらず、トリッキーな瞬間がありました。これらすべてのユニットテストは、本番環境のバグとアプリケーションの動作について1グラムを証明するものではありません。つまり、テストは動作をキャプチャし、変更を加えやすくし、フィードバックを提供します。あなたはそれを正しくやっていますか？問題は、QA部門があることです。もちろん、これは問題ではありません。問題は、彼らが一定レベルの品質を提供するタスクを持っているということです。そして、彼らはこのレベルに到達することに慣れており、この責任を負います。そして、それがあなたの製品の最初から来ていなければ、この瞬間を変えることは困難です。どんなレシピがありますか？最も正しいことは、全員を解雇し、すべてが自動化によって引き継がれるときにハードモードをオンにしないことです。これはおそらく私が見た中で最も恐ろしく、最も未熟なアプローチです。それのどこが悪いんだい？まず、テストの品質はしばらくの間失われます。第二に、すべてのプロセスが破壊され、新しいプロセスが迅速に構築されません。そして、彼らはこのレベルに到達することに慣れており、この責任を負います。そして、それがあなたの製品の最初から来ていなければ、この瞬間を変えることは困難です。どんなレシピがありますか？最も正しいことは、全員を解雇し、すべてが自動化によって引き継がれるときにハードモードをオンにしないことです。これはおそらく私が見た中で最も恐ろしく、最も未熟なアプローチです。それのどこが悪いんだい？まず、テストの品質はしばらくの間失われます。第二に、すべてのプロセスが破壊され、新しいプロセスが迅速に構築されません。そして、彼らはこのレベルに到達することに慣れており、この責任を負います。そして、それがあなたの製品の最初から来ていなければ、この瞬間を変えることは困難です。どんなレシピがありますか？最も正しいことは、全員を解雇し、すべてが自動化によってキャプチャされるときにハードモードをオンにしないことです。これはおそらく私が見た中で最も恐ろしく、最も未熟なアプローチです。それのどこが悪いんだい？まず、テストの品質はしばらくの間失われます。第二に、すべてのプロセスが破壊され、新しいプロセスが迅速に構築されません。テストの品質はしばらくの間失われます。第二に、すべてのプロセスが破壊され、新しいプロセスが迅速に構築されません。テストの品質はしばらくの間失われます。第二に、すべてのプロセスが破壊され、新しいプロセスが迅速に構築されません。



私たちは何をしましたか？回帰を置き換えるUIテストを作成することから最適化を開始しました。つまり、これらは、テストユーザーとバックエンドに接触する本格的なインフラストラクチャテストです。そして実際、この作業の結果は、ご存知のように、あらゆる種類の人気のあるフレームワーク、たとえばKaspressoでした。これはまさに私たちが始めたときに置いたものです。開発者を支援できるアーティファクトをたくさん残しました。そのため、今すぐテストを開始する方が簡単です。また、さまざまなランナーをオープンソースに配置し、誰もが私たちがどのように彼らと協力しているかを見ることができます。しかし、手動テスト、その最適化、およびこれら2つの部門が1つの効果的なプロセスに統合され始める方法について忘れていませんでした。おそらくポイントBはRevolut状態です。しかし、他の多くの企業と同様に、ポイントAからポイントBへの道は長い時間がかかります。現在、QAが研究者の役割を果たしている段階にあり、彼らは製品にもっと没頭し、機能要件に取り組み、自動テストを作成します。



手動回帰を改善する方法で最も興味深いのは、影響分析です。つまり、「このリリースで何が変更されたのか」という質問に答える試みです。そして、何をテストし、何を安心して次の段階に展開できるか。影響分析は難しい質問です。リリースサイクルが長い場合、つまり2〜3か月間リリースされた場合、影響分析は常に同じように答えます。そのような間、アプリケーションのどの部分にもほとんど触れられていないためです。しかし、このリリースサイクルを1週間、さらには1日に短縮すると、影響分析は非常に適切なことを示し、手動回帰の最適化に役立つマークを残します。私たちはこの慣行を非常にうまく適用しました。最初は間違いがありましたが、1回限りの手動テストの量を減らしました。



次の方法は、テストモデルを最適化することです。奇妙なことに、テストにはレガシーもあります。テストは作成されますが、あまり最適ではない可能性があり、そこに何か他のものが追加され、テストケースはこのために処理されませんでした...詳細な分析により、何度も削減できることがわかりました。テストシナリオの数。



これらの3つの方向性により、1日1回ベータ版にリリースし、1週間に1回、ユーザーの100％に到達し、手動で回帰することはありません。この話が、リリース状態に不満を持っている企業が行動する動機となることを願っています-将来リリースボタンを押すだけで、すべてがユーザーに行き、誰もがチャートだけを見るように。



ユリ・チェチェトキン：もちろん、これらはRevolutのプラクティスだけでなく、世界中で使用されており、GoogleやFacebookなどで使用されています。これはスムーズな移行であることに同意します。そして、多くの人がPOになるか、自動化されたQAに入ると、すべてが少しぼやけて進化し、言われたことに変わります。しかし、ロシアでは、この傾向は始まったばかりです。そして、あなたが正しく言ったように、彼は可能な限り健康でなければなりません。



ニーナ・セムキナ：そのような質問がありました。ユニットテストは誰がどこで実行しますか？CIで、またはプッシュする前にローカルで？



Yuri Chechetkin：ローカルでの運転は開発者の仕事のようです。つまり、無理に運転するべきではありません。CIが100％あるべきであることは私には明らかです。



Nina Semkina：議論してくれたすべての参加者に感謝します！スピーカーに床を譲りますディママンコと彼のレポート。