You’ve got the contract. You’ve created your project plan. And you’ve nailed down the requirements in so much detail, scope creep doesn’t have a chance. Your design team gets to work. They create detailed design documents and present them to the customer. The customer asks for a few small revisions but is happy with the design. The design phase finishes on time.
Development begins. You fight through a few of the typical snags that happen in this phase – technical issues, resource issues, and the like. But, development is finished on schedule.
Now, it’s time for testing. Your test lead has created her spreadsheet of test cases. The testers are ready to go. And here’s where things go horribly wrong. She completely stops testing because there’s a severe bug making it impossible to test any test cases. Your development and design team are in a different country and it’s a full day before they see her bug. You’ve just lost a day of testing.
It turns out the bug wasn’t the bug at all. It was just a misunderstanding. Once explained to the test lead, she is able to start testing again. Things go a bit smoother. Then she gets to a set of test cases and fails ten in a row. She needs to speak with the designer but he’s at a 2-day long kickoff meeting for another project. Another day of testing lost.
This rocky path continues and you manage to just barely stay on schedule – but only with a lot of extra hours and stress. The day before you’re supposed to deliver a working tested system, you don’t sleep, you beg for extra resources to help, and you barely get it done in time.
How did your smooth plan go so terribly wrong? You need to bring the QA team in early in the project. They need to be part of the design process and design meetings. So often, QA becomes an afterthought. “All they have to do is run through a bunch of different scenarios,” you think. But systems can be very complex. To set your QA team up for success, it’s essential they understand all the intricacies of the design, all the business rules, all the exceptions – not just the surface layer.
There’s something else that’s equally important. As soon as the design phase is over, before you lose your designer to another project, you need to have the designer be part of test case creation. The QA lead should not be creating test cases in a bubble. The designer can best explain the why behind design decisions.
Then, once the QA lead has created the test cases, the designer needs to review them in detail and help with any necessary corrections. He needs to fully explain the underlying business rules that lead to design decisions. This will save time during testing and allow testers to realize reasons for failures themselves, assign the bug to the right team member, and even offer a potential solution.
Make your testing phase in the software life cycle go as smoothly as your design and development phases. Give it love and attention and you’ll always deliver a working system on-time and with less stress.