0

This question already has an answer here:

Just like many teams we used to have a manual QA member. After a while he transferred to developer's position. We don't have any automated functional or unit testing. What we do have is so-called bug-session. The whole point is to bring the entire team together for manual testing. It does help to share the knowledge about the expected behavior but I don't feel it's enough because people don't take it seriously.

To improve the situation I suggested the boss contracting an outsource person part-time to minimize the expenses. The new person can simply take care of the issues pending for QA.

Manager says he doesn't see the value in bringing new QA because any of engineers can do manual testing. He asks me to prove we need a new person on board. How do I do this? What are the business advantages for having QA member in the team?

marked as duplicate by gnat, IDrinkandIKnowThings, Chris E, Reinstate Monica, Jim G. Mar 15 '15 at 21:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence. – Cronax Mar 10 '15 at 10:58
  • Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss. – Thorbjørn Ravn Andersen Oct 21 '16 at 15:51
1

Dedicated QA

Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.

Making this time a person

Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.

For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.

Making the most of QA time

So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)

As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)

Summary

A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...

But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.

  • Thank you, calculation may work. And, automation is another hard sale! – etual Mar 5 '15 at 20:06
  • @etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers) – RualStorge Mar 5 '15 at 21:15
  • Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle. – Brandin Mar 6 '15 at 13:21

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