Monday, January 12, 2009

QA Effert Estimation

I would say that it vary a lot depending on the way the code was done. Depending also on your definition of "done". At Microsoft, they done some testings on whether "done" should be "code complete" or a little more than that. They figured out that it pays a lot doing more testing up-front than later on. That being said... I think that something like 15% analysis, 10% architecture, 50% code, 15% QA and 10% project management / release management etc. would be pretty much accurent.

Some factors includes hardware environment which will influence the QA/Dev hour ratio are:

Maturity of the product,
Quality of the requirements,
Level of domain knowledge of the Dev/Business/ QA team members,
Development model followed (waterfall, agile, etc.),
Breakdown of roles and responsibilities between the teams (different companies have different expectations between Dev and QA) ,
Physical proximity of the Dev/Business/ QA teams (people are more efficient when they work together)
Level of quality needed (Banking and health care industries have much stricter quality requirements than an entertainment application)
Team Sizes (Smaller teams are more efficient than larger ones)
Effectiveness of Change Control Procedures
Scale of the project (Defects increase exponentially with the scale of the project, more defects means more QA time and therefore a higher ratio of QA hrs to dev hrs)
Quality of the Code (The single largest factor)
Quality of Documentation
Availability of test data (only applies to some projects)
Quality of the QA team (actually a much more minor factor than you'd think)

Here are a few rules for effective testing estimation:
Rule 1: Estimation shall be always based on the software requirements
Rule 2: Estimation shall be based on experience of the team
Rule 3: Estimation shall be based on previous projects
Rule 4: Estimation shall be recorded
Rule 5: Estimation shall be supported by tools
Rule 6: Estimation shall always be verified

Testing estimation vs Development time
- simple problems : same as 20-30% of time spent for development
- normal problems : 40-80%
- complex problems : 100-130% (test should start even before devt)
- very complex problems : devt should be done according to tests, and breakdown to smaller problems if possible with robust framework and QA guidelines.

No comments:

Post a Comment