Per the process, testing and development should start at the same time. That is what is called V testing .
I am trying to map the development activities with testing activities.
Can some one please provide more inputs on this one.
<font class="small">Code:</font><hr /><pre>
Development activities Testing/Quality Activities
Analyzing business requirements <===========> Analyzing business requirements
Developing conceptual design<==============> Analyzing testing feasibility
Developing high level design<===============> Developing testing strategy
(This includes, testing coverage of the applications,
what kind of test types to be adopted, like
Integration, system, functional, regression, performance etc..)
Developing low level design<================> Developing test scripts and test cases
Coding <=================================>Buildi ng the test environment
Unit testing <=============================>System test data preparation
Supporting testing activities <==============> Test execution
Obviously, there should be a coordination between those development and testing groups to identify the gaps.
Thank you LynneM for your point. You are absolutely right - there can be some/many activites that do not coordinate.
Basically, my point here is, that QA is basically to prevent the defects rather than detect them. So If Development and QA can perform the activites together that can be coordinated, there can be a good chance of preventing the problems.
There are certain activities that are coordinated when you start improving your process for defect prevention.
From your list these are the items that I would have QA involved in:
Analyzing business requirements
I would actually call this reviewing - but in the ideal situations I would have all team members do this and have defects against requirements that did not fit the criteria they were being reviewed/analyzed for. This give a great archive for review and metrics when defects further down the line could have been prevented. Defects should be able to be identified by any person reviewing the requirements
Conceptual and High Level design
This may be done by development or a deign group but the design at this level for the most part should be understandable to many project members including QA and this should also be reviewed, once again I would have deign defects opened at this level and tracked etc.
Low Level Design
As this is more technical attempt for peer reviews from technical areas, as Performance/load testers tend to be more technical I would have them review. Once again track defects against this.
Peer Reviews can be done – for the most part if Unit testing is going to be done then I think reviewing for standards and good coding practices is sufficient but if anything else is caught it would be fixed. This is a total development task in my book and no direct QA involvement unless your process require a sign-off on the peer reviews when QA would expect to verify the sign-offs.
For Unit Test
This is a developers verification of code and peer reviews of results could also be don here – once again I see this as a developer activity only.
Done by the testers and supported by develops, include defect management. If you have successfully put in place a process for the reduction of defects then the support and retest time should be reduced.
I have not shown activities coordinating as you did because while the testers may develop Test Scripts and cases while the developers are doing low level design – they may not and it only matters that these are ready for the test execution.
I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison