BDDプロジェクトにおけるQAの役割は何ですか？
自動受け入れテストでユーザーストーリーを100％カバーするBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何でしょうか？
開発者が製品所有者と一緒に受け入れテストを書くと思いますが、それが愚かな仮定のように思われるかどうか教えてください。
私は古すぎるかもしれませんが、製品をクライアントにリリースする前に、最新の開発またはプロセス手法でさえ別の目、新鮮な目で置き換えることはできません。
製品が単に他の開発者向けのAPIである場合でも、QAを使用してAPIユーザーとして考えることができ、自分やクライアントが事前に考えていなかったテスト/使用シナリオを提供できます。
製品がユーザーインターフェースに基づいている場合は、クライアントに送信する前に最終結果を他の人（あなたやチームの誰かではない）に見てもらいたいと思います。
私たちの業界の他の流行語と同様に、BDDは100％カバーしても 銀の弾丸はありません です。
100％のカバレッジは100％のテストと同じではありません。
ATDDプロジェクトのQA担当者は、テストの作成や、まだ存在する他のタイプのテストの実行を支援する人物だと思います。つまりUIテスト、破壊テスト、および負荷/ストレステスト。
しかし、私はATDDプロジェクトを考えたことはありません。
QAの仕事はアプリケーションを壊すことであり、開発者の仕事はそれを壊さないことです。したがって、彼らは異なる視点からテストを書きます。たとえば、開発者は期待される動作が発生するかどうかを確認するためのテストを作成し、QAはテストを作成して、開発者がユーザーが行うことを決して考えないことをユーザーが実行したときに何が発生するかを確認します。さらに、開発者は要件を誤って解釈することがよくあり、QAテストは、解釈が開発者の意図とは異なる場合にキャッチし、プロジェクトの利害関係者と協力して、どちらが正しい解釈であるかを判断します。コードを作成した開発者が作成したテストは、開発者が大きな盲点を持っているため、しばしば大きな盲点があります。たとえば、エッジのケースではなく、97％の時間で何が起こるかをテストします。
以前の雇用主では、QAの役割は製品をテストするのではなく、開発者がQAによって定義された以前に定義された受け入れテストに関して彼らがやろうとしていることを本質的に実行することを保証することでした。
一方、製品の所有者は、テストとはまったく関係がありませんでした。あらゆるレベルのテストに対処する私見は製品所有者の役割ではありません。
ある時点で、従業員に自信を持つ必要があります。チェックとバランスは良好ですが、開発サイクル内でソリューションを強制する必要はありません。実際には、従業員の作業倫理のごく一部に対処するだけです。
完璧な世界では、共同で受入テストを作成することで、devとQAとのコラボレーションが形式化されるのがわかります。 QAは、開発チームとは異なる側面をテーブルに持ち込む必要があります。 QAは、製品の初期段階でパイに手を携え、サイクル全体を通じて関与し続ける必要があります。一方、製品の所有者は、製品の現在の状態、リスクなどについて理解するためにQAを行い、全体的な方法で製品に焦点を合わせる必要があります。製品を構成する特定のニュアンスではありません。
BDDの一部は、ステークホルダーが協力して受け入れ基準を作成する3 Amigosアプローチを適用しています。 QA/Devはステップコードを記述して、シナリオを受け入れテストとして実行できます。 BDDツールが自動的に実行するのと同じ受け入れテストを手動で実行するQAの価値はどこにありますか？ QAの付加価値は、これらの受け入れテストを検証し、スクリプトによる受け入れテストの外で手動の探索的テストを実行することです。複製は通常同じ結果になります。
開発者は要件と仕様を書き直さず、QAはアプリコードを書き直さない... QAは、開発者が受け入れるテストとまったく同じスクリプトテストを実行する必要がない可能性があります。 DevsがQAの帽子をかぶる時が来ました！
私の経験から：私たちはユニットテストを使用してコードの90％以上をカバーしていました。統合テストと毎時ビルドもありました。 BDDのjBehaveテスト。
QAの役割：-テストにユーザーストーリーを採用する-手順の背後にあるコードを記述する-IDEAのRestClientプラグインを使用した探索テスト（したがって、いくつかの大きなバグが見つかりました）