QAチームを「分散」させた方法とその結果

または、テストチームを拒否した場合に、明らかでない結果を得る方法。



1年半前、私たちはテストチームを破壊しました。回帰をあきらめ、開発者をサポートするためにE2E自動テストをSeleniumに転送し、芽のバグを防ぐ機能を見たチームに行きました。バラ色の夢の中で、それはもっと便利だと私たちには思えました。QAは品質に取り組み、テストは早期に開始され、開発者は自分で自動テストを作成し、誰も気にしません。







しかし、それはそのようにはうまくいきませんでした。ピンクの夢は追加の色合いで彩られました：誰も品質について考えていません、自動テストは悪化しています、そしてQAチームのない開発者は（突然）さらに作業があります。これは、私たちが準備ができていなかった二次的な結果がどのように現れたかです。現在、私たちはそれらを修正しており、これらの結果が何であるか、それらがどのように発生するか、それらがどのような損傷を引き起こすか、そしてそれがそれほど害を及ぼさないようにそれらを予測しようとする方法をあなたに伝えることができます。

一次および二次の結果は何ですか

PrinciplesのRayDalioには、「2次の結果」という概念があります。これらは、私たちがしばしば予測できない決定の非自明な結果です。たとえば、20世紀の60年代に、スズメとの戦争が中国で始まりました。スズメは穀物を食べました、そして彼らがそれを食べるのをやめるために、中国は鳥を探し始めました。狩猟中に、中国人は20億羽近くの鳥を一斉に殺しました。







スズメの大量殺戮の結果、収穫量は1年後に増加しました。これらは一次的な結果です。しかし、昆虫やイナゴを食べる人は誰もいなかったし、毛虫が増えてさらに多くの作物が破壊され始め、その後数年で中国で大規模な飢餓が発生した。これらは二次的な結果です。



一次的な結果は私たちの決定の直接的な結果であり、常に表面にあります。二次的な結果は微妙で、しばしば長期的です。それらを理解するには、状況を考えてシミュレートする必要があります。例えば：

• コードの行数を開発者に支払うと、コードは増えますが、品質は低下します。時間が経つにつれて、人々はより多くのお金を得るためにますます多くの悪いコードをだまして生成し始めます。これらは二次的な結果です。
  
  
• 運動を始めると、最初は痛くて時間がかかります。しかし、しばらくすると（1週間から数ヶ月）、習慣が生まれ、健康と外見が改善されます。これらは二次的な結果です。
  
  
• 毎週金曜日に豚のように酔うなら、金曜日の夜はいいでしょう。しかし、土曜日の朝は悪くなります-これらは二次的な結果です。そして、これを何年も定期的に行うと、おそらくそれはアルコール依存症と肝臓の肝硬変に発展するでしょう。しかし、これらはすでに3次的な結果であり、「まったく別の話」です。
  
  

QAチームがあり、それを「分散」させました

ここで、1次と2次の両方の結果をどのように感じたかを説明します。7人のテスターからなる居心地の良い専用チームがありました。そのうち4人が自動テストを作成し、3人が手動でテストしました。ある時点で、私たちはチームに分かれて分散することにしました。どうして？ 

開発者がフィードバックを受け取るのが遅すぎたためです。

バグは、すべての開発がすでに「終了」し、すべてが「統合」された段階にあり、製品がリリースの準備ができていることを確認する必要がありました。受け入れテストはありませんでした;それはテストスキルを持っていない製品アナリストによって実行されました。さらに、テスターと開発者は異なる世界にいて、ほとんど対話しませんでした。



明らかな（そして）解決策は、芽のバグを防ぐために、システムの特定の機能（パーツ）に取り組むチームに分割することです。私たちは仕事をあきらめたくなかったので、私たちの機能を開発者に移すことにしました。自動テストについて考えました。開発者に渡して、問題なくテストします。



最初に、彼らは「実験」で自分たちで仮説をテストすることを決定しました。自動テストで回帰の重要なシナリオをカバーし、手動回帰を拒否します。経験の結果、ホットホットとリリースのロールバックの数が劇的に増加しない場合、実験は成功したと見なすことができます。そしてそれが起こりました-これ以上の修正プログラムはありませんでした。解決済み-同意しない。



注。同社はレストランと呼ばれる製品を持っています。これには、すべてのサービスとモノリスが含まれます。この製品の目標は、すべてのレストラン従業員の作業を可能な限り自動化および最適化することです。現在、私たちの仕事はエラー防止に重点を置いています。現在、私たちは「レストラン」製品のQAです。製品の品質を開発し、タスク開発のすべての段階に参加しています。

一次および二次の結果

