That is a tough question. I would actually hate to be asked it. On one hand it almost seems like they want you to say that you're covering 100% (which is never the case). I also hate giving vague answers but I'd probably have to say something like, "I've got enough coverage when I feel that we've limited the risk of the release as much as possible."
It's a bit of a fluff answer, but it's almost like they're baiting you. It's a loaded question at the very least.
You can describe the coverage vs the effort as a flattening curve. There is a point where more effort no longer has significant impact on coverage or quality. Your aim should be to test close to that point so you have maximized your return of investment of time and resources.
Well, it is really fluffy as well but makes you look good in an interview... And truth is, it works as a method to determine your test efforts.
Test coverage is simply to assure that the test process has covered the application. There are many methods that can be used to define and measure test coverage, including:
• Statement coverage. Use trecability matrix to make sure all requirement statement being tested.
• Branch Coverage. Excecute all branches.
• Path coverage. Execute all possible paths between units.
• Integration coverage. Determine extent to between units behavior match design specification. Increase to an acceptable level that units will behave correctly under all circumstances of interest.
&#61607; Decision table are used to document complex business rules that a system must implement.
&#61607; Boundary data coverage
&#61607; User specified data coverage
&#61607; When the functional testing provides a less rate of additional coverage for the effort expended, conduct white-box or structural testing on the remaining parts of the application until the coverage goal is achieved.