Quality Upfront - Eliminate Defects upfront
Submitted by MKBala on Sun, 23/10/2005 - 21:51.
functional testing
If you are a Software Tester in Quality Control area, how many times have you wished that you get a decent code so that you could perform more Functional Testing and not waste 1/4 th to 1/2 of the time fighting basic defects.
Yes, if you think thats a miracle, its really not and my recent experience has proved the results fruitful and repeatable. Going by the SDLC cycle, lot of times Developers are under pressure with their deadline and there is a high probability that the code quality is less than acceptable. I have been in a lot of projects where Quality Control end up Unit testing. Though its for a good cause, thats not the intention. To alleviate this, how about expediting testcase creation and a sub-group in development perform string testing with the testcases that are developed by Quality team. This eliminates duplicate testcase development by the String test team and also ensures more quality upfront.
Having said there are few points to be considered following the above model
Caution 1 : Set of testcases chosen for String testing should be analysed so that they have more screen coverage (or) logic coverage since we want to catch as many bugs as possible
Caution 2 : Testcases that pass in String Test now pass in Quality testing 99% of the time. However the Quality team should not be influenced by this fact especially during testresult validation. Defects missed by the String test team could be overlooked if the repeated testcases are taken for granted.
Caution 3: With the model working and providing great value to the project, caution needs to be taken to make sure that there is good coordination between Development team and the Testing team. When not followed in right spirits, this could result in pointing fingers when there is a problem and could result in contention for credits when the model works excellently well.
However this is not a Severity 1 problem :)
My ears open for any thoughts on similar experience (or) better approach .
Yes, if you think thats a miracle, its really not and my recent experience has proved the results fruitful and repeatable. Going by the SDLC cycle, lot of times Developers are under pressure with their deadline and there is a high probability that the code quality is less than acceptable. I have been in a lot of projects where Quality Control end up Unit testing. Though its for a good cause, thats not the intention. To alleviate this, how about expediting testcase creation and a sub-group in development perform string testing with the testcases that are developed by Quality team. This eliminates duplicate testcase development by the String test team and also ensures more quality upfront.
Having said there are few points to be considered following the above model
Caution 1 : Set of testcases chosen for String testing should be analysed so that they have more screen coverage (or) logic coverage since we want to catch as many bugs as possible
Caution 2 : Testcases that pass in String Test now pass in Quality testing 99% of the time. However the Quality team should not be influenced by this fact especially during testresult validation. Defects missed by the String test team could be overlooked if the repeated testcases are taken for granted.
Caution 3: With the model working and providing great value to the project, caution needs to be taken to make sure that there is good coordination between Development team and the Testing team. When not followed in right spirits, this could result in pointing fingers when there is a problem and could result in contention for credits when the model works excellently well.
However this is not a Severity 1 problem :)
My ears open for any thoughts on similar experience (or) better approach .