まず、開発プロセスについて簡単に説明します。 1週間に毎日クライアントリリースと3〜5のサーバーリリースがあります。 開発チームには60人以上の人々がおり、10人の機能的なスクラムチームに分かれています。
私は統合チームで働いており、そのタスクはサービスを外部製品に統合し、外部製品をサービスに統合することです。 たとえば、Jiraタスクトラッカーを統合しました 。 Jira Cards-Jiraに入らずにボード上で便利に作業できるタスクの視覚表示。
実験はどのように始まりましたか？
それはすべて、ありふれた問題から始まりました。 テスターの一人が病気のリストに行ったとき、チームのパフォーマンスは大幅に低下しました。 チームはタスクの作業を続けましたが、コードはテスト段階に達し、タスクは一時停止しました。 その結果、新しい機能は予定どおりに運用に至りませんでした。
休暇中のテスターの出発もまた別の話です。 彼は、タスクに没頭するために、自分のタスクに加えて自分のタスクを受け入れる準備ができているテスターの1人を事前に見つける必要があります。 同時に、2人のテスターが休暇に行くことは許されない贅沢です。
私たちは問題の解決方法について考え始め、実際の問題は開発プロセスの狭いネックがテストであったことであることに気付きました。 いくつかの物語の例を紹介します。
最初のストーリー：無限のタスクのロールバック
私も開発者です。 それぞれに独自のタスクがあります。 開発者はタスクの1つを終了し、テストのために私に渡しました。 このタスクは現在のタスクよりも優先度が高いため、切り替えます。 バグを見つけ、すべてをJiraで取得し、修正のために開発者に返します。
延期しなければならなかったタスクに戻ります。 開発者は、新しいタスクから返されたタスクに切り替えます。 彼はバグを修正し、テストのために私を返します。 私は再びバグを見つけ、タスクを再び返します。 このプロセスは非常に長い間続く可能性があります。
その結果、タスクの総作業時間は数倍に増加し、続いて市場投入までの時間が増加します。これは、食品会社としての私たちにとって重要です。 タスクに費やす時間を増やす理由はいくつかあります。
- タスクは開発とテストの間で絶えず移行しています。
- タスクは、テスターまたは開発者を待機しているアイドル状態です。
- 開発者とテスターは定期的にタスクを切り替える必要があり、追加の時間とエネルギーが必要です。
2番目のストーリー：成長するタスクライン
スクラムチームには、複数の開発者がいます。 彼らは定期的にタスクをテストのために私に提出します。 優先順位に基づいて、私が引き受けるタスクのキューフォーム。
だから私たちは約1年間働いていましたが、この間に会社は大きく成長しました。プロジェクトと開発者の数が増えたので、テストのタスクの数が増えました。 同時に、私はまだチームで唯一のテスターであり、速度を上げることができませんでした。 その結果、より多くのタスクがテストキューに蓄積され、開発者とテスターの間でタスクを転送するプロセスにより待機時間が増加しました。
突然病気になりました。 制作チームからの新機能の提供は完全に停止しました。 そのような状況でチームは何をすべきですか？ テスターに別のチームの支援を求めることができます。 しかし、高い確率で、彼は私たちの詳細に没頭することはなく、それは両チームの品質とタイミングに悪影響を及ぼします。
両方のストーリーからの結論は同じです-チームはテスターに依存しすぎています：
- チーム全体のパフォーマンスは、テスターのパフォーマンスによって制限されます。
- 開発者の数を増やすには、テスターのスタッフを増やす必要があります。
- すべてのタスクがテストのためにキューに入る場合、開発速度の向上は意味がありません。
- 開発者の作業はテスターによって確認されますが、品質に対する開発者の責任感は軽減されます。
- テスターがいない場合、新しい機能を出力するプロセスが低下します。
テスターのスタッフを増やしましょうか？
最も明白な考えは、テスターのスタッフを増やすことです。 これは機能しますが、特定の時点までのみです。タスクの数は絶えず増加し、テスターの数を無限に増やすことは不可能です-ある時点で高価で非効率になります。 Dodo PizzaのCEOであるFedor Ovchinnikovは 、「リソース思考」の問題についてよく書いています（問題を解決できませんか？別の従業員を雇います）。
現在のリソース内で開発の速度と品質を維持する方がはるかに効率的です。 そのため、すべてのリスクと国境の状況を考慮して、チームがすぐに機能を作成できるようにする実験を開始することにしました。 チームの役割の1つを、開発者がエラーを特定する猿のテスターから、開発プロセスのすべての段階で意識的に品質を保証するQAエンジニアに変えることから、彼らはそれを「テスターをQAに変換する」と呼びました。
開発プロセスを改善しましょう
実験の目的：
- チームのテスターへの依存を排除するが、品質と時間の損失なし。
- チームのQAエンジニアによる品質保証を改善します。
最初のステップは、チームの考え方を変えることでした。 テスターがチームの品質に責任があるという事実に誰もが慣れています。
私たちの仮説は、タスクの準備とテストの時間を増やすと、1つのタスクでの作業の反復回数を減らすことができるというものでした。 これにより、速度と品質レベルを損なうことなく、より高速で高品質な新機能を本番環境に導入できます。
チームおよび他のチームのテスターと協力して、新しい作業スキームを開発しました。 半年間、チームがそれに取り組んでおり、その過程で生じた困難や問題を考慮に入れました。今日は次のようになっています。
- 生産のプレゼンテーション。
- 技術的なソリューションとテストシナリオ。
- 開発と検証。
- リリース
問題の声明
プロダクトオーナーがタスクをチームに提示します。 チームは、技術面および製品面から境界線の状況を特定するために、処方を分析します。 さらに調査する必要がある質問がある場合-スプリントで時間が割り当てられる別のタスクが設定されます。
技術的解決策
問題のステートメントの分析結果は、1人または複数の開発者で構成される技術的なソリューションです。 QAを含む関連するすべての従業員は、技術ソリューションに精通し、同意する必要があります。 技術的な解決策は、私たちが解決しようとしている問題、影響を受ける製品の機能ブロック、およびコードを変更するための提案された計画を説明しています。
このソリューションを使用すると、開発プロセスの関連する参加者の経験に基づいて、よりシンプルで優れたソリューションを特定できます。 手元に詳細な技術的な説明があります-ブロックの問題を簡単に確認して回避でき、コードのレビューを簡単に実行できます。
技術的なソリューションの一部のブロックの例を次に示します。
タスクの説明
システムに新しいエンティティまたはアプローチが追加されていますか？
その場合、既存のアプローチの枠組み内で問題を解決することが不可能である理由を説明し、説明します。
クラスタ内でサーバーの対話は変化していますか？ 新しいクラスターの役割が追加されていますか？
データモデルは変更されていますか？
サーバーについては、オブジェクトとモデルについて話します。
データモデルが複雑な場合は、UMLダイアグラムの形式で、またはテキストの説明として表現できます。
クライアントとサーバー間の相互作用は変化していますか？
変更の説明。 これがAPIの場合、外部ユーザーに提供できますか？ エラー処理を忘れないでください-つまり 正しい理由を示してください。
テストシナリオ
これと並行して、開発者またはQAは、問題が発生した可能性のあるすべての場所を考慮したテストシナリオを作成します。 開発者がこれを行う場合、開発者は必ずQAを確認するスクリプトを提供し、QAは完全性と十分性を確認します。 スクリプトがQAである場合、開発者は、各アイテムをどのように完了することができるかを理解していることを確認する必要があります。 また、チームはスクリプトの正確性を評価します。
スクリプトのコンパイルと保存には、HipTestを使用します。
開発と検証
開発者は、技術的なソリューションに基づいてコードを書き始め、テストドキュメントに記載されているすべての可能な状況を考慮に入れます。 コードレビューを渡し、テストシナリオに対してコードをチェックします。 マスターでマージを生成します。
この段階で、QAは開発者に必要なサポートを提供します。 たとえば、複雑なケースの再生、テスト環境のセットアップ、負荷テストの実施に役立ち、大きな機能を本番環境に出力する際の微妙な違いを提案します。
すぐに使える機能のリリース
これが最終段階です。 ここで、チームは、ベータ版ユーザー向けの新機能を含めるなど、リリース前のアクションを実行する必要がある場合があります。
ドキュメントとツール
新しい作業スキームでは、開発者がテストプロセスに没頭する必要がありました。 したがって、QAとして、必要なすべてのツールを提供し、機能テストの基本を教えることが重要でした。 他のチームのQAと一緒に、必要なドキュメントのリストを作成し、不足しているテスト手順を作成し、開発者には明らかではないことを考慮して既存のテスト手順を完成させました。
その後、開発者にすべてのテストツールとテスト環境へのアクセスを許可し、共同テストの実施を開始しました。 最初は、開発者はテスト結果に責任を持ちたくありませんでした。なぜなら、他の誰も彼らのために何もチェックしなかったからです。 各開発者には、テストスクリプト、開発した機能、および[マージ]ボタンしかありませんでした。 しかし、徐々に彼らはそれに慣れました。
実験結果
実験開始から6か月が経過しました。 グラフには、チーム内の週ごとのバグ数の統計が表示されます。 赤色はチームが発見したすべてのバグの数を示し、緑色は修正されたバグの数を示します。
実験開始時のバーストを除いて、赤い線のレベルは同じレベルのままであることがわかります。 バグはもうありません。つまり、現在の品質レベルを維持しています。
同時に、タスクの平均作業時間は2％しか減少しませんでした。実験開始前は12時間40分、12時間25分後でした。 そのため、タスクの現在の作業速度を維持することができました。
その結果、チームはQAに強く依存しなくなりました。 私が病気になったり休暇に出かけた場合、チームはスピードと品質を損なうことなく仕事を続けます。
時間と品質の指標が同じままであるという事実にもかかわらず、実験は成功したと考えますか？ はい。作業の速度と品質を維持し、製品品質と開発プロセスに関するより意識的な作業のためにQA時間を解放したためです。 たとえば、研究テストを実施するには、機能テストの対象範囲を拡大し、すべてのチームでテストドキュメントを作成するための原則とルールを説明します。
他のチームでは、実験の種をsoきました。 たとえば、コマンドの1つでは、開発者が自分で表示できるため、QAは開発者がプルリクエストで記述した内容をテストしません。 別のチームでは、QAがリクエストの変更を分析し、複雑で非自明なケースのみをチェックします。
実験を始める前に覚えておくべきこと
これは複雑で時間がかかる実験です。 指をクリックするだけでは実装されないため、慎重に準備し、すぐに結果を待つ必要はありません。
チームの否定性に備えてください。 ただそれを受け取って、開発者が機能をテストしていると言うことはできません。 このためにそれらを準備し、アプローチを開発し、チームと製品の実験の価値を説明する必要があります。
開始時の速度の低下は避けられません。 開発者のトレーニング、不足しているドキュメントの作成、および再構築プロセスには時間がかかります。これは実験に寄付する必要があります。
既製のソリューションはありません。 同様のプロセスは、たとえばAtlassianで実装されていますが、これは、自分でそのまま実装することもできるという意味ではありません。 会社の文化とチームの詳細に適応することが重要です。