不完全な機能の機能テスト
実際には完了していない機能に対して機能テストを実行する（そして自動テストスクリプトを作成する）といういくつかのタスクがありました。
たとえば、ユーザーがアイテムを作成、読み取り、更新、削除できることを確認するためのプロジェクトのCRUDテスト。作成プロセスを開始するときに、すべてのフィールドに入力し、「次へ」というボタンを押します。モックアップとワイヤーフレームには、[次へ]ボタンをクリックした結果として続くはずの特定のページがあります。このページが表示されることを期待して、そのアイテムの作成に使用したページが代わりに更新されます-しかし、アイテムdoesは期待どおりにリストに追加されます（ただし、データが不完全であるためis「次へ」をクリックした後に追加する詳細情報になるはずです）。
私はこのようないくつかのタスクを実行しました。そこでは、機能的にテストし、完了していないプロジェクトの機能の自動スクリプトを作成しようとしています。私にとって、ユニットテスト（コード自体のテスト）は、開発のこの段階で意味があります。機能テストはしません。私はSQAに不慣れで、ソフトウェアの世界で新しい専門家なので、私の経験不足が邪魔になっているかどうかはわかりません。次に、「完了」すると予想される機能をテストするように言われているので混乱しますが、ドキュメントを参照しても、実際には完全ではありません。次に、何かがおかしいと思って頭をかきました。その直後に、開発者に何かが足りないかどうか尋ねるために中断しました。これは時間の非効率的な使用のようです。
これはテストを行うための適切な方法ですか？プロジェクトの機能を最初に完了する必要がありますか？
残念ながら、すべてがテストに完了するのを待つと、一度に多くの間違ったものを発見する可能性があり、混乱を一掃することはストレスの多い悪夢になります。たぶんその時だけ-遅すぎる-あなたは基本的な仮定に欠陥があることに気付くでしょう（ 時には壊滅的な結果を伴う ）。
ソフトウェアの品質は、開発プロセスの最初から最後まで確保する必要があるものです。また、品質の1つの側面は、開発された部品が意図したとおりに、できるだけ早く、可能であれば、より複雑な部品に組み立てる前に機能することを保証することです。
テストが単一であるほど、バグを見つけやすくなります。機能をテストする前に2つの相互に関連する部分が終了するのを待ってテストが失敗した場合、最初に問題がどの部分にあるかを見つける必要があります。
テスト駆動開発 アプローチもあり、より高い信頼性を実現するには、最初にテストを記述し、次にコードを記述する必要があると主張しています。
そうです、すべてが完了する前にテストするのは普通です！
ここでテクニックについて説明します。 テストダブル の使用に興味があるかもしれません。 すべての詳細 を入力せずに、テストスタブ、モック、偽のオブジェクトを使用して、単体テストですでに存在するものに焦点を当て、チャットがまだパイプ内にあるという仮定をシミュレートできます。