W-model makes the importance of testing and the ordering of the individual testing activities clear. It also clarifies that testing and debugging are not the same thing.
the above information is form stickyminds.com.
In Application testing how we are going to seperate debugging and testing. In w modal how we are going to relate both.Can you please be elobrate on this topic.
As someone that strongly believes that testing is not a bug hunt, here is my approach. I'll try to keep it jargon and methodology free.
We have a requirement, we design a solution, we produce code, we test that design and test that code.
The requirements must be clarified, detailed and unambigous - we use QA and QC to try to achieve that.
The design and code are similarly subject to QA and QC to try to remove misconceptions, ambiguities, faulty logic, faulty coding etc. (Remove bugs at the source).
So, we finally end up with an executable we want to test.
We design test cases, with the aim of making sure the design is honoured, that the design matches the requirements, and that no "sillies" have slipped through the net. We also want to ensure that new function has not regressed existing functions, that all new functions work together, and that exception handling is covered.
Again, we use QA and QC to validate the test collateral.
The classic approach is:
Regression test pre-existing functionality.
Somewhere we also test Non Functional Requirements (Load, Stress, Performance etc), it is the subject of debate at what stage we do those tests.
Then, we request that the users confirm our satisfaction (or otherwise!) - with User Acceptance Testing.
All that can be planned.
Then, during test execution, we find a bug.
We now face two additional tasks:
1. Test the fix
2. Test for any regression caused by the fix - both in the directly affected function and in the complete application.
This is all what the W-Model is designed to illustrate.
You cannot separate debugging from testing, it is a natural by-product of testing. What you can do is specify how you handle bug fixes, this is what you can separate out.
Whether we use waterfall or iterative methodology, we still carry out these steps - it is the granularity and number of iterations that change.