QA time budgetting

Question

I am currently preparing a proposal to a client for a large web application development. My environment is outsourced software development. I need to budget QA time for the project.

Usually, from practice, I used a mix of the following:

• Base case scenario: QA estimated at 15% of the development team time. With some percentage point changes based on the mix of juniors and seniors as well as back-end to front-end tasks. Usually front-end and junior - make more QA needs. Whereas back-end and seniors - make less.
• Commercial considerations. There are more often than not, very down-to-earth considerations in terms of time utilization.

Questions:

• Is QA budgeted 15% of dev time an industry standard? I always had the impression it was. But recently someone challenged this in a discussion putting the number higher.
• Is there a smarter way? Some more sophisticated drivers than the ones I use. Any article to link on the matter?

Thanks!

Answer 1

AFAIK, there is no such thing as accepted industry standards for QA estimation. This is because it would vary based on the parameters such as complexity, understanding of functionality, technical landscape, scope, resources, team composition, etc.

If you are on manual testing, then you will need to consider the challenges on a different track. If you are on automation testing, by applying continuous integration (CI), the game plan changes.

If you just go blindly by 15% of your development effort, you might need to change your strategy. It might not help you provide a shippable product.

To answer your question: 1. There is no accepted industry standard, but people do leaf out a certain percentage of distribution for the phases based upon the total budget. You could very well go by the standards accepted by your organization.

2. The smarter way: Is to understand the scope, challenge, critical success factors of the application and embrace continuous integration (CI). This will help you to identify various streams of cases / scenarios and automate thereby helping you reduce the manual effort - earlier we would call it as reusable test cases.

2a. You could very well bank upon this Book as it would help you explore on how to improve your QA efficiently. Continuous Delivery, Continuous Integration

Hope this helps you.

Answer 2

What do you regard as QA time? If a bug is found and a developer needs to fix it, do you count the fix time as QA time? What about re-testing to confirm the bug is fixed?

How about if it is unclear whether it is a real bug or a misunderstanding of the requirements? Perhaps a business person is required to clarify the requirement, is that also QA time?

Then there is the question of what do you regard as an acceptable level of quality. If you don't mind shipping bugs then that impacts on QA time. How about if you test on one browser, but don't test on other browsers? Won't that impact on the QA time?

What about unit tests? How about Continuous Integration? Are they QA time?

The point is that there is not a clear distinction between what is development and what is QA. The development process should be seen as a whole, not as a series of individually estimated elements.

I would suggest the best approach is to quote an overall development time that incorporates the time required to ensure quality is maintained to an agreed standard.

Answer 3

I always found the historical information the most valuable when I estimate QA and support costs.

Depending on the project, if you are re-using a lot of code, you'll probably need less time for QA. On the other hand, if you are building the application from scratch, you'll probably need more.

Since you are building a large application, you could break down scope of the work to modules similar to ones you did in the past and go from there.