The Red Team Rules for Software QA

I found the Original 12 Red Team Rules recently (there’s profanity in the list), and a lot of them are relevant to life as a software quality advocate/analyst/engineer/assurance person with a bit of modification.

Rule 1: Know when the test will be over.
(Was: Always have an escape plan).

Rule 2: Be aware of the environment for your app, database, network, mobile devices, etc.
(Was: Be aware of your surroundings.) Different environments require different testing strategies and tools.

Rule 3: Assume nothing.
(Was: Assumption is the mother of all f***ups.) Get your acceptance criteria spelled out, and if there’s not code in place to stop you trying something, do it.

Rule 4: Vary your attack.
(Was: Always have a backup plan.) If you don’t find a bug the first time out, try something different. Someone that always tests the same way won’t find new kinds of defects.

Rule 5: Never get caught by surprise.
(Was: Never get caught.) Know your application, who will be using it, how they will use it, and its vulnerabilities.

Rule 6: Collaborate effectively.
(Was: Keep your mouth shut.) Quality is a collaborative process, but talk with respect, and don’t log a half-baked bug report that can’t be replicated.

Rule 7: KISS: Keep it simple, stupid.
This applies equally to QA and the Red Team. Write stories, acceptance criteria, bug reports, and regression test plans that a total stranger could follow. Because in six months time, that total stranger could be you.

Rule 8: Simple and light equals freedom, agility and mobility.
Don’t get bogged down in a document-heavy test process. Test Driven Development will help if you can read code (and QA people should be reading the code).

Rule 9: Do the job and then go home.
(Was: Plan, execute, and vanish.) Tired and cranky people do poor work.

Rule 10: Automate the boring bits.
(Was: You don’t have to like it – you just have to do it.) Sometimes we have to do repetitive stuff. Automate it if you can so you don’t have to do it again, but don’t duplicate automated tests.

Rule 11: Always invest in good quality stuff.
Get the right tool for the job and learn to use it well. JMeter is unfriendly but provides excellent information.

Rule 12: Trust your gut.
If you have a hunch there’s a bug in an area of the application, keep digging until you find it.