直接的な結果。予想通り、私たちは最初からタスクの開発に関与し始め、PBR、計画、ワークショップに参加し、テストの専門知識を彼らに伝えました。私たちは開発チーム、またはむしろその一部に近づき、私たちの問題はチームの問題でもありました。テスト、品質保証、およびシステムに関する幅広い知識の専門知識がチーム内で成長し始めました。次に、開発者の作業に没頭し、開発者の苦痛を理解し始めました。



さて、私たちが計画しなかったのは二次的な結果です。



誰も製品の品質を推進しません。この問題には2つの側面があります。

• プロセスの観点からの品質。
  
  
• 自動テストとパイプラインの品質。 
  
  

専任のQAチームでは、品質を推進してきました。私たちは、ユーザーの前で製品を見て、ユーザーがどのように見ているかを理解した最後の人でした。チームレトロの変更と改善について話し合い、開発チームにそれらを導入するかどうかを一緒に決定するための提案がありました。自動テストを監視し、その安定性に取り組みました。



チームに分散した後、それはすべてどこかに消えました。開発チームでは、私たちはチームの一員であり、船の一員です。私たちはその仕事に完全に没頭し、目が「ぼやけ」、製品のこの全体的な品質は少し遠いものになりました。



すべてのアイデアは、チームの状態を改善することのみを目的としていました。高品質の製品ではなく、高品質の機能をリリースするためにあらゆることを行いました。その結果、製品の品質を新しいレベルに引き上げることができる根本的に強力なソリューションは登場しなくなりました。



自動テストを作成する能力が失われました。自動テストは曲がり始め、コードを変更せずに低下することが多くなりました。チームが解散するまでに、手動テスターは自動化の基本を理解し始めたばかりでした。テスターも開発者も専門知識を持っていなかったことが判明しました。さらに、これらのテストを書いた人々が開発、製品管理に入り、誰かが辞めたとき、専門知識の粒が混乱しました。



私たちは、どのような自動テストがあり、何をカバーしているのか、それらがどのように開発、進化、追加、削除されるのかを確実に知りませんでした。その結果、自動テストでいくつかの情報を見つける必要があるとき、それは開発者なしでは理解できないのと同じ探求でした。 



開発者のための余分な作業。開発者になるのは難しいです。以前は「魔法のように」検証されて本番環境に移行する製品コードを作成していましたが、今は自分でテストを作成し、編集して安定させる必要があります。 PBRでは、テストの対象となるシナリオを決定し、開発者が自動テストのレベルを自分で選択します。



開発者は、パイプラインの死を受け入れるいくつかの段階を経ました。 



否定..。すべてのDodoISリリースは、開発者によって公開されています。彼らはプロセスを整理し、負荷テストチームと通信し、ログを確認し、リリース中に監視します。赤いテストに直面してリリースをロールバックした開発者は、その理由を理解しようとはしませんでしたが、5-7-10回緑になるまでパイプラインを再起動しました。これは、自動テストに信頼がなかったためです。 



私が見つけた再起動の最大数は44回です!!!レトロな「赤いテストでリリースしないでください」の1つで採用したルールのように思えます。テストが赤の場合は、問題が何であるかを把握します。問題がテストにある場合は、それを修正するか、署名してカードを作成し、テストのロックを解除してバックログに追加します。」 



怒り：開発者は私たちのテストで誓った、彼らは彼らが言ったたわごと不安定、下手に書かれた、彼らは（そのために）投げ出さと書き換え、やり直しをする必要があります。



交渉や不況はなく、すぐに受け入れられました。開発者は、UIとAPIのE2Eテストを自分で作成し、安定化して改善できるようになりました。



販売中のバグの数が増え始めました。重大ではないバグが本番環境に浸透し始めました。これにはいくつかの理由があります。

• 私たちの自動テストはすべての機能をカバーしているわけではなく、重要な機能だけをカバーしています。また、手動の回帰テストはもうありません。
  
  
• すべてのチームに十分なQAエンジニアがいませんでした。チームにはテスト能力がなかったため、テストに十分な注意を払っていませんでした
  
  

その結果、本番環境で誤ってバグを見つけ始めました。それらは重要ではありませんが、一般的にどれだけの数がありますか？

これらの問題をどのように解決しますか

おそらく、別のチームがすべての非自明な結果を予測できたかもしれませんが、私たちはできませんでした。数ヶ月後に結果を見て、私たちは決定を下し、それらを排除し始めました。すべての



レストランQAを含むレストランQAギルドまたは実践コミュニティを作成しました。コミュニティの目標は、製品全体の品質を向上させ、すべての製品チームに優れたテスト手法を広めることです。これは、専任のQAチームの利点を組み合わせた教育であり、開発チームでQAになることからもメリットがあります。







