Skip to main content

Quality BA, Quality Outcomes

A QA manager once asked me “What does the BABOK® say about QA?”. My response was uninformed and correct at the same time. I was so excited to be asked I was practically jumping up and down as I said “The best way to get quality outcomes is to work with the BABOK! We should talk more.”

I went to my electronic copy of the BABOK and searched for “QA”. I got one hit in the “Practitioners Reviewer” section:

“Richard L. Neighbarger, CSQA, CSQE.” 

It made sense that a software quality expert contributed to the BABOK, but where was the QA content?

I figured out I should search for “quality assurance” just like all my readers did when they read the prior paragraph, only slower than they did, as usual. I found many hits for quality, but only six for “quality assurance”. Here is the most relevant of six hits that I found (try it – it is fun), and the one I shared, still excited, with the QA manager:

“A business analyst is any person who performs…the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.”

“You’re a BA too!” I shared, in my usual reserved manner 🙂 “If you helped the BAs develop better business cases and requirements management and business use cases and iterative improvement you would know what to test and when!”.

To my surprise, the QA manager was not excited. “That’s not it”, she said. “Quality testing starts at the beginning, not at the end”. “Exactly”, I said. No product or software can receive quality by inspection – the quality is already there, or it isn’t. Every stage of the process needs quality. If we work together from the earliest vision requirements, through a quality business case, and thorough elicitation, analysis and validation, we are bound to get higher quality software outcomes” I waited for her agreement, but it never came.

“The BAs need to produce better requirements, ones that I can test.” I’m not going to do their job for them, but I will QA the job they do”, she finished, frustrated. “How do you know they are doing a bad job?” I asked. “We get all the complaints”, she replied. “The systems never do everything they are supposed to do.” 

Inside, I am grinning, trying not to laugh from the ambiguity of contradictory statements. “How do you know what the systems are supposed to do?” She stopped to think, and finally said “I don’t have time for this”, and we never spoke again.

How do we know that our solution requirements [analyzed from business and stakeholder requirements] will be relevant? We can make them testable (and we do) and still we are missing requirements. There are at least two answers:

  1. Nobody complains about a system that they aren’t using. Complaints are a sign of some success. Keep doing your job, and seek continuous improvement where possible, and sleep in peace.
  2. Turning a “Vision” into a high quality business case, one that informs further requirements drill down.

Next month: How to turn a Vision into a high (higher) quality business case.

Until we meet, have fun!

Don`t forget to leave your comments below.

Comments (2)