Clever Geek Handbook

1月の「テスターカレンダー」。 バックログを取る

100人のテスターがサーキットで働いています。 昨年末、彼らは「テスターカレンダー」を考案しました。これは、テストに関する実践、秘密、ライフハックを含む12の月次記事のサイクルです。



最初の記事は、1月にエカテリンブルクのテスター共同体のウェブサイトで公開されました。 より多くのテスターが読むために、Habrに転送します。 2月の次の記事は明日公開され、その発表は電報チャンネルで行われます。



このサイクルは、すべてのサーキットテスターのトップであり、 小売テスターの1人であるマキシムザハロフによって始まります。 彼は、なぜバグが蓄積しているのか、ピザを使用してバックログを解析し、80個のバグを破壊する方法を教えてくれます:)


バックログは、チームが完了する必要がある残りの作業のログです。 この用語は、アジャイルの方法論ファミリー、特にスクラムから来ました。スクラムでは、主な成果物の1つであり、ユーザーストーリーのソースです。











私はオフィスでテスターとして約8時間働いており、時々週末に働いています。 6か月間の大きな目標と、数週間または数か月にわたる小さなプロジェクトがあります。 必須のルーチンもあります。 仕事は常に豊富です。つまり、すべてを行う客観的な機会はありません。 1年後、私は同じタスクを実行して同じ問題を解決していることを知りたくありません。 私はドロフェエフやアルハンゲリスクではありません。記事には幸福のレシピはありませんが、いくつかの良いヒントとコツを安全に頼ることができます。







私の記事は、製品のバグのリストを管理し、欠陥の優先順位付けと更新に関与しているテスターに​​役立ちます。 テストシステムとテストプロセスをサポートするための多くの1回限りのタスクを持っている人。 おそらく、タスクのテストに加えて、多くの追加作業、またはチーム外部のプロジェクトさえ持っている人たちです。







バックログの解析



私の最初の間違い -私はいくつかのバックログがあることを理解していませんでした。









それとは別に、プロジェクトは実行可能ですが、数少ないバックログのうちの1つだけを処理するかのように時間を計画しました。







2番目の間違い -タスクのソースをバックログと見なしました。 これにより、私はすぐに次のタスクに取り組み始めました。 新鮮なタスクは常により緊急、重要、簡単に見えます。 そして、私は自分の目標のために仕事をやめ、レーキ受信トレイになりました。







バックログのタスクはどこから来ますか？





これらのソースが完全なバックログになるには、多少なりとも正式な処理が必要です。 したがって、私はテスト用の機能を毎日レビューし、Micromilesに含まれています。 2〜3か月ごとに 、テスターのグループで、技術的な改善と技術的な負債について考え、レトロな開発チームを実施しています。 そしてその後にのみ、着信リクエストは現実のステータスを受け取り、最も貴重なリソースである時間を獲得します。







最大の対立を解決するには、ソースとバックログの分離が必要です。作業タスクと残りの作業、重要な作業と緊急の作業です。 よく知っています。 優先度の高いタスクを扱う場合、常にボードからの緊急タスクで詰まってしまいます。 プロジェクトのみを行う場合、必須のルーチンがスリップします。 数年前、私はSLAに同意しました。作業タスクは3日間しか待機できず、5を超えることはできません。 この契約が尊重されている限り、プロジェクトに参加できます。







今、私はこのような問題を解決します：









自分とリーダーに告白することは非常に重要です-私はすべてをするつもりはありません。 しかし、私は定期的にそれ以上のことをします。









バックログを調理する方法



最初にしたことは、バックログを減らすことでした。 私たちがそれをどうやってやったかについてのいくつかの物語。







100個のクローズドバグの物語



むかしむかし、製品があり、その中に300の未解決のバグがありました。 更新に多くの時間が費やされました。 テスターは世界の不完全さに苦しみ、マネージャーは時間を割り当てず、闇が支配していた。







マネージャーとテスターは収集し、バグを作成日でソートし、100の最も古いバグを閉じました。 彼らは、年に一度は誰もそれを修正しないと推論しました、そして、これは最悪の問題ではありません。 そして、これは彼らが決して修理されないことも意味します。







興味のある人が走り始めて、これは無理だ、これは無礼だ、これらは重要なバグだ、彼らは彼らを探すのに時間を費やし、クライアントは本当にそれを必要としていると大声で呪い始めました！ マネージャーとテスターは、5人のバグすべてを主張せずに公開しました。







バックログは3分の1になりました。







現在、これらのマネージャーとテスターはZenを学習し、6か月に1回（これも見ずに）6か月以上前のすべてのバグとタスクを殺しています。 問題はありませんでした。







道徳。 バグが修正されないことを認めることは、各オープンバグの所有権の価格を理解することと同じくらい重要です。


不要なバグトラッカーの物語



むかしむかし、1か月に40個が開かれ、20個のバグが閉じられた別の製品がありました。







最初の話に向かっていることは明らかでした。 マネージャーとテスターが同じだったので、私はしたくありませんでした。 マネージャーは、テスターと、今後1〜2週間以内に修復されるバグのみがトリガーされることに同意しました。 そして、それらが正確に修復されるように、開発者に同意する必要があります。 それ以外の場合-起動しません。 絶対に。







バグをトラッカーに取り込むよりも、整理するのが難しいです。 ただし、現在製品には約10の未解決のバグがあり、3年連続でバグがあります。







