What to Do if You’re Told That Your Project Doesn’t Need to Plan for QA

The QA process is a vital leg of any IT project’s journey. A well-planned QA process can smooth over rough patches during development and bring a troubled project in for a graceful landing. However, for some projects, a formal QA process may not always be possible. Here’s how to make sure your project’s expedition survives when your stakeholders inform you there won’t be time, money, or bandwidth for QA.

A Project Owner who skimps on QA is very likely to have skimped on requirements development. When you know going into a project that there will be no QA phase, your survival depends on starting off on solid footing. Meet with the Project Owner, dissect the requirements in detail, and make sure you all leave that meeting in agreement on what is going to be delivered and how you plan on delivering it.

This is also the perfect time to nail down a commitment from the Project Owner to look at and experiment with the application’s development builds. If they won’t want to pay for or give time to the QA process, then the client team has to step up and help shoulder some of that burden.

Unleashing code into the wild without some quality assurance is like releasing a pack of rabid wolves in Central Park: someone Is going to get bit and it’s not going to be pleasant. If there isn’t any QA certification at the end of the project, it’s critical that the development team incorporate some portion of that certification into the development process.

A solid unit test plan will keep your project team from wandering helplessly through a thicket of recurring bugs. When a defect gets fixed, write a unit test case that checks all new builds for that defect. These unit test cases must become part of your automated test process. A reliable, regularly executed automation test suite will make sure the same old bugs do not keep creeping back into your codebase.

It’s a good idea to include this process in every project, even ones with ample QA budgets, to help your team avoid the repetitive and demoralizing task of squashing the same bugs over and over again.

When testing is shortened or eliminated from a project’s schedule, it is vital to keep the Product Owner engaged throughout the development process. The more you can show them your progress and get them working and comfortable with the application, the less likely your development process is to run aground on some unforeseen problem.

Each piece of application functionality should be put into the Product Owner’s hands as soon as it is stable. When you would typically ship a build to the QA team for testing, send it to the Product Owner, instead. You want the client’s hands on the product early and often. The more small issues they find in their use of the application, the less likely one of those tiny defects will snowball into an avalanche that buries your whole team in a backlog of defects.

Showing the Product Owner rough-and-ready builds of the application will also let them see why QA is so essential, and how much value it adds to the project, so they will be less likely to skimp on it in the future.

Development teams used to working in concert with a QA group may not be used to triple-checking their application for errors. Following the above steps can help you and your team avoid the worst problems that can arise without a formal QA team or process, but you’ll need to keep a constant watch to avoid suffering a bug ambush.

Spending some time with your team on a consistent basis to analyze and report defect trends, recurring issues, and trying to predict future problems will go a long way toward seeing your project’s journey to a successful end.