—組織をもたらし、バグに簡単にプロセスを適用する方法bashクレモナ
重要：これはバグbashを整理する方法のステップバイステップです。 QuintoAndarでの使用の利点についての詳細は、記事”バグバッシングが頻繁かつ一貫してチームの考え方を品質に変え、QuintoAndarでの接続を構築した方法”にあります。Bug Bashはテスト方法論であり、もともとは2001年にRon Pattonが著書Software Testingで定義したものです。 テストへのこのアプローチはQuintoAndarの異なった分隊で有用であり、その結果、私達は適用を最大限に活用するためにプロセスを作成した。
バグは何ですか？!
私は最初にQuintoAndarで私の募集のインタビューでバグbashという言葉を聞いて、それは良い響きでした。 その後、私はオンラインでより多くの情報を探していましたが、これは非常に普及した慣行であり、多くの企業で共通して使用されていました。 Bug Bashは、もともとRon Patton、2001によって定義されたテスト方法論です。 彼の著書”ソフトウェアテスト”の中で、彼はbug bashを、製品の開発サイクルに関わるすべての人々が、定期的な日々のタスクを脇に置き、”製品にポンド”する手順と したがって、定義から設計、開発からマーケティングまで、製品について何らかの形で発言権を持っている人は、同じ部屋にいて、機能をリリースする前にできるだけ多くの方法で機能をテストする必要があります。
これにより、チームは利害関係者から開発まで、できるだけ多くのテストシナリオをカバーするために緊密になり、したがって、欠陥のあるリリースの可能性を減らすことができます。 これは、私たちの速く、激しいペースの仕事に代わる実行可能で貴重な代替手段である可能性があることを認識し、私たちはゆっくりとチームにコンセプトを導入し始め、常に機能のニーズに応じてアプローチを改善し、適応させました。
天国、それはあなたですか？
天国はあなたですか？
夢のように聞こえますが、バグバッシュを率いたことがあるなら、あなたはおそらく、それが部屋の中で非常に多くの異なるプロファイルを収集することができますどのように混沌を知っている：それはバグであるかどうかに疑問を提起する人、他の人が調査結果を報告する場所を尋ねる人、他の人がシステムにアクセスするのに問題がある人、誰もがテスト中にバグ修正をフォローアップし、優先順位を付ける方法を議論するなど。 最小限の準備がなければ、重要な詳細が質問とポストitsの間で失われようとしているオッズは、人々が聞いていないためにイライラし、最終的には、バグP>
バグバッシュを調整する固有の複雑さに加えて、プロパティ検索からレンタル管理まで、完全なビジネスソリューションを提供する製品 これは、ユーザーエクスペリエンス全体を通じてバックエンドとフロントエンドの成果物を意味します。 したがって、ここQuintoAndarでは、両方のシナリオに適した柔軟で適応可能なプロセスを持つことが不可欠でした。
私たちは、私たちの前に大きな挑戦があることを知っていました。: さまざまなコンテキストでバグbashを効果的に適用する方法を知る。 プロペラが必要だった 意味、異なった種類の配達の確認で使用されるには十分に適応可能だった集中化のための必要で、強い用具が付いている滑らかなプロセス。
上記の実現について疑問に思って、私たちはテストの重要なポイントとバグ報告の重要な要素を組み合わせることに焦点を当てたプロセスを作
前述のように、良いバグbashの基礎には、品質保証担当者がテストの条件を設定し、テストスキルを評価するツールを一時的なテスターに提供する準備 良いセットアップには三つの主要なステップがあります：
ステップ1：すべての調査結果を一元化するスプレッドシートを作成する
最初のもの 文字通り！ 問題をマップしようとするときは、すべてを1つの文書で報告することが基本です。 これは、共有メモ、テキスト文書、巨大な段ボールを意味する可能性があります。 我々はまた、テストされていたもののいくつかの視覚的なガイダンスを与えることができるスプレッドシートを使用することにしました。 この選択は、チームのプロダクトデザイナーとのコラボレーションで、”Product Design&Bug bash:インターフェイスと品質を検証する方法エンドツーエンドから
スプレッドシートを使用すると、プロセスを簡単に自動化して、よりスムーズで機能的にすることもできます。 Bug bashスプレッドシートには、参加者、Bug bash、自動レポートの3つのタブがあります。
QuintoAndarのエンドユーザーアプリケーションは主にwebベースであるため、テストには異なるモバイルデバイスとデスクトップデバイスを含める必 時には、問題はデバイス関連であり、その開示が不可欠です。 そこで、バグbashの各テスターまたは参加者が名前、シミュレートされたユーザー、ブラウザ、デバイスブランド、デバイスタイプなどの情報を入力する”参加者”タブ これらは、問題の調査または修正を開始するために必要な基本的な情報です。 その情報が完了したら、私たちは続けていくことができます。
2番目のタブ”Bug bash”では、テスト要素とバグ報告要素を組み合わせています。 最初の列でテストされるコンテキストの画像の後には、テスターがテスターの名前、見つかった問題の詳細な説明、該当する場合はその画像を入力する三つの列が続きます。 このようにして、レポートに疑問がある場合は、誰がそれについて問い合わせて時間を節約するかを知っています。 これは、設計されたレイアウトに対して最終製品を検証できるため、フロントエンドの配達を保証するときに特に価値があります。 バックエンドの配信を検証する場合、フロントエンドイメージは通常、バックエンドで何が起こっているかを説明するワークフローに置き換えられます。 このようにして、私たちは目に見えてテスト可能ではないにもかかわらず、人々を文脈に投稿し続けます。 人々は、製品をテストし、このタブ上のすべての問題、機能強化や疑問を報告します。 テスト時間が経過すると、チームは報告された問題を調べ、修正段階に含めることが理にかなっているものを見直し、議論します。p>
重大度の評価と優先順位付けのこの段階により、チーム全体が見つかったすべての問題を認識し、その開発サイクルに関連する問題をレポー これは報告段階を最大限に活用し、問題に優先順位をつけるためにフォローアップの会合を避けます。
“自動レポート”という名前のスプレッドシート上の第三と最後のタブは、私たちのプロセスの速度に追いつくための鍵です。 これには、最後の2つのタブからすべての情報を取得し、Jiraボード上に課題レポートを自動的に作成するスクリプトが含まれています。 これは、報告プロセスフェーズで失われた情報がないことを意味します。 これにより、多くの再加工が防止され、プロセス全体がより効率的になります。 スクリプトはカスタマイズ可能なので、報告するフィールドを追加することができます。p>
ステップ2：コンテキストプレゼンテーションを作成します
効果的であるためには、テストされる製品の範囲は、テストプロセスに関 スコープは、その特定の時間枠または開発サイクルで追加された機能に限定する必要があります。 その特定のテスト式典の範囲が明確であればあるほど、それがバグであるかレガシー問題であるかに答えることは少なくなります。 利害関係者やチームの外部者がテストに参加している場合、開発自体の中の人々が持っている明確さを持っていない可能性があるため、このプレゼンテーシ
ステップ3：部屋を予約し、先に招待日を送信
また、人々のカレンダーを気にしながら、人々の大規模なグループに合わせて部屋を手配することは、常にそ それは皆のカレンダーに一致するか、利用可能な十分な大きさの部屋を持っているので、先に滞在するのに長い時間がかかる可能性があります。 招待状では、コンテキストプレゼンテーションとbug bashスプレッドシートを共有し、すべての参加者に必要な権限を与えていることを確認してくださ バグバッシュのもう一つの非常に重要な側面は時間です。 この式典に投資するために、少なくとも1時間30m（1時間半）を惜しまないようにしてください。 それは多くのように見えるかもしれませんが、製品を使用して、ユーザーエクスペリエンスへのより良いアプローチを得るために相互作用するので、多くの異
