One of the best “bang for the buck” QA team structures that I’ve seen has been to have a QA Engineering team or at least a QA Engineer available. Bringing in a QA Engineering Team into an existing company with development can sometimes prove to be a difficult task. Difficult for development and difficult for management to justify. Depending on the technical maturity of the development staff they may or may not like another person coming in to evaluate their code. A developer’s code can sometimes be a very personal thing. You are basically looking under the covers and may just see their dirty linens. Some more mature developers actually appreciate a QA Engineer looking at their code as a second pair of eyes. If your company doesn’t have peer code reviews then a QA Engineer is a good option. I can’t say how many times in my professional career a good code review hasn’t proved to be worth its weight in gold. I’ve worked at one of the top software company’s in the world and have found some amazing things under those covers.
Once during a code review I found a snippet of code left for a demo version of the product. If the product had shipped with this snippet of code still in place it would have meant that everybody’s purchased product would have turned into a demo version only thirty days later. Not a good thing to happen to any company. After I pointed this out the developer was actually quite appreciative, as was I since I knew what would have happened had the product shipped.
QA engineers can also help with designing test methodologies beyond just standard white-box test practices. A good engineer can also help to implement automation testing or may be able to help with performance testing. Correctly employed automation can truly help reduce the amount of time for each test cycle by employing scripting that is repetitive and consistent. It’s nice to run a good automation suite of scripts against a product each time that you have a new build. This can often be done automatically to occur immediately after a build has completed. Hence you can often catch a bad build, or bad code quickly – a great practice to use during the middle of the night so that Dev can come in in the morning and rectify or even better have a script failure trigger alerting to the build team so that they can potentially resolve immediately.
This is just one example of how a good QA Engineer can help a development team. There are countless other examples and I’m sure some that you would find in your company if and when you have QA Engineers doing code reviews (white box testing). Next time your management complains about budget, offer them this example and perhaps they’ll support you when you go to bat asking for a QA Engineer or Engineering Team.