Too often I’ve seen QA teams flounder or fail because they lack the discipline to follow best practices. If you want to have any hope of success in assuring the quality of your project, you need to start with these 10 best practices first.

  1. Test Everything: Have you ever had the misfortune to be called into work the weekend of a release because of a critical bug that was missed? Depending on your organization, it might take two minutes, two days, or two weeks, but invariably you will be asked the question, why didn’t you find that bug? Well, why didn’t you? On the east wall of my cube there hangs a handsomely framed sign that assures everyone who walks by will know my mantra: “If you haven’t tested everything, you haven’t tested anything!!!!” Too many times we fail to test every part of the application and get burned by a missed bug.

  2. Mind the Gate: Who is in charge of quality in your organization? Are the developers? The business analysts? Management? Do you think those people are going to test quality into your product? Of course not, they don’t even have the name “quality” in their title. Only the Quality Assurance (or Quality Control) team should have the authority to decide if the software is ready for release. If for some reason you don’t have a team with the word “quality” in the title, it’s time for a title change. The “Testing Team” for example can be modified to be called the “Quality Testing Team”. Words matter.

  3. Maintain Your Test Cases: I talk to a few testers now and then who tell me they don’t write test cases. At first I have to ask if we’re using the same terminology. Some call them test scripts or test plans. That usually clears up the confusion, but there are a few who go on to say that they actually understand what I’m talking about and no, they don’t write test scripts. Instead, they will ramble on about this “ET” or “Exploratory Testing” fad that seems to be getting popular these days. I like to tell them “ET was great in that movie, but he shouldn’t be doing your testing”.  It’s not as if Exploratory Testing is completely worthless though. It can be helpful as an ad hoc exercise after you’ve executed your formal test cases, but that shouldn’t take time away from your number one priority: Maintaining and executing your manual test cases, making them detailed enough so that anyone can execute them. What if you hire an offshore team to do your testing, or an intern, or some guy preaching Doomsday on the street? If that person can’t execute the test just as well as you can, then you simply haven’t done your job.

  4. Automate Everything: If you’re good with best practice number 3, then you’re ready to start automating all of those manual test cases you’ve been maintaining.  Start small, don’t spend more than 75% of your team’s available time in converting test cases. Eventually though, you’ll want to get to the point where only 5% or so of your team’s time is spent in manual testing. The other 95% should be spent maintaining your suite of automated tests and writing new ones. Actually executing the automated tests is optional, but don’t get so bogged down in running tests that you don’t have time to maintain them.

  5. Don’t be bullied by your situation: I’ve seen too many testers make the mistake of being unprepared for the situation they’re getting into with a new product.  Determine your testing strategy first, before your brain gets overwhelmed by all the variables of your context and then adapt it to your situation. This applies to testing tools as well. For example, if you’re a Selenium expert, figure out how to best use Selenium in every testing project you’re assigned to instead of wasting time looking at different tools for each project.

  6. Manage with metrics: It’s a proven fact that 92.6% of projects fail when testing isn’t driven by measurement. The right metrics can motivate not just the testing team, but the whole project. Whenever I’m managing a testing project, I always set up a reward system for finding the most bugs early. Be sure not to reward bug counts late in the project though, because finding a showstopper close to your deadline can lead to major rework.

  7. Make sure your test team has the right programming skills: Applications are built by programmers, so why would you want anyone but programmers to test them?  Only someone who has been a programmer can understand the mind of a programmer and be able to find their mistakes.

  8. Keep QA and Development separated: Programmers and testers are two different roles, and they think differently. Applications are used by users, so why would anyone want a programmer to test them? Keeping testers and programmers separate will ensure that your QA team keeps a distant view of what’s going on in the program so they can test more like a user.
  9. Be Agile: When you’re striving for Agileness, always be Agiling to Agile a little more Agilier, because Agiling is the key to becoming Agile. If you’re not Agiling to be Agile already, then be more Agile in your approach to Agiling. Remember, Agile is not just a word, it is the only word, except for Agiling, that’s a word too.

  10. Go back over the first 9: ... and do pretty much the opposite of what each one says. In subsequent posts, I’ll go over each of these in more depth and talk about why I think each one is bad for the Software Testing profession. That is if you believe anything I have to say now after reading this post!