But What Does a QA, Tester Guy Know About...

... Product?
... BA work?
... Development?

My, what an interesting few days. I was asked those questions Thursday afternoon and Friday morning. It was an interesting set of discussions. My answer was similar for each of them.

Starting with the easier one to explain first.

Development

There's a secret that people with a specific agenda don't want others to know, I think.

The better someone doing testing or general quality work understands what developers do, the language they work in and the database that holds the data, the better questions they can ask around the software and the better testing they can do.

It seems obvious to me, but I think it isn't so obvious. Let me see if I can explain what I mean.

If a tester has a basic understanding of, say, SQL, and can read and write basic queries, then she can build more targeted test structures and more vigorously explore the application's behavior.

If a tester can at least read through and understand what is happening in the code, she can use her "tester mindset" and check her understanding against the requirements - either in a traditional "Requirements Document" or in notes on the User Story/Story Card.

She can look for discrepancies between her understanding of the requirements, specifications, whatever, and what she sees in the code. This can lead to conversation with the people writing the code and the BA and Product Owner/Product Manager to clarify and make sure everyone has a shared vision of the project.

This is similar to how a good tester can understand what a BA does.

Business Analysis

Testers look at the requirements produced by Business Analysts. Ideally, they participate in discussions where the requirements are discovered and defined. For many organizations this is not the case. (I suspect it goes a long way toward explaining the disbelief around a tester/Qa person understanding what a BA does.)

I remember past projects and companies and clients and places where things did not work well.  Each time I asked about reviewing the requirements or specifications or user stories, then discussing them with the people who created them, I was often looked at with confusion. Like, "Why would you want to do that? Everything is written down here." This was often followed by "No testers have gone back to this stuff before. Why do you want to?"

I learned to control myself.  My automatic reaction typically was to smile to myself and think "And that explains the state of testing for these projects." 

What I actually said was "It is good to know what the documented requirements are.  It is also good to know what existing tests have been set up or run already.  It is essential to know what problem the project is intended to address.  It is crucial to know what people are doing now and what they need the software to do for them."

When looking at how to test something, or how to approach a piece of software, I've learned that the most effective way for me was to gain just that level of understanding. If I can understand the problem the BA was describing better, I can do a better job of testing to make sure the customer needs, problems and desires are being addressed.

I sometimes get told that a BA will explain everything in the documentation and I should simply leave them alone. Except, everyone translates information that fits their view. Everyone filters out unimportant bits - which sometimes is really important.

For that reason, I find conversation is the most powerful tool a tester has to build good, meaningful tests. They need to go beyond the handful of words written down and make sure they have the same perspective the BA was trying to represent.

Product

The purpose of every software organization is to deliver a viable, working product to customers. Every development model, quality program, testing model, and approach, waterfall, Agile, SCRUM, Kanban, or XP aims to deliver the best product possible. 

These goals often fail, in my experience, with what I think of as the Edsel.

Anyone drive an Edsel lately? Wait. What? You haven't? I bet your neighbors have one though, right? Well, maybe not.

The Edsel was an amazing piece of engineering, design and marketing. It had absolutely bleeding edge features for the time it was designed and produced. The goal was a "perfect product." 

It failed miserably.

When working with software projects, I have a really fundamental opposition to trying to advance by "hitting home-runs." Most baseball players strike out, most of the time. 

Incremental improvement, based on firm understanding of the needs and problems we are trying to address seem a more solid solution to developing ideas into software.

If we don't understand the needs and problems our customers have can we really make a product people want to use, let alone pay for?

I get the idea of "revolutionary." I get the value of being the "first to market." I also get that ideas are never perfect, and building on good ideas can lead to better ones. Take a minute and gather some data, then load it into VisiCalc  and see the odds of the breakthrough leading to corporate success.

Good ideas grow on each other. If you set a fixed direction and channel every available resource into that, will you be able to respond to changes in the market, or world? Will you be able to respond to problems found in creating the breakthrough?

I find it helps to have a general idea with a broad, fuzzy view of what the final product will look like. The work to build that view needs to be sharper and more clear as it is being worked on. The tasks for next week need to be well understood. At least, they need to be understood enough to make progress toward the final end goal.

What Does a Tester Know?

As a "quality guy" I have seen enough examples of well meaning, well intended direction carved in stone that results in chaos, if not disaster. The key to success, as I see it, is to remember that ideas are transitory. They shape and shift and change over time.

By keeping the conversation around the purpose of the product alive, and keeping every person involved "in the loop" as equals and as contributors to success, amazing things are possible.

The higher and more formidable the barriers the less likely conversation and communication will happen.