-1

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!

Improve this question
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.

  1. 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.

Improve this answer
1

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.

Improve this answer
3
  • By QA time, is understood here as "time spent by dedicated QA resources" (ie people or "man days"). Generally accepted as best practice when contracting on a web or app development for a third party to explicitly list the supported browser and devises and their versions. These are expected by the client to be bug free. Of course the more of these, the more QA time in man-days is needed. – Alex Jean Jan 10 '18 at 10:38
  • Can you elaborate on how you have "seen as a whole" budgeting? And when "quot[ing] an overall development time", how you allocate resources while making fixed price projects profitable? – Alex Jean Jan 10 '18 at 10:38
  • My preference is to quote for the entire delivery team on a total number of days. e.g. This delivery will require 50 days effort (which includes development and QA effort). The danger with breaking out the QA time is that can result in problematic conversations, such as: "Why have you allocated 20 days for QA? Can't we get away with 15 days?". Making fixed price projects profitable is a whole different question. It typically comes down to putting in lots of contingency based on perceived risk (i.e. we have never done this kind of dev work before, so we will add extra contingency). – Barnaby Golden Jan 10 '18 at 11:47
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.