-同じバグで再び私たちに目を向ける場合はどうすればよいですか？

「同じ。」 修復するか起動しない。

「しかし、再検討に多くの時間を費やしますか？」

-はい、しかし、いいえ、私たちは支出していないように思われます。

-バグのある製品があります！

-この測定の前後の製品のバグの数は変更されていません。 私たちはできることとできないことを正直に認めました。







未解決の欠陥の膨大なリストを持っていないという感覚は特定のものです。 現在、マネージャーとテスターはZenを学び、3〜7個の未解決のバグに対して欠陥トラッカーの使用を拒否しています。







道徳。 それらを修正するバグがあります。 そして、あなたがそれをもう修正できないならば、我々はそれをより少なく始めます。 結果は同じですが、議論の中心は穏やかで穏やかです。


バックログをさらに調理する



彼らは過剰を捨てた、残りは間違いなく行われる必要があります。 しかし、時間はありません。 になる方法 適切に準備されたバックログにより、時間を見つけることができます。 使用方法を学ぶことができる多くの時間ソースがあります。







インターン



夏には、インターンプログラマーがチームに来ます。 製品の知識に加えて、トレーニングの必須部分はテストシステムの知識です。 メンターとマネージャーは、研修生がテストシステムを改善するタスクを引き受けることに簡単に同意します。 主なことは、このタスクを策定し、理解しやすく、最終的なものにすることです。







そこで、テストシステムにデータジェネレーターが登場しました。







当社ではこのような慣行も行っています。年に一度、各テスターは別のチームで別の月に出勤する権利を持っています。 教え、学び、世界を見て、自分を見せること。 そのようなテスターが私のチームに来た場合、彼は私の手が届かなかった改善を行うことをお勧めします。 私にとって-改善点として、彼は1か月間ルーチンをやらない機会があります。







そこで、単体テストでカバレッジを上げました。







プログラマーの自由時間



3月10日以降、プログラマーは休暇を取り、既に7番目のタスクを完了しており、大きなことはしたくありません。 この瞬間を首筋でつかみ、小さなパズルを滑らせることが重要です。







したがって、テストはもう少し安定しました。







プログラマーはテストのために2つのタスクを与え、最初の2つを起動するまで3つ目のタスクを実行したくありません。 彼が使用するテストシステムを改善する時が来ました！







そのため、キャッシュに関するシャーマニズムのために、ブラウザーのテストが2倍速くなりました。 （そして正直に言うと、プログラマーは自分でタスクを思いついた。）







チームの動き



1か月前、私たちのチームは村に家を借り、3日間一生懸命働いて新しいおしゃれな分散トレーシングシステムを導入しました。 テスト担当者は、分散トレースシステムをドラッグする方法を知りませんでしたが、通常の日常のタスクを実行できませんでした。







そのため、テストシステムでは、TODOが数個少なくなりました。







最初のストーリーのマネージャーを覚えていますか（205個のバグが205個残っています）。 新年が近づいており、新年の前の最後の数日間は、CIS全体が深刻なものを展開することはありません。 しかし、20人のプログラマーを連れて、各テスターまたはアナリストにペアを与え、競争を手配することができます-誰がさらにバグを修正しますか？







本質が15分で明らかな場合は、欠陥を取ります。それを修正し、テスター（またはその役割のアナリスト）がチェックし、コミットし、次のものを持ち帰ります。 バグが複雑な場合は、スキップして先に進みます。 進歩、競争の雰囲気、新年と混乱、最後にピザと威勢のいい感じの大きなボード。







そのため、1日以内にさらに80個の未解決のバグがありました。







助けたい人



製品の実装者は、新機能について最初に知りたいですか？ それとも、彼らはプロセスにいくつかのバグを見つけるでしょうか？ タスクがキューを待機している間に、テストベンチにロールアウトし、実装についてこのことについて説明します。







これは、「第2テストの付着物のクラブ」がどのように表示されたのかを示しています。そこでは、製品のノベルティに事前に触れてバグを報告できます。







デザイナーは自分のプロトタイプインターフェイスが実際にどのように見えるかに興味がありますか？ テストを開始する前に、テストスタンドを見せることができます。 そして同時に説明します：「ところで、すべてのレイアウトのバグはここに書くことができますが、プログラマーと直接議論する方が良いです。」







これにより、問題の「作成者による制御」が行われ、レイアウトの欠陥の数が大幅に削減されます。







アナリスト、機能をデモする方法のプロダクションで書くことができますか？ プログラマー、私は1つの既製のテストケースを持っています。最初のテスト結果を待つ間に、エンドツーエンドテストをエンコードします。







そのため、各タスクについて、テストの開始時にエンコードされたエンドツーエンドの自動テストが表示されました。







なぜこれらすべての例ですか？



多くの機会があり、創造することさえできます。 これを行うには、バックログを準備してこれらの機能を使用できる必要があります。









私のヒントやストーリーが、大騒ぎせずに働き、不必要な動きをしないようになることを願っています。 トピックに関する独自のアイデアがある場合は、コメントで共有してください！







カレンダー記事のリスト：

別のアプローチを試してください

合理的なペアテスト

フィードバック：発生方法

テストを最適化する

本を読む

分析テスト

テスターはバグをキャッチし、Canerを読み、移動を整理する必要があります。

ロードサービス

QAサービスメトリック

セキュリティをテストする

顧客を知る

バックログを取る







More articles:


All Articles