December 20, 2013 Testing Time and QA Budgets Many software companies often see QA testing as an unnecessary expense – or perhaps not unnecessary, just a good amount less necessary than other areas...Many software companies often see QA testing as an unnecessary expense – or perhaps not unnecessary, just a good amount less necessary than other areas of the budget. Because of this, when the budget ultimately falls short for an intensive development project, the first area that many will try to cut costs in is QA testing. As testers, we’re used to this, and we’re also used to telling those folks why this is a terrible idea that’s going to handicap their project badly and possibly indefinitely. Here’s the thing: quality costs money, and quality assurance is the only way to know for certain that the system you’ve already put a huge investment into gives you the best possible monetary return. Wonder why your apps don’t rate so well in the app stores? Or why your e-commerce site isn’t getting the sales you thought it would? There are plenty of possible problems, but if your feedback says that your system keeps crashing or glitching on clients, the problem is with your QA. QA should be something that you’re considering from the very beginning of the development process; if you only begin your QA at the end, that’s bad. Quality assurance should be on the developers’ minds from the very beginning of the testing process. This doesn’t mean that you need to be throwing money at QA from the very beginning, but it does mean that the development team should be using the principles of testability from the get-go. This is truly the best way to trim down your testing time: having a system which undergoes proper quality assurance multiple times during its lifetime, and which is created by engineers who are familiar with the testing process and can keep that process in mind during the development life cycle. It also shouldn’t be a task handed off to junior engineers to keep them busy – testing requires a different skill set that most junior-level software employees are just not experienced enough to possess. The best way to trim down your test time is to ensure that everyone has proper communication, both within the test team itself and with other necessary departments. Trimming Down your Testing Time: If you’d still like to save some time and money on software testing, here are some good starting points: Does your testing team have clear goals from the development team, and open communication through which they can discuss these goals? Are regular meetings between testers and developers scheduled, so that even if open communication is not an option, the two teams can still check in with one another once in a while? Do the testers have regular meetings with their test leaders, so that anyone can discuss their concerns with the project? Does everyone know their deadlines, and can they speak to management about time concerns immediately? Is everyone submitting proper test result documentation, particularly in regards to bug reports? Have you put enough thought into traceability, the process that documents which requirements have been satisfied? Similarly, are your bug tracking procedures clearly communicated? You should notice that these questions have a common theme. Can you guess what it is? That’s right: the best way to trim down your test time is to ensure that everyone has proper communication, both within the test team itself and with other necessary departments (and with the development team in particular). The benefits of this should be obvious, from being certain that everyone is on the same page about crucial information like deadlines and goals to making sure that concerns are addressed to the proper people as soon as possible. These are just good test management practices, sure- but they’re also the best way to make sure that your QA testing effort is as seamless as physically possible, which will also ensure a lower price point for the process as a whole.