is there any start stop boundary qa s role scrum
スクラムにおけるQAの役割は何ですか：テスターのためのスクラム活動
この記事は、いくつかのプロセスや方法に関するチュートリアル、またはQAとして機能する方法に関する指示だけではありません。 むしろ、これは私がスクラムでシニアQAとして働いた自分の経験を共有したい記事です。
以前のCTOはいつもこう言っていました 「自由には責任が伴います」。 あなたがあなたのやり方であなたの仕事をする自由を与えられているなら、あなたとあなただけがあなたの仕事や仕事や活動に責任があります。
これがスクラムのすべてです!!スクラムについての基本的な考え方を説明します。
学習内容：
スクラムの概要
スクラムはのサブセットです アジャイル手法 広く使用されている軽量プロセスフレームワークです。
スクラムは、小さなモジュールで製品を提供することにより、お客様を満足させるのに役立ちます。また、頻繁に変化する要件によってアクティビティが遅くなる可能性があることをお客様に認識させます。リリースは短く、関係するチームの能力に応じて作業が行われるため、失敗や顧客の不満の可能性が大幅に減少します。
一方、要件（この場合はユーザーストーリー）は、やり直しを避けるためにスプリントが開始する前に確定されるため、スプリントが遅延または失敗します（例外は常に存在します）。
しかし、QAの最大の課題は、リリース期間が短いことです。スプリントはほとんど15日周期です。したがって、バグの「無料」製品を最大4〜5日で提供する（開発時間を短縮する）には、多くの努力と賢明な思考が必要です。
私は私のチームのQAです：
はい、私は私のチームのQAであり、私のチームの重要なプレーヤーです。なぜ？？顧客、BA、スクラムマスター、およびその他のすべての人が、アプリケーションまたは製品の品質、ルックアンドフィール、およびパフォーマンスについて曖昧であるためです。
スクラムでは、スプリント期間が短いため、QAはスマートな方法で実行する必要があります。したがって、最初から「計画」に関与する必要があることが非常に重要になります。 POが利用できない場合、QAがプロキシ製品の所有者の役割を果たすことができる場合があります。これにより、BAが受け入れ基準のテストシナリオ/ケースを作成するのに役立ちます。
開発者は、機能やビジネスルールで問題が発生したときにもQAにアプローチします。スクラムでは、スプリントのリリースをスムーズかつ成功させることにのみ焦点が当てられており、チームが助けを求めてきたときに助けを与えるのは「私の仕事」や「あなたの仕事」ではありません。
スクラムチームボンディングでは、チームメンバー間の健全な関係が非常に重要な役割を果たし、QAであるため、テストしているユーザーストーリーについての意見を伝える際には十分に注意する必要があります。 コミュニケーションは、ユーザーストーリーや機能に関するものであり、それに取り組んだ人に関するものではありません。
スクラムでは、QAは、発見したバグの数だけでなく、チームとのやり取り、チームの支援、困難な時期でもチームの動機付けについても判断または評価されません。
スプリントタスクのテストとは別に、テスト計画/テストケース/リリースドキュメントの作成も、スプリントのリリース期間が短く、目標がすべての人にとって同じであるため、より多くのことを試みます。 「互いに助け合うことで、バグのない実用的な製品を提供する」。
QAは、スプリントで実行されるほとんどすべてのアクティビティに関与しており、技術的には、QAアクティビティの開始または停止に境界はありません。 QAがリリースのテストのみに限定されている従来のウォーターフォールモデルとは異なり、ここではQAにははるかに多くの責任があります。ですから、以下の活動をもっとやってみることをお勧めします。
従うべき活動
以下に、スクラムのQAとしてフォローすることをお勧めするいくつかのアクティビティを示します。
Javaでバイナリ検索ツリーを作成する方法
＃1）より深く住む：
これは、ユーザーストーリーとその受け入れ基準の準備ができたら、それらを徹底的に調査し、依存関係、隠れた結果、およびそれを行うためのより良い方法があるかどうかについて深く考えることを意味します。
BAや開発チームもこれについて考えていなかった可能性があるため、これについてBAや開発チームと連絡を取り、協力してください。あなたのアイデアや発見をチームと共有してください。
隠れた障害や悪影響があることに気付いた場合は、スクラムマスターと開発者と一緒にそれらを育てることで、それに応じて考え、行動する時間が与えられます。 スクラムでのこの活動は、プロジェクトが大規模なものであり、 チーム全体にモジュールが分散している場合。
現在、依存関係について調査している間、影響はQAにとって非常に重要であり、開発チームにも同じことを認識させます。これを行うには、他のチームのQAと話し合い、それらから情報を入手します。
＃2）見積もりに関与する：
通常は見積もりにQAを含めることですが、スプリントが小さいため、多くの場合、QAはタスクをテストするための見積もりを求められず、テスト作業のために3/4/5日を残します。
これを決して受け入れないでください。必要に応じて声を上げますが、すべての作業に必要な時間を含むテスト見積もりを提供していることを確認してください。
調査時間、セットアップ時間、履歴データ収集時間などが含まれる場合がありますが、テストアクティビティの実行に必要な時間について厳密かつ具体的にし、これらの時間値を開発タスク時間とともにユーザーストーリーに追加します。 。
これは非常に重要です。割り当てられた時間内に作業を行おうとして、完了できない場合は、失敗の責任は自分だけにあるからです。 QA時間が追加されると、スクラムマスター、POは、関連するQAアクティビティと必要な時間を認識します。
＃3）開発QAペアリング：
理想的には、スクラムでは、開発が完了し、開発テストが完了すると、Sprintユーザーストーリーがテストに渡されますが、ここでの問題は、テストのためにQAに渡されるまでに4〜5日はほとんどないということです。デモまたはレビューに残ります。
これで、QAとして4つのブロッカーまたは機能障害が見つかった場合、機能テストやリグレッションなどが行われるため、リリース日を満たすために深夜または週末に作業する必要があります。これは、最善の方法ではない従来のウォーターフォールモデルのようですが、スクラムで最も賢い方法は 「欠陥を見つけるのではなく、欠陥を防ぐ」。
したがって、解決策は、開発者がテストの正式リリースの前であっても、開発者がストーリーの準備ができたらすぐに、開発QAペアリングを実行し、開発セットアップで基本的なテストラウンドを実行することです。
ユーザーストーリーの開発セットアップでBVTを実行するには、次の基準を考慮することができます。
- 各ユーザーストーリーの受け入れ基準： 受け入れ基準に従ったユーザーストーリーのBVT。
- 開発者への信頼の欠如： 開発者は、一部の実装に自信がない場合があるため、そのような実装について話し合い、同じ開発セットアップの開発者に対してBVTを実行します。
- 依存関係/影響テスト： 新しい実装の他のモジュールへの/の依存関係または影響のBVT。
- ユニットテスト： 作成した単体テストの開発者とBVTを実行し、必要に応じて単体テストを追加または更新して支援します。
これは、バグの行き来を減らすのに役立ち、QAにリリースされる前のように、クラッシュまたは機能的なバグの大部分がすでに修正されているため、全員の時間を節約できます。スプリントレビューの前にツールにこれらの欠陥を記録し、「クローズ」状態になるまで移動させることを忘れないでください。
＃4）ホワイトボードのQA：
私は常に、バグも含めてホワイトスクラムボードにQAタスクを含めるようにチームに個人的に勧めてきました。これは、スクラムマスターがボードを見るだけでユーザーストーリーのQAステータスを把握するのに役立ちます。
いいえ。 To Doリストのバグ、In Progressリストのバグ、To Do、In Progress、およびDoneリストのQAアクティビティは、それ自体を物語っています。スプリントの個々のストーリーのテストのステータスについて誰かが尋ねてくると、ツールのコンパイルと表示、または電子メールのドラフトから自分のステータスを取得するために余分な時間を費やす必要があるため、非常に苦痛です。
私は単にその人をスクラムボードに向けて、彼らに自分でそれを理解させることを好みます。 QAスティッキースリップには明るく優れた色をお勧めします。
＃5）ドキュメント：
これはスクラムの欠点または短所の1つであり、スプリントのサイズが小さいため、ドキュメントを作成する時間があまりなく、スクラムチームでテクニカルライターを見たことがありません。スクラムマスター/ BAは、製品情報に関するドキュメントを更新しない場合があり、常に更新するわけではありません。
問題は、新しいメンバーが加わった場合、または最悪の場合、ビジネスルール、機能が変更され、これらを追跡する方法が発生した場合に発生します。「完了」のユーザーストーリーで情報を検索することは、干し草の山で針を探すようなものだからです。
解決策は、ドキュメントを確認して更新するか、スクラムマスターまたはBAに更新させることができるように、ドキュメント用に可能な限り（ほとんどの場合、スラック時間またはワークロードが非常に少ないときに）スプリントで個別のタスクを作成することです。
QAは、ユーザーストーリーをテスト、検証し、機能の内外を知っているので、ドキュメントの更新を支援するのに適した人物です。 BAがなく、スクラムマスターが更新に忙しい場合は、自分で行ってください。
＃6）スプリントレビュー/スプリントデモ：
ほとんどの場合、QAは、POと利害関係者にデモを提供するために選択されたものです。しかし、そうでない場合は、スクラムマスターにそうするように説得してください。 QAは、ユーザーストーリーをテストしたり、テストしたりするので、デモを行うのに適した人物です。
QAは、機能、フロー、およびビジネスルールを知っているため、ビジネスの観点からデモを行うことができます。デモの準備をしっかりして、POと利害関係者が持っているすべての質問に答えるようにしてください。これは、スクラムマスターとBAが不在の場合に、彼らの連絡窓口になるのに役立ちます。
＃7）BAのように振る舞う：
これは通常のタスクではなく、QAからも期待されていませんが、QAはBAになるのに最適な人物であるため、チャンスがあったときにこの役割を担うようにしてください。たとえば、フロー、機能、またはビジネスルールを顧客に利益をもたらす方法で変更できるかどうかを考えて視覚化してみてください。
UIの現在の傾向、アプリケーションのルックアンドフィール、それを打ち負かす方法、よりユーザーフレンドリーにする方法などを考えて検索します。チームが問題に悩まされている場合は、参加して、シンプルでスマートなものを提供してください。解決。これはあなたの役割を後押しし、あなたのキャリアの成長に貢献する要因になります。
いくつかの問題が議論されているとき、またはあなたが提案を与えることができるレビュー/デモで、POとの電話中にチャンスが訪れます。
結論
スクラムは通常のウォーターフォール方式とは非常に異なる方法であり、スクラムマスターはファシリテーターです。したがって、彼/彼女があなたのためにあなたの活動を定義することを期待しないでください。
スクラムでは、QAの役割に開始と終了の境界はありません。 QAは、最初から最後まで、事前計画からスプリントレビュー/デモまで、すべてのアクティビティに関与する必要があり、関与する必要があり、すべてのアクティビティに参加する必要があります。
これは、（前に述べたように）スクラムで作業するときに利用できる適切なドキュメントがないため、製品またはアプリケーションを理解するのに役立ちます。あなたは責任があり、意欲的で積極的であることが期待されています。したがって、誰かが来て、あなたが何を、どのように行うべきかを教えてくれるのを待たないでください。
自分でイニシアチブを取り、あらゆる方法でチームを支援し、健全な関係を維持し、チーム内で進行中のことを追跡し、最も重要なこととして、特定のスプリントでのタスクについて明確にする必要があります。
ここには、あなたを監視したり、あなたの活動を追跡したりするマネージャーはいません。常にチームを支援する準備をしてください。そうすれば、最高の機会を得ることができます。
以下のコメントセクションで、この有益な記事についてのあなたの考え/提案を自由に表現してください。
推奨読書
- SCRUMにおけるビジネスアナリストの役割とQAがこの役割に最適な理由
- アジャイルスクラムオンラインクイズ：アジャイルスクラムの知識をテストする
- アプリケーションをデバイスにインストールし、Eclipseからテストを開始します
- かんばんvsスクラムvsアジャイル：違いを見つけるための詳細な比較
- アジャイルスクラムプロセスを使用して、高価値のソフトウェア機能を短期間で提供する方法
- アジャイルマニフェスト：アジャイルの価値観と原則を理解する
- スクラムでの欠陥トリアージ：スクラム設定でどのように編成されているか
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)