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