The role of a software quality assurance professional is kind of an interesting thing. It is hard for a lot of people, even those we work with, to really understand the position. It can even be hard for us. I often used to find myself defining the job by saying what we aren’t.
We aren’t usually software engineers, but most of us can (and should) do some basic programming and understand simple algorithms.
We aren’t on the business side of things, even though our role very much affects the bottom line, both in terms of cost and revenue generation.
We aren’t the product owner or primary stakeholder, but our decisions affect the direction our products take.
Sometimes it seems from the outside that we don’t really do anything, but we are responsible for everything.
Before I go any further I want to give you a couple of definitions so my point doesn’t get lost in semantics (as so often happens on the internet). You don’t have to agree with these definition, but it will hopefully give you some context for where I am coming from:
An advocate is one who supports or promotes the interest of a cause or group.
A customer, as I am going to define it for the purposes of these articles, is someone who gets value from the products we design and build.
Everyone in the company/organization should have a focus. The focus for the business side of the company is usually to generate ideas which bring in value and revenue for the company. The software development side is focused on turning those ideas into a “product”. An app, an api, a service, whatever. The quality team’s focus should always be on the value this product brings to the customer’s life.
We get pressure from the business to roll out this new feature in order to meet a deadline, the devs are anxious for their code to be in production, sales really wants to sell it. In a fast-paced agile environment it’s really easy to fall into the routine of just being “AC-Checkbot”. Verifying the acceptance criteria is absolutely an important function of the job, but it should really just be the starting point. Hopefully your devs made sure that the ACs were met, at least in their own local environment. Proper QA is expensive, both in terms of time and resources and your organization might not always willing to fully invest in it unless you prove the value of being a customer advocate.
“I’m sold!” you might be saying now. “How do I become that advocate?” Well, read on and I will give you a few things you can start on right away.
First up, get involved as early as possible in the process. QA typically comes near the end of the SDLC. Ask to be invited to some of the earlier meetings. If you can get in before development has even begun that is the best time to start asking questions on behalf of the customer. While the devs/architect will be asking the how questions on the implementation of it, you should consider asking some of the why questions. Understanding these will really help when it comes to the actual testing. “Why are we changing this?” “Will it save time?” “Will it save money?” “Does this actually help the customer or is it just something we are doing because company X is doing it?” Some of these questions from the customer’s POV might be uncomfortable to ask, but you need to do it anyway. You can’t advocate by being silent. This doesn’t mean you should be rude – remember that literally everyone at the company is ultimately YOUR customer.
Next up, I’d recommend coming up with customer personas if your company doesn’t use them. If they do, then always strive to keep them in mind when doing your testing. There are some great resources out there on creating the persona, and I would recommend you do some research. To get you started if you have never seen these, I would recommend the following as a bare minimum.
They should have a name. It can be helpful if you think about. There should be an idea of how often they use your product. You should have an idea of their level of technical expertise. You should know what their desire in using your product is. It shouldn’t take too long to create this basic skeleton. I’ll drop a couple of hypothetical examples for a customer for a blog creator and if there is interest I can go more into this in a future article.
Customer persona: Jo is a twenty-four year old college dropout who wants to start blogging. She’s used computers her whole life but isn’t a programmer nor does she want to. She wants to make money selling her cat hat crochet.
Customer persona: DeShawn has been a php developer for the last three years. He wants to build up an online community of competitive dart players.
Understanding these basic customers you can identify what is important to them from the app. When you are in those early product meetings and there is talk about maybe rolling out a new shopping cart option you can start thinking about what would be important to Jo and ask questions on her behalf. “How many steps is it going to take to set up the cart?” “How are we going to make sure the payments are secure?” “Are we going to collect shipping information?” “Why are we changing this?”
All businesses exist to provide value the the customer. Often product implementation decisions are made solely for ease of development, and not for the customer. You need to stand up for the customer in these cases. Sometimes the value of dev ease will be take priority and know when to acquiesce, but do so knowing that at least the question was asked and a decision was made. So many times things happen because of inertia more than intention.
I’ve gone on longer than I expected to for this article but I really think this is the most important part of the job. As software quality professionals we need to think of ourselves as a customer first and the first customer.
Next up I will be writing about the importance of being organized (which is something I have been terrible about personally).
(all images in this article are free use from clipartmax.com)
Random Thoughts 