スクラム テスト方法のチュートリアル
⚡ スマートサマリー
スクラムテストは、継続的な検証アプローチであり、 Sprint 開発者、テスター、プロダクトオーナーが協力して機能要件と非機能要件を検証するサイクルであり、プロジェクトライフサイクル全体を通して透明性、適応性、迅速な納品を維持する。

ソフトウェアテストにおけるスクラム
ソフトウェアテストにおけるスクラム スクラムは、複雑なソフトウェアアプリケーションを構築するための手法です。複雑なタスクを実行するための容易なソリューションを提供します。スクラムは、開発チームが品質、パフォーマンス、ユーザビリティなど、ソフトウェア製品開発のあらゆる側面に集中できるよう支援します。また、ソフトウェア開発中に透明性、検査、適応性を提供することで、複雑さを回避します。
スクラムテスト
スクラムテスト は、ソフトウェア アプリケーションの要件が満たされていることを検証するために、スクラム手法で実行されるテストです。セキュリティ、ユーザビリティ、パフォーマンスなどの非機能パラメータのチェックが含まれます。このプロセスではテスターが積極的に関与することはないため、通常は開発者が単体テストを使用して実行します。プロジェクトの性質と複雑さによっては、専用のテスト チームが必要になる場合もあります。現代のチームは、この作業を Jira、Linear、 Azure DevOps、または Asana.
スクラム方法論の主な特徴
スクラムの主な特徴は以下のとおりです。
- スクラムには、調整可能なスコープを持つ、短く固定されたリリースサイクルスケジュールがあります。 Sprints急速に変化する開発ニーズに対応するため。各リリースには複数の Sprints. 各スクラムプロジェクトは、複数のリリースサイクルを持つことができます。
- 繰り返されるシーケンス 会議、イベント、マイルストーン.
- 新しい要件をテストして実装する実践。 物語各作業後にリリース準備が整っていることを確認する Sprint.
スクラムは以下の3つの柱に基づいています。
それでは、一つずつ見ていきましょう。
1. スクラムにおける役割
スクラムテストには、プロダクトオーナー、スクラムマスター、開発チームという3つの主要な役割があります。それぞれの役割について詳しく見ていきましょう。
| プロダクトオーナー | スクラムマスター | チーム |
|---|---|---|
| 彼または彼女が製品の機能を定義する。 | その人はチームを管理し、チームの生産性に気を配る。 | チームは通常5~9人程度で構成される。 |
| プロダクトオーナーは、リリース日とそれに伴う機能を決定します。 | 担当者はブロックリストを管理し、開発における障害を取り除く。 | 開発者、デザイナー、そして場合によってはテスターも含まれます。 |
| 彼らは製品の市場価値と収益性に基づいて、機能の優先順位を決定する。 | 彼または彼女は、あらゆる役割や機能との調整を行います。 | チームは自分たちで仕事の計画とスケジュールを立てる。 |
| その担当者は、製品の収益性に対して責任を負います。 | 彼(彼女)はチームを外部からの干渉から守る。 | プロジェクトの範囲内で、 Sprint ゴール。 |
| 彼または彼女は、作業項目の結果を承認または拒否することができる。 | デイリースクラムへの招待状、 Sprint Rev視察、および計画会議。 | 日々の儀式に積極的に参加する。 |
2. スクラム成果物
スクラムプロセスには以下が含まれます。
- ユーザーストーリー: これらは、テスト対象システムの機能に関する簡潔な説明です。保険会社の場合の例としては、「保険料はオンラインシステムを使用して支払うことができます。」となります。
- 製品バックログ: これは、スクラム製品のために収集されたユーザーストーリーのコレクションです。 プロダクトオーナーが準備します プロダクトバックログを管理します。プロダクトバックログはプロダクトオーナーによって優先順位が付けられ、プロダクトオーナーの承認があれば誰でも追加できます。現代のチームは、Jira、Linear、 Azure DevOps、または Asana.
- リリースバックログ: リリースとは、複数の反復作業が完了する期間のことである。 プロダクトオーナーは調整します スクラムマスターと協力して、どのストーリーをリリース対象とするかを決定します。リリースバックログにあるストーリーは、リリースで完了することを目標としています。
- Sprints: ユーザーストーリーを完了するための期間は、プロダクトオーナーと開発チームによって決定され、通常は2~4週間です。
- Sprint やり残し: これは、完了すべき一連のユーザーストーリーです。 Sprint。 中 Sprint バックログとは、作業が割り当てられることはなく、チームが自主的に作業にサインアップするものです。バックログはチームが所有・管理し、残りの作業の見積もりは毎日更新されます。これは、実行しなければならないタスクのリストです。 Sprint.
- ブロックリスト: これは、スクラムマスターが所有し、毎日更新される、未解決の課題と未決定事項のリストです。
- バーンダウン チャート: バーンダウンチャートは、プロセス全体を通して進行中の作業と完了した作業の全体的な進捗状況を表します。未完了のストーリーと機能をグラフ形式で示します。
3. スクラムにおける儀式(プロセス)
- Sprint 計画: A Sprint チームがリリースバックログからストーリーをインポートすることから始まります。 Sprint バックログ。スクラムマスターが管理します。テスターは、さまざまなストーリーをテストするための労力を見積もります。 Sprint やり残し。
- デイリースタンドアップ: デイリースクラムとも呼ばれ、スクラムマスターが主催し、約15分間続きます。デイリースタンドアップでは、メンバーは前日に完了した作業、翌日の予定作業、および作業中に直面した問題について話し合います。 Sprintチームの進捗状況は tracここにいます。
- Sprint Rev見/回顧展: スクラムマスターが主催し、約2~4時間続き、チームが過去1週間に達成したことについて話し合います。 Sprint そして、そこからどのような教訓が得られたのか。
スクラムの役割、成果物、儀式が確立されたら、テスターがこのフレームワークの中で具体的にどのような位置づけになるのかを明確にすることが重要です。
スクラムにおけるテスターの役割
スクラムにはテスターの積極的な役割はありません 通常、テストは開発者が単体テストで実施しますが、プロダクトオーナーも各テストプロセスに頻繁に関与します。 Sprint. プロジェクトの性質や複雑さによっては、スクラムプロジェクトに専任のテストチームが設けられている場合もある。.
次の疑問は、スクラムにおけるテスターの役割とは何か、ということです。次のセクションでは、その疑問にお答えします。
スクラムでのテストアクティビティ
テスターは、スクラムのさまざまな段階で以下の活動を行います。
Sprint 計画立案
- In Sprint 計画段階では、テスターはプロダクトバックログからテストすべきユーザーストーリーを選択する必要があります。
- テスターは、何時間かかるか(作業時間の見積もり)を決定する必要があります。 終わる 選択された各ユーザーストーリーについてテストを実施する。
- テスターとして、彼は、 Sprint 目標は。
- テスターとして、優先順位付けのプロセスに貢献してください。
Sprint
- 開発者の単体テストを支援する。
- ユーザーストーリーが完了したら、テストを実施してください。 テスト実行が行われる テスターと開発者が協力して作業するラボで、欠陥はログに記録されます。 欠陥管理ツール (NAIST) と trac毎日チェックされます。欠陥はスクラムミーティング中に協議および分析されます。欠陥は発見され次第再テストされます。 解決 そしてテストのためにデプロイされます。現代のスクラムチームは通常、Jira、Linear、 Azure DevOps、または Asana このワークフローの場合。
- テスターは、毎日のスタンドアップミーティングにすべて出席し、意見を述べます。
- テスターとして、現在のタスクで完了できないバックログ項目を何でも持ち込むことができます。 Sprint そしてそれを次の Sprint.
- テスターは開発を担当しますping 自動化スクリプト。彼または彼女は自動化テストをスケジュールします。 継続的インテグレーション (CI) システム納期が短いため、自動化が重要視されています。テスト自動化は、市場で入手可能な様々なオープンソースツールや有料ツールを活用することで実現できます。これにより、テストすべき項目がすべて網羅されることが保証されます。チーム内での密なコミュニケーションにより、十分なテストカバレッジを達成できます。
- RevCI自動化の結果を確認し、関係者にレポートを送信する。
- 承認されたユーザーストーリーに対して、非機能テストを実施する。
- 顧客およびプロダクトオーナーと連携し、受け入れテストの受け入れ基準を定義する。
- の終了時 Sprintテスターは場合によっては受け入れテスト(UAT)も実施し、現在のテストの完了を確認します。 Sprint.
Sprint 回顧
- テスターとして、現在の Sprint.
- テスターは、得られた教訓とベストプラクティスを特定する役割を担います。
これらのテスト活動がそれぞれ実行されると、 Sprintチームは進捗状況を伝えるために明確な指標に依存しており、そこでテストレポートが不可欠となる。
テストレポート
スクラムテストメトリクスレポートは、プロジェクトに関する透明性と可視性をステークホルダーに提供します。報告されるメトリクスにより、チームは進捗状況を分析し、製品を改善するための将来の戦略を計画できます。Jira、Linear、 Azure DevOps、そして Asana これらのレポートの多くは自動的に生成されます。レポート作成によく使用される指標は2つあります。
バーンダウン チャート: 毎日、スクラムマスターは、残りの作業の見積もりを記録します。 Sprintこれはバーンダウンチャートで、毎日更新されます。
バーンダウンチャートは、プロジェクトの進捗状況を素早く把握できるチャートです。このチャートには、プロジェクトで完了しなければならない作業の総量、各段階で完了した作業量などの情報が含まれています。 Sprint、などなど。
速度履歴グラフ: 速度履歴グラフは、各チームが到達する速度を予測します。 Sprintこれは棒グラフであり、チームの成果が時間の経過とともにどのように変化したかを表しています。
その他、役立つ可能性のある指標としては、スケジュール消化率、予算消化率、テーマ完了率、完了したストーリー数、残りのストーリー数などが挙げられます。




