Software Testing and Quality Assurance: No, my job isn’t to break things.

QA Testing

I have spent my entire career in the software development field in some capacity. While I always find myself returning to the Quality Assurance team, I have spent years working with the Tech Writers, the Support Desk, and the Implementation team (and am always amazed at how similar each of those roles are when it comes right down to it), but it’s only when I am primarily connected with QA that I find myself being asked repeatedly by friends and family, “So what is it that you do again?”

The answer to this question seems so much easier for our Developer or Programmer counterparts. They can say that they build software, write code, or implement technical design, and most people can understand that. Similarly for Business Analysts and Requirements Managers who can say that they convert needs or gaps in business solutions into a document that can be followed by a Development team. Tech Writers document software for users or other audiences. Support Engineers resolve user and customer issues and complaints and show how to use a piece of software or a system. But what about Quality Assurance professionals?

Usually I start with an innocuous answer like “I test software” and see what kind of response I get. A confused look or a cocked head earns a follow-up where I try to give an example of something my friend might be familiar with, such as a bank ATM or the guide screen on their TV and take it from there. At some point I usually hear, “Oh, I know. When I go on the Internet, I always see things that are broken – so you try to break things?”

And yes, I suppose to many people that’s how our job looks. In fact, for some of us that’s how we see our primary function. But I have never quite viewed it that way. For my first foray into QA, I was paired with a brilliant up-and-coming software developer who had emerged from college with near-perfect grades and technical confidence galore. I took very seriously my new responsibility of finding fault in everything he did. It was somewhat less than a match made in heaven. Initially. Then something happened to make us aligned in our misery: the database developer inadvertently wiped out the only existing instance of the database and we found ourselves all aligned with the mutual goal of getting everything back up and running in time for an executive demo. Suddenly we realized we were all on the same team and began acting like it. My role became doing everything I could to make the application as close to perfect as we could and, as a by-product, making my developer look as good as possible. My efforts were not lost on him and he began referring to me as his “best friend.” Once we had ourselves mentally re-aligned, the true value of my role became more apparent and more readily accepted. Rather than trying to break things, I was trying to make things better.

A few years later (and in a different company), I expanded my role as QA Manager to include management of the Application Support team. Having spent several years completely aligned with the Development team, I now found myself in the formal position of representing customers and end-users as I was working directly with them on a daily basis. While I always considered myself an end-user advocate as I worked with Business Analysts and Developers on design and implementation decisions, I finally had a first-hand view of their pains and struggles, not only with the functionality and usability of the products, but with their more intangible aspects, such as portability, maintainability, reliability, and security. Our customers and end-users appreciated my connection with the Development and Testing teams as I was able to expertly answer their questions, provide workarounds when needed, and give bidirectional input into upcoming features and fixes.

But the real value in expanding my role was that I had additional insight into the potential risk of releasing changes into the field. So now, in addition to trying to make things better, I was gauging the impact of releasing something in its current state. This perspective really allowed me to change my view on what I now see as the most important aspect of the QA job. While there is great reward to be found in aiding the Development team in building software that is as close as possible to perfection, and there is always satisfaction in representing the needs and pains of the end user and customer communities, synthesizing the business needs and technical implementation details into information that can be used to drive go-live decisions is ultimately the most valuable facet of our role.

As simply as I can clarify the role of a professional software tester, our main responsibilities are these:

  • Risk identification and communication to stakeholders
  • Advocate for customers and end users
  • Best friend and editor of the Development team

By joining forces with the Software Testing and Quality Assurance practice within SDLC Partners, we can help you realize the advantages of each of these facets of a strong QA organization. We employ an entirely US-based team of nearly 100 software testing and quality assurance professionals who are experienced in every aspect of lifecycle testing using all of the major commercial and open-source testing toolkits, as well as test process improvement and test team development and management.

Susan Keim

Point of View Author

Susan Keim, Manager, QA Analyst

Susan is a lifelong advocate for innovative solutions, happy users, and harmonious teams. She appreciates efficiency and strives to approach perfection by following the “measure twice, cut once” directive. She has spent the past 25 years surrounding herself with smart people and finding ways to help them be more effective. Her professional roles have ranged from application support to tech writer, from business analyst to implementation manager, but she started out in QA and always finds a way to return to her roots. Reach out to her at skeim@sdlcpartners.com to continue the conversation.

Share:Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInPrint this page