Life, audits, and reporting back

As I wrote in my previous posting, the Projects in Quality Center at my client site are going to be audited, and I was asked to check the Projects ahead of the audit to see if there were any obvious errors that could be fixed before the audit was conducted.

There were.

I’ve checked one project so far, and I found literally over 1000 issues. I’ve been asked to draw up a checklist for the Business Analysts and Test Analysts so that they can check their work against it and avoid repeating the same mistakes.

You may be wondering why there were so many errors. The main reason was copy/paste.

A lot of the Test Cases were very similar. To save time, the Test Analysts writing the Test Cases would copy from an already written Test Case, and paste to a Test Case they were writing. All fine and well if the stuff being copied is error-free, but in this case there were spelling and grammatical errors. I kept finding the exact same misspellings of the exact same words in the exact same places in Test Case after Test Case. Two misspellings of “cancellation”, “formated” instead of “formatted”, “a messages”, amongst others. A worse problem came with the message Test Cases.

Part of the Project I checked was messaging. There were six different messages. The codes were RJ4000 to RJ4005. The messages differed in minor ways and the Test Steps for each message were often identical. So the Test Analysts went bonkers with copy/paste. Just one thing: they forgot to change the codes in the Test Steps. So the Test Cases for RJ4001 to RJ4005 kept referring to RJ4000. Not good.The most serious problem came up in the last few Test Cases. One of the guidelines is that a Test Case must include a Summary or Test Objective (what the Test Case is testing), any preconditions (what is needed before the Test Case can be executed) and all postconditions (what should happen if the preconditions are met and the code being run fulfils the requirements under test). When I compared the Test Objective to the postconditions, I found that in some of the last Test Cases the two actually contradicted each other.So here’s a preliminary checklist I’m going to present.

  • Check spelling and grammar. If you need to, get someone whose first language is English to go over it (clarity).
  • Link each Test Case to the exact Requirements it is testing (traceability).
  • Every Requirement that is testable and in scope must be tested. You are not finished Test Case Design until every such Requirement has a Test Case that tests it (completeness).
  • Every Test Step in a Test Case must have an expected outcome (completeness).
  • When executing a Test Case, include evidence that you have run it.

I’m going to call a meeting and present my findings to everyone. I must just keep one principle in mind when I do.

“You are testing the product, not the person”.


About autismjungle

I am a Software Test Analyst. Shortly before I turned 21 I was officially diagnosed, although I had long suspected I was autistic. Welcome to my blog
This entry was posted in Life, Work. Bookmark the permalink.