スクラムでの品質保証（テスト）
スクラムチームにリリースレトロスペクティブを用意しました。私たちはリリースプロセスについて多くのことを話しました。
私たちの会社は、本番環境でのバグを許容できないため、頻繁にリリースするという従来のスクラムマントラを守ることができないと指摘しました。
つまり、私たちは医療会社です。生産におけるバグは、患者のケアに問題を引き起こす可能性があります。 （迅速な修正リリースは、バグによって悪影響を受けた患者には役立ちません。）
スクラムには正式な品質保証プロセスがないことを指摘しました。 （テストは開発中に行われることが想定されています。）
次に、スクラムには、本番環境でのバグの暗黙の予想があると述べました。 （早期かつ頻繁にリリースするプロセスに基づいています。）スクラムプロセス部屋の人々は、スクラムはそうではないと述べました。彼らは、適切に行われたスクラムは、本番環境ではバグがなくなる可能性があると述べました。
だからここに私の質問です：
スクラムのテストと品質保証はどのように機能しますか？（本番環境でのバグの発生が非常に少ないように）
OR
（迅速なフォローアップリリースと共に）スクラムでバグがある程度予想されるドキュメントはありますか？
注：これは完全なエンタープライズレベルの開発用です。 6つ以上のWCFサービス、いくつかのサービスバス、4つのデータベース、WPFフロントエンドアプリケーション、およびWebインターフェイスがあり、それぞれ約6〜8人の2つの別々のスクラムチームによって作成されています。 これは、最初に正しくコーディングするだけの答えは現実的ではないことを意味します。
注II：バグのないソフトウェア製品はないことを知っています。しかし、私たちのリリースプロセス（非アジャイル）は、開発プロセスを通過する少数をキャッチし、ソフトウェアを「バグなし」レベルにかなり近づけます。
スクラムのテストと品質保証はどのように機能しますか？ （本番環境でのバグの発生が非常に少ないように。）
実際、SCRUMはこれに対応していないと思います。 SCRUMは製品/プロジェクトのすべての段階をカバーするわけではありません。 SCRUMの主な目的は、開発自体を整理することです。「機能についてのアイデアがある」から「開発チームがこれは本番稼働の準備ができていると考える」までの部分です。プロジェクトの最初の部分（基本的なアイデア、プロジェクトのビジョン、利害関係者の発見、予算の獲得など）は対象外であり、最終的な提供（導入、顧客フィードバックなど）は対象外です。
したがって、SCRUMチームの完了後に追加のステージが必要だと感じた場合は、必ずQAテストの個別のステージを用意してください、回帰テスト、認定など、本番環境に移行する前に行ってください。
テストを行って関係者からフィードバックを得ることができるため、頻繁なリリースの価値は引き続き得られます。 SCRUMは"potentiallyShippable product"について話していることに注意してください。これは、実際にはさまざまな理由で製品を出荷したくない場合があるためです。 。
注：明らかに、個別のQA /テスト段階の欠点は、実際に機能を顧客に出荷するのに時間がかかることです。ただし、新機能を迅速に出荷するよりも品質が重要である場合、それはあなたにとって適切な妥協案である可能性があります。それは、利害関係者と開発者が決定することです。
スクラムでは、各履歴に「完了」の定義があります。1つの履歴が「完了」と見なされると、この定義が満たされ、本番環境に移行する準備ができます。プロダクションのバグが頻繁に発生する場合は、doneの定義を改善し、履歴がこの定義を確実に満たすようにする必要があります。
スクラムは、あなたのような難しい質問が通常発生するときに、軽量のプロジェクト管理手法であり、スクラムには具体的な答えがありません。他のアジャイル手法（TDDまたはエクストリームプログラミングからのペアプログラミングなど）でこれらの答えを見つける必要があります。たとえば、すべてのユーザー履歴が渡さなければならない、doneの一般的な定義は、次のようになります。
- すべての単体テストに合格し、改訂されたカバレッジ
- コードが改訂されました（ペアプログラミングが好まれますが、これは単なる例です）。
- テストサーバーに展開された機能
- QA担当者によって改訂された機能。
- その負荷テスト
- ...
必要なものは何でも追加できます。重要なのは、この定義を満たすユーザー履歴が、プロジェクトに必要な品質レベルで確実に生産され、運用に移行できることです。
QAについてあと2つだけ
- QA担当者は別のチームになることはできません。QA担当者はチームの一部です。 DoDを満たすには、スクラムチームにすべてのスキルが必要です。
- 自動テスト（TDDかどうかにかかわらず）が必要な品質レベルを達成するのに十分でない場合は、自動テストでより良い仕事をする方法を考えてください。おそらく、QA担当者がこの自動化を支援できます。長時間（おそらく数日）の手動回帰テストを実行する必要がある場合、迅速なリリースは不可能です。何かが実行できることを確認する自動（または半自動だが非常に迅速）な方法がない場合、スクラムは迅速なリリースを提供できません。必要な品質レベルの生産に。
テスト駆動開発を実践している場合、スクラムはバグのないものになる可能性があります。V＆Vチームにリリースするソフトウェアが単体テストで設定されたすべての期待を満たしているため、インソファーです。
別の言い方をすれば、ソフトウェアにバグがないことを証明することはできないかもしれませんが、すべての単体テストに合格したことを証明できます。単体テストは、スーパーバイザーまたはマネージャーがサインオフできるものです。これは医療グレードの認定ではありません（まだQAが必要です）が、バグのない状態であることを示す負担をチームから解放します。
したがって、リリースごとにバグのないソフトウェアを主張する（おそらく正しくない主張）代わりに、承認された単体テストが合意された範囲内で信頼性を証明することを実証します。
QAにリリースする前に、ソフトウェアの機能テストを実行することもできます。 QAは、これらのテストの一部またはすべてを開発するのに役立ちます。
さらに読む
http://en.wikipedia.org/wiki/Therac-25
Therac 25は優れたケーススタディです。開発プロセスの問題（および特定のソフトウェアバグは発見されなかった）が失敗の主な理由として挙げられたためです。