BDDプロジェクトでのQAの役割は何ですか？

自動受け入れテストでユーザーストーリーを100％網羅したBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何ですか？

開発者が受け入れテストを製品所有者と一緒に書くことを想像していると思いますが、それが馬鹿げた仮定のように思えたら教えてください。

たぶん私は古すぎるかもしれませんが、最新の開発技術やプロセス技術でさえ、クライアントに製品をリリースする前に別の目、新鮮な目を置き換えることはできません。

製品が単に他の開発者向けのAPIである場合でも、QAを使用してAPIユーザーとして考えることができ、お客様またはクライアントが事前に考えなかったテスト/使用シナリオを提供できます。

あなたの製品がユーザーインターフェースに基づいて重い場合、間違いなくあなたは別の人（それはあなたやあなたのチームの誰かではない）がクライアントに送る前に最終結果を見て欲しいです。

業界の他の流行語と同様に、BDDは、100％のカバレッジであっても特効薬ではありません。

100％のカバレッジは、100％のテストと同じではありません。

ATDDプロジェクトのQA担当者は、テストの作成と、まだ存在する他のタイプのテストの実行を支援してくれる人だと思います。すなわち、UIテスト、破壊テスト、および負荷/ストレステスト。

しかし、私はATDDプロジェクトを実行したことがありません。

QAの仕事はアプリケーションを破壊することであり、開発者の仕事はアプリケーションを破壊しないことです。したがって、彼らは異なる視点からテストを書きます。たとえば、開発者は期待される動作が発生するかどうかを確認するテストを作成し、QAは、開発者がユーザーが行うことを決して考えないことをユーザーが行うと何が起こるかを確認するテストを作成します。さらに、開発者は要件を誤って解釈することが多く、QAテストは、解釈が開発者が意図したものと異なる場合にキャッチし、プロジェクトの利害関係者と協力して正しい解釈を判断します。コードを書いた開発者が書いたテストには、開発者が大きな死角を持っているため、しばしば大きな死角があります。たとえば、97％の時間で何が起こるかをテストしますが、エッジケースはテストしません。

以前の雇用者でのQAの役割は、製品をテストすることではなく、QAによって定義された以前に定義された受け入れテストに関して開発者が本来行うことを実行したことを保証することでした。

一方、製品の所有者はテストとはまったく関係がありませんでした。あらゆるレベルのテストに対処することは、製品の所有者の役割ではありません。

ある時点で、従業員に自信を持たなければなりません。チェックとバランスは良好ですが、開発サイクル内でソリューションを強制する必要はありません。実際には、従業員の労働倫理のごく一部のみに対処することです。

完璧な世界では、開発者とQAが共同で受入テストを書くことで形式化するというコラボレーションが見られます。QAは、開発チームと同様に、テーブルに異なる側面をもたらす必要があります。QAは、製品の初期段階でパイに手を入れ、サイクル全体を通して関与し続ける必要があります。一方、製品の所有者は、製品の現在の状態やリスクなどについて理解するためにQAを実施し、全体的な方法で製品に焦点を当てる必要があります。製品を構成する特定のニュアンスではありません。

私の経験から：ユニットテストを使用して、コードの90％以上をカバーしていました。統合テストと1時間ごとのビルドもありました。jBehaveはBDDのテストを行います。

QAの役割：-テストのためのユーザーストーリーの採用-ステップの背後にあるコードの記述-IDEA用のRestClientプラグインを使用した探索テスト（したがって、いくつかの大きなバグが見つかりました）

BDDの一部は、利害関係者が協力して受け入れ基準を作成する3 Amigosアプローチを適用しています。QA / Devはステップコードを記述して、シナリオを受け入れテストとして実行させることができます。BDDツールが自動的に実行するのと同じ受け入れテストを手動で実行するQAの価値はどこにありますか？QAの付加価値は、これらの受け入れテストを検証し、スクリプト化された受け入れテスト以外で手動の探索的テストを実行することです。通常、複製しても同じ結果が得られます。

開発者は要件と仕様を書き換えず、QAはアプリコードを書き換えません...開発者が受け入れテストとして実行するのとまったく同じスクリプトテストを実行する必要がない場合があります。開発者がQAハットを着用するときが来ました！