回答:
すべきではない！
すべての作業を行って停止し、すべての問題を修正することは非常に困難です。QAプロセス中に見つけた問題を修正する場合、別の方法を実行する方がよいことがわかります。
すべてをロックステッププロセスと考えるのではなく、より循環的なものにしてください。いくつかの機能をコーディングしてテストします。さらにコードを記述してテストします（古いものはまだ機能します）。このより流動的なプロセスは、すべてをフロントロードしようとする困難な船を軽減します。締め切りに近づいても、コードのフリーズ（バグの修正のみ）の概念はありますが、重要なのは、早期に頻繁にテストすることです。
まあ、コードのセクション全体が非稼働状態でQAに渡されている場合、おそらく、何らかのユニット/統合テストをプロセスに追加することを検討する必要があります。QA担当者に、コードの単体テストまたは統合テストに失敗したことを知らせて乱用しないでください。
仕様に従ってコードが提供されれば、バグがない（そしてQAの必要がない！）ので、それは細かいところです。コードが日常的に仕様に反映されていないという事実が、そもそもQAを行う理由です。
しかし、私は実際にそれがあなたが話していることだとは思いません。つまり、開発チームはコーディングに少し時間がかかりすぎているように見え、機能していないように見える明らかな大きな問題があるということです。機能A、B、およびC（仕様内）ごとにユニットテストが存在する必要があることを事前にレイアウトし、コードとテストを（チームリーンまたはマネージャーが）個別にレビューすることで、この種の問題を緩和することができます。 。
少なくとも、開発者は「ハッピーパス」をテストするべきだったと私は主張します。彼らが期待されたデータを入力するならば、それはそれが仕様がそうするべきであると言うことをします。それほど多くをしない開発者は質問されるべきです。
開発者が明らかなエッジケースをテストしていない場合もがっかりします。データベースに対して文字列が長すぎる、明らかに無効なテキスト、数字を入力する必要がある場所に文字を入力した場合などです。それが頻繁に発生する場合は、再度質問する必要があります。
ただし、仕様で特に言及されていない場合、開発者が名前を大文字と小文字のみに制限し、一部の名前にアポストロフィが含まれていることを忘れたり、2011年2月29日の日付を許可したりすると、少しわかりやすくなります。 。彼らが何度も同じ間違いをしない限り。
QAチームは極端なエッジケースをピックアップする必要があります。私はモンキーテスターよりもQAを好みます。ランダムなゴミを入力して、アプリをそのように壊すことができるかどうかを確認します。
Web開発では、QAはさまざまなブラウザーを試し、コードに影響を与える可能性のあるプラグインを見つけようとします。彼らはJavascriptとCSSをオフに切り替えて、それで何ができるかを確認する必要があります。そういうこと。開発者がそうすることを期待するなら、あなたはそれに多すぎるお金を費やしています。
機能しない機能が提供されている場合、問題は開発とQAの間ではなく、開発と製品所有者の間の問題です。
製品の所有者と開発者は同じチームのメンバーである必要があり、機能を「完了」と見なすために必要な作業を定義し、コードがそのニーズを確実に満たすように協力する必要があります。
コードが配信されるとき、テストは単なる形式的なものでなければなりません。これは、製品の所有者が開発者と協力して、すべてのユースケースがカバーされていることを確認する必要があるためです。
（プロのテスターがいる場合、彼らはチームの一員であり、あらゆる段階で関与する必要があります。）
QAに入る前に、開発者にコードのウォークスルー/デモを提供するように依頼するプロジェクトのスクリーニングプロセスがあります。QAテスターだけでなく、コードのビジネスオーナー、カスタマーサービス、マーケティング/デザインも含まれます。これは、少なくとも簡単なユースケースで開発者に焦点を合わせる傾向があり、さまざまなチーム間の結果として生じる議論により、仕様が変更され、QAへの参加が遅れることがあります。可能な場合は、プロセスのかなり早い段階でQAを行います。これにより、コードがまだ暖かいうちにバグを修正できます。ただし、「公式」QAが始まる前にウォークスルーを行います。
誤ってQAの代わりに本番環境に移行した場合に気が動転する場合は、コードをQAに送信しないでくださいと時々言いました。重大な機能不全のあるコードはQAに属しません（特定の状況を除く）