アジャイルにおける品質保証（テストではない！）の役割
ウィキペディアから：
品質保証とは、製品、サービス、または活動の要件と目標が満たされるように、品質システムに実装された管理活動と手続き活動を指します。[1]エラーの防止を実現するのは、体系的な測定、標準との比較、プロセスの監視、および関連するフィードバックループです。[2]これは、プロセス出力に焦点を当てた品質管理とは対照的です。
次の記事を読んで、QAとテスト（品質管理）の違いを理解してください。 http://blogs.msdn.com/b/alanpa/archive/2006/02/26/539527.aspx =
私が理解したいのは、アジャイル/スクラムでテスターではないQAエンジニアのための場所があるかどうかです。アジャイルは故意にプロセスとドキュメントが不足している（マニフェストにさえあります）、それがQAの専門分野です。それで、アジャイルにはQAエンジニアもいるべきでしょうか？
私自身はQAエンジニアではありません（私はテストリードです）が、私には友達がいるので、私が尋ねているのはそのためです。
確かに、アジャイル組織には 品質保証 の役割があると思います。特に 品質管理システムISO9001 などを遵守しなければならない組織には、 =、 医療機器業界ではISO13485 または 航空宇宙業界ではAS90 は、顧客の要件、規制、または企業の要件を満たすために使用します。
覚えておくべき重要なことが2つあります。まず、品質保証は最終製品の品質だけでなく、すべての中間作業製品に関心があります。ソフトウェア開発は、何らかの形で顧客の要求を取り込み、ソフトウェアを出力する（そしておそらくそのソフトウェアのサポートを行う）ブラックボックスと見なすことができます。ただし、そのプロセス中、開発チームは、ソフトウェアの設計と構築に使用できるものへのこれらの要件の変換、設計の作成、プロトタイプとシミュレーション、プロダクションコード、テストコード、サポートスクリプト、手動手順（テスト、デプロイメント用）を行います。 ..）、ユーザーマニュアルなど-それらのいずれかは、その情報に依存する下流のアクティビティに影響を与える欠陥を持つ可能性があります。品質保証は、これらの作業成果物で欠陥がどのように発見されるかだけでなく、それらの欠陥がどのように防止されるかに関係しています。第二に、品質保証はプロセス品質にも関心があります-私たちがどれだけうまく仕事をしているか。ここで明らかなのは作業成果物の品質ですが、作業を行うのにかかる時間も（特に）長くなります。
アジャイルの信条の2つは、「プロセスとツールよりも個人と相互作用」を支持することと、「包括的なドキュメントよりもソフトウェアを操作すること」を支持することです。ただし、どちらも、プロセスがあるべきではない、またはいかなる種類のドキュメントも必要がないとは言いません。品質管理システムを実装しようとしている場合、監査中に実際に行われる作業と比較できるドキュメントのある程度のレベルが必要になる可能性があります。これらのアジャイルの理想は リーンソフトウェア開発 のいくつかの概念でよりよく表現されていると思います。プロセスの遅延を取り除き、官僚主義を減らし、内部コミュニケーションを改善し、学習を拡大し、チームが目標を最もよく達成する方法について決定を下します。
QA組織は、内部監査を担当するだけでなく、無駄を検出し、遅延を見つけ、文書化された内容が各開発チームにプロセス要件を実装するための十分な余裕を与えることを保証することによって、俊敏性または無駄のないソフトウェア開発をサポートすることもできます（個々のプロジェクトに最適な方法で顧客、規制当局、企業の義務などから課せられますが、組織全体である程度の一貫性があり、新しい一連のプロセス全体を再学習する必要なく、プロジェクト間を移行できます。技術的な学習曲線の上にメソッド。
しかし、あなたのコメントの一部に基づいて、これが進んでいる方向はアジャイルでも無駄でもないようです。プロセスドキュメンテーションを作成するための詳細な手順を説明するのは、うれしいことです。あいまいであり、各プロジェクトチームに必要なものを実装する余地を与え、組織全体でプロセスの実装（したがってプロセスの品質と製品の品質）に大きなばらつきをもたらす場合。それが具体的で詳細すぎると、官僚主義が追加される可能性が高く、包括的なドキュメントが相互作用や機能するソフトウェアの邪魔になるでしょう。俊敏性とプロセス品質に関する情報を取得する能力（測定と一定レベルの一貫性を介して）の間のバランスが必要です。
以下も参照してください。
「テスト」と「品質保証」の違い（または関連性）を理解しているかどうかはわかりません。最終的にQAを行うには必須テストを行う必要があります。
QAは、定義すると、アジャイルマニフェストの価値である包括的なドキュメントに対するソフトウェアの動作に対して少し聞こえます。あなたは本当にそのすべてのプロセスの文書化が必要ですか？既存のプロセスをアジャイルプロセスに絞り込もうとしていますか。ドキュメントが本当に必要な場合は、それを完了の定義に追加する必要があります。
アジャイル方法論は、垂直スライスを行う「一般化するスペシャリスト」を好みます。つまり、すべてのチームメンバーがすべてのストーリーを完了できる必要があります。開発者がテストし、QAがテストし、誰もが品質を高めるために努力する必要があります。
アジャイルチームは、プロセスを改善するポイントとして、回顧を使用します。
私がすべての人で働いてきたチームでは、品質に責任があります。通常、イテレーション/スプリントでテスト可能な何かがテスターの準備ができるまでに遅れがあります。この時間で、ストーリーのテストにちょうど間に合うようにQAアクティビティを実行できます。反復内でのこのスコープクリープの導入に注意してください。
多くのアジャイルプロセスは、その詳細レベルについて規範的ではなく、決定するのはチームに任されています。自己組織化チームはQAスペシャリストを求めますか？
品質運動の創設者（Shewart、Demming、Juran）の出版物を読むと、品質は経済的問題であることがすぐにわかります。品質の欠如は、多くの無駄があることを意味します。品質向上は、プロセスから廃棄物を排除するプロセスです。 Shewart、Demming、およびJuranは製造を扱っていましたが、ソフトウェア開発にも同じ考え方が当てはまります。ソフトウェア開発では、無駄の主な発生源は、常に顧客の機能要件が満たされていると想定してやり直すこと（エラーの修正、再テスト、再配備）です。次に最も高い問題は、顧客が購入したいものを生み出していないことです。ソフトウェアの品質にもユーザーが関与します。不十分な設計または信頼性の欠如は、ソフトウェアの使用コストを増加させる可能性があります。
品質保証の役割は、製品をテストすることではありませんが、テストデータが適切に記録されていれば役立ちます。品質保証の役割は、発生する問題の数を減らし、それらを修正するコストを削減する可能な方法を調査することです。これはコードの欠陥に限定されません。
エンジニアリング開発における伝導の最悪のプロセスの1つは、設計者/開発者に機能の責任を負わせることです。問題は、複数の開発者またはチームが同じコンポーネントを変更して目的の機能を提供する必要がある場合に発生します。その結果、統合後（システムレベルのテストなど）まで発見されない欠陥が発生します。理想的な状況では、システムテストで欠陥がまったく検出されないはずです。かなりの数が見つかった場合、すべてのテストが完了した後でも、製品に非常に多くの欠陥が残っていることを意味します。これは信頼できない製品をもたらします。
この問題に対する答えは、コンポーネントまたはサブシステムベースの開発であり、1人の開発者またはチームだけがサブシステムの特定のコンポーネントを変更できます。機能指向のショップでは、QA担当者の役割は、チームがサブシステム指向のプロセスに移行するのを支援することです。
その他の事業では、メトリックが収集され、将来を予測するために使用されます。多くのソフトウェアショップで重要な測定基準は、検出された欠陥または未解決の欠陥です。しかし、これは改善の役に立たない指標です。重要な測定基準は、作業成果物にまだ残っている欠陥の数です。要件の欠陥（要件があると仮定した場合）は、最終的には設計で発生したエラーとともに設計に含まれます。設計上の欠陥（設計があると想定）は、コーディングエラーとともにコードに含まれます。品質保証は、これらのアイテムが作成および検証されたときに収集されたメトリックを使用して、以前の作業成果物から持ち越された欠陥の数を最小限に抑える方法を見つけるのに役立ちます。
品質保証は製品の品質に責任を負いません。それらを生産する人々は責任があります。品質保証は、途中で生じた混乱を発見し、それらを経営陣に指摘して、深刻で費用のかかる問題になる前に対処できるようにする責任があります。