私たちは週に1回会合を開きます。結果、発見を共有し、品質について協力することを計画しています。また、ギルドタスクに取り組むために週にいくつかのスロットを割り当てます。たとえば、リリースマン用のアシスタントボットを完成させています。 



関税..。ギルドは、質の高い所有者と自動テストの欠如の問題を部分的にカバーしています。しかし、ギルドには開発と自動化に関する強力な能力がないため、CTOは意欲的な決定を下し、パイプラインの義務を組織しました。







これで、開発者はパイプラインプロセスを体系的に改善できます。安定させ、リリースを遅らせる問題を見つけて修正します。開発チームの1人の開発者が、パイプラインの所有者に1か月間なり、体系的に改善します。リリースはしませんが、改善します。これにより、テストのリリースとサポートのプロセスが簡単かつ簡単になります。製品メトリックが改善されたので、このアテンダントを削除しましたが、いつでも返すことができます。 （記事を書いている間、通知が安定性を低下させ始めたので、私たちはそれを返しました）



コース..。手動テスター向けのコースと、自動化の経験を持つ開発者とのペア作業により、能力不足の問題を解決します。 



開発者のための余分な作業。それについてあなたができることは何もありません、開発者はちょうど自動テストを受け入れる段階に達しました。低レベルのテストで機能をカバーできない場合は、E2Eテストを自分で作成し、パイプラインを安定させます。彼らがスマートブックで言うように、チーム全体と開発者とテスターがテストを書くことができるとき、それは良い習慣です。それはまた、モノリスから飲んだマイクロサービスの側への私たちの旅行にも影響を及ぼします。モノリスでのテストは少なくなり、別々のリポジトリでのテストが増えるにつれて、パイプラインはより安定します。



製品を調査します..。予想される動作との不整合について製品の調査を開始することにより、本番環境のバグに関する問題を解決します。毎週の探索的テストセッションを予定しています。また、製品所有者のバックログにバグをもたらします。

私たちは今何をしますか？

二次および三次の結果を考慮しなかったため、決定が不十分になりました。最善ではない最初のオプションが既存のバイアスを強化する場合、特に危険です。しかし今、得られたすべての経験で、私たちは異なった行動をとったでしょう。



たとえば、能力の喪失は、自動化の能力を持つ人々が移行する数か月前に、製品のすべてのQAエンジニアまたはチームの開発者と能力を共有するように依頼することで解決できます。そして、一度にすべてのためにより良い。開発者



の余分な作業の問題を補う方法はありませんが、事実の前に置かないことでテストを書く手間を減らすことができますが、次のようになります。

• テストの値を明示的に示します。
  
  
• これらのテストを作成、改善、維持するように開発者に教えます。
  
  
• ( ), .
  
  

私たちが別々の道を進んだとき、私たちはこれらの問題についてさえ考えませんでした。 「後から考えると」、それについて考えるのは初歩的なことのように思えます。しかし、後から考えると、私たちは皆強いです-未来を予測してみてください。



私にとっての二次または三次の結果は、すでにそのような決定を何度も行い、そのような決定の結果を見た経験豊富な人々にとっての一次の結果かもしれません。



結果に影響を与える不確実性と変数が多すぎます。 

結果を予測するのではなく、少なくとも、それが何であるかを知ることが重要です。決定を下す前に、結果がどのようなものになる可能性があるかを考え、他の会社の事例に関する情報を読んで、少なくとも起こりうる非自明な結果の規模を把握することが重要です。 



決定の2番目（さらには3番目）の結果を予測することを学ぶ人は誰でも、人類を救うか破壊することができます。または、少なくとも株価の変動から、ScroogeMcDuckよりも多くのお金を稼ぎます。 

今、どのように結果を予測しようとしていますか

私はこのトピックに関する記事を読み、著者によると、そのような結果を予測するのに役立ついくつかのルールを自分で推測しました。私はそれらを使おうとします：

• 決定を下す前に、「次に何が起こるか」という質問を自問してください。質問にタイムラインを追加します。10分、10か月、または10年後に何が起こりますか？
  
  
• さまざまな状況を振り返ることによって、そのような結果に向けてあなたの考えを訓練してください。たとえば、全世界が電気自動車に切り替えた場合、またはたとえば、基本的な無条件の収入を導入した場合、1次または3次の結果はどうなりますか。この演習には正解はありませんが、より広く考えることができます。
  
  
• あなたの頭の中で最初に考えたのは最初の注文であることを忘れないでください。いつも。
  
  

テストチームや他のチームの編成を変更するときに他の問題が発生した場合は、コメントを書き込んでください。直面した問題とその解決方法を知ることは興味深いことです。

P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).



, , , : « » « » ( «» — ). QA, « ? ».



-, .