Some testers who agree they can't know they've found all the bugs in a product still talk loosely about what it means to be finished testing. Saying "it will take me five days to test that" can be interpreted to mean that you think you will have completely tested that part of the product in five calendar days. And that might be taken to mean you will find every bug in five days. Completeness is more often implied than stated. Either way, it's a concept you must treat with great care. Think about what complete testing might mean:

1) Completed the discovery of every bug in the product.

2) Completely examined every aspect of the product.

3) Completed the testing that you believe is useful and cost-effective to perform at this time.

4) Completely fulfilled the stated objectives of the project to the best of your ability.

5) Completed the agreed-upon tests.

6) Completed everything humanly possible to test, under the circumstances.

7) Completed everything you knew how to do.

8) Completed your part of the testing, regardless of anyone else's part.

9) Completed a broad, but not deep, pass of testing on the product.

10) Completed one kind of testing on the product.

11) Completed the time period assigned to testing.If you take care to clarify what you

mean and don't mean by "complete" or "finished" or "done," then you're probably safe. You're less likely to be blamed for not doing your job and better able to defend yourself if you are blamed.

Be aware that the definition of "complete" is not the kind of thing that can be settled conclusively at the start of the project. You have to reconsider it as the test project evolves and as new test tasks crop up. To cope with the general problem of miscommunication about completeness, share some of the details of your test process with your clients.

Summarize the testing you do and why that testing is worthwhile, and tell your clients about other worthwhile testing you are not doing and why you aren't doing those tests.