Testing: Part 2 of How To Commission a Software Project
This testing article is part of the “How to Commission a Software Project” series.
Formal testing must be part of your software development process. There are a few non-negotiables and a few recommended best practices listed here related to how to formalize and execute a quality assurance program.
- Independence of test – developers write code to accomplish a specific task as they understand it. When a developer tests his own code, he cannot shake all of the bugs loose. Find someone else (preferably a software quality specialist) to operate the test plan. Having a different human being test the product is critical. Seriously – don’t forget it.
- Written test plan – codify the full body of tests in a document or within a management tool. This reduces the natural tendency to convince yourself something passed a test when it did not. It also elevates the importance of testing something seemingly unimportant. If something seems unimportant, why does it live in your application? Remember when you documented your requirements? Good requirements serve as your best source for test planning. While you run your test plan, document passing and failing tests and report issues meticulously. We use a Fivable-built tool called Passable™ which traces the life-cycle and resulting records of every execution of a test case.
- Unit tests – this is as much a development topic as a testing topic, but unit tests must be part of your codebase and they must be run. I’m part of the camp that believes it’s ok for some pieces of the codebase to lack unit tests (if and only if they’ll be exposed to manual or automated integration or end-to-end testing. But if it’s critical, please unit test. And if you don’t know how unit tests work, start researching.
- Track bugs (until fixes are verified) – this looks something like: test engineer reports a bug in a traceable system, developer sees bug report, developer investigates and fixes the bug, developer reports fix, test engineer sees a fix notification and either verifies the fix or tells the developer “sorry pal, try again.” Repeat. Don’t let bugs fall through the cracks.
- Give testers reasonable access to developers. Let them talk about whether something is a bug or a misunderstanding. This will give your testers extra context about the software in general and will keep invalid bug reports to a minimum. This will also give the devs the opportunity to say, “Yeah, that’s a bug. Include detail X and it’ll be a quick fix when I get to it.” A measured amount of that is awesome stuff.
- Give testers and product owners the final say on whether something is or isn’t a bug and whether or not it should stop a software release. Remember that on a small team, they have the most empathy to the users of the system.
- Let testers play with the system early. This creeps into the waterfall/ XP/Agile conversation a little bit, but no matter what, letting the QAS play with even broken code is better than them sitting on their hands. Plus, they’ll be able to verbalize what’s broken about it.
Are you ready for testing? Remember, if you’re part of a lean team, this might be you. CEOs, COOs, and developers make great testers as long as they didn’t write the code under test. As long as you start your formal QA process now, you should be ok.
Interested in getting help with testing?