For the thousandth time today, I wish that I had run away with the circus and become “Madame Zenobia, Fortune Teller of the Great Sahara and Far East.” That way at least after I’d made a vague guess about the nature of my client and what might happen to them in the future, I would be long gone with the rest of the circus before the angry client came looking for me.
I am, after all, pretty easy to find parked at the same desk day after day.
So what do I do for a career instead of reading tarot cards and selling love charms? I am (insert crack of lightning, rumble of thunder, and the swelling of minor key music that always the heralds the arrival of the bad guy) QA!
If you don’t know what that is, let me elaborate. ‘QA’ stands for ‘Quality Assurance,’ but I am also known as a tester, an analyst, or the name I hear most often from coworkers, ‘that jerk who keeps breaking my software!’ and from clients, ‘that jerk who didn’t catch that bug!’
Pleased to meet you.
So I know how I am described by others, but how would I describe myself?
Well, I am the person who tries to make sure that the software we send you works, is complete, and meets your needs. The first two functions go hand-in-hand and are no brainers. Does it blow up when I press this button? Did all the parts of the product make it into the release? Good!
The third function, verifying that the software meets the needs of the client is the toughie. How can I tell what you need? Well, sometimes we have Business Requirements that give us some direction. “Need a system to process claims and handle checks.”
Ok, good, that is a start, but how do you want to process claims? Who is doing it? What do they need to do? How can we make the system function to make their life easier?
Everyone has their own idea of easy. Structuring software sounds easy at the beginning of the process, “Need a system to process claims and handle checks,” well duh, how hard can that be!? But how people interpret the Business Requirements depends on who they are.
A software developer might interpret this as, “input payment x in field y and send to table z to get to report q.” If you have almost passed out from algebra-phobia, you are not alone. I see this type of interpretation, and I want to hide under my desk and eat cookies until I explode.
A tester might interpret that same set of requirements as ‘user should be able to enter and maintain a claim, enter, print, and document checks, and be able to reference the claims and checks systems.” Hey, sounds good to me!
What is missing here? If you are a client, then you probably are already yelling, “What about what I have to do?! Did you even think that I have to do this task and that task seven hundred times a day, and your stupid system doesn’t make it easy AT ALL for me? I have to go to this screen, then that screen, and remember to type in this code here, and boy, but you make my life purgatory!”
Well, we try to find out what you need. We try to get an idea of what clients and users need, what changes we can implement to make your work easy, but so far that hasn’t worked out as well as we’d hoped.
If we send out client representatives, they can only talk to so many clients at so many locations per year, and we try to distill that feedback down to a set of user-based requirements that help us understand you, but frankly, that doesn’t give us the big picture.
Why not? Well, I don’t know, not really, but I think it has something to do with the sheer number of people that are between the beginning and the end of the process.
Do you remember playing the ‘telephone game’ as a child, where the first kid whispers something to the second kid, and they whisper it to the third one, and so on around the circle, until the original comment has been completely distorted?
That is similar to what happens during the lengthy process of creating software, where the original set of expectations gets passed through so many hands, and so many of the folks working on the project are far removed from the original voice asking for and describing the project, that the clients often end up with a wishbone instead of a wishing well.
So how do we give you what you want, what you need, and what you would really like to work with?
The answer is simple. TELL US. Tell us what you need, what you want, what really steams you about our software, what you think is stupid, what would save you time, what would make your day a joy instead of a chore, and tell us what you do like about it and would like to see more of.
Trust me, we read what you write. We take it into account, and it matters to us. You might not see any change immediately, but take my word for it, any real-world usage scenario, any hints from a veteran, and any suggestions that would help you out are like gold to us.
If you don’t tell us what to change, we will never know to change it.
You may not be the type to just log onto a website and lodge a complaint because you feel like you are yelling into empty space, but I can tell you from personal experience that everybody in this office wants those messages in a bottle from you.
Why? Well, that is a simple question to answer. Nobody wants to work on a project for a year and find out later that the client thinks it is useless. Period. It’s like when you go out Christmas shopping for ‘that perfect toy’ for your child, going to every store in town, fighting the crowds, asking every salesperson to help you find the last one on the shelf, and then when the gift is finally opened, you hear, “I wanted the RED one, not the BLUE one! I hate it!”
And that is exactly what happens unless you tell us that we are doing something wrong.
Working in an information vacuum and being expected to come up with an accurate forecast of the future is pretty tough, even if you have a working crystal ball (mine’s in the shop).
So you get on that site and start talking to us, and I’ll stay at my desk and not change my name to Madame Zenobia.
For now.
Holly Priest CSTE, MLIS, has been a QA Analyst for seven years, loves to oil paint, and wants to build a robot out of popsicle sticks, vacuum cleaner motors, and twine.