Are developers more important than QA testers? Probably.

Is development superior to QA/testing?

In my 19 years working as a QA tester in various methodologies, I have often heard this lamentation from QA staffers working in software development: Software development companies, large and small, always value a programmer more than a QA tester. It's a business fact. Those who can code and fix software get more attention.

If you work as a QA tester, I suggest you don't take this as a personal affront. Don't be insulted by it; it is simply the nature of the software development beast.

When I find a defect and report it, unless it's deemed "hair on fire" critical, it sits in a backlog for what can be a very, very long time. Often, I feel that I'm wasting my time digging through documentation, carefully reading over acceptance criteria and design specifications, or participating in design discussions that are often over my head. However, I do love getting background information any way I can get it. It helps me as a QA determine where the holes are or what code was rushed or forced into a release at the last minute.

All of the background information a QA can get is valuable. Becoming knowledgeable enough to add your voice to design discussions is critical to your career and job function. However, no matter how good you are, you'll never be as important as a developer, and that's OK. In this article, I'll explain what I mean and describe how you can be a unique, powerful QA who's so good you won't be ignored.

QA testers: Get over it and move on

If you're having feelings of being inferior, try displacing them by improving your QA skills. Even as a mere mortal QA, there are numerous skills you can develop to enhance and extend your QA role. Your focus always needs to be on improving the customer experience by regression testing and testing to ensure that new features work as expected and deliver value to customers.

Testing in the Agile Era: Top Tools and Processes

Cross-team skills

As a QA, you can enhance your role further by learning additional team tasks. For example, if the DevOps team members are overloaded, offer to learn and perform deployments or review the stylesheet and database changes. Learn to execute the scripts and verify the deployment's success. By learning and doing additional tasks, a QA can identify other areas for team process improvement or even defects in the deployment process. Without performing other duties, it's difficult to truly understand how to improve them.

Team building and communication

While working with your team, let's say you notice that the team works well together for the most part, but there are some trouble spots. Why not become the team builder yourself and improve team cohesion? Take the time to observe and figure out ways to improve team communication and cohesion. You can develop team skills outside the QA realm by improving the team's performance and productivity. Cross training, along with active, communicative standup meetings and alert participation in team discussion, is essential to being able to communicate well and produce a higher-quality application.

It's true that the team as a whole must bake quality into the software, but the QA member must own and encourage it. How? By setting an example. Speak up, actively participate. Acknowledge openly when you don't know something. Be willing to adjust how you work to suit the needs of each team member. In orther words, figure out how to communicate effectively with each and every person on the team. It's not as hard as it sounds, but it does require the ability to be humble, assertive, and flexible. Doesn't that sound like a QA professional? It should.

Building respect

As QAs lead the team-wide effort to build in quality to the software, they will also be garnering enough respect from developers that they'll test their code completely before moving it forward. With the creation of mutual respect comes cleaner code builds, with far fewer obvious defects. With a strong team, developers take additional pride in what they deliver to QA because they respect QA.

This mutual respect naturally leads to better code deliveries, because respect helps grow and nurture a support system of developers on a professional level. You don't have to be everyone's best friend, but as a QA you can certainly build and carefully develop a professional relationship with your team members. In order to gain your team member's respect, focus your testing by including all the details. Ask educated questions. By educated, I mean to make sure you've read all the design documentation and have more than a clue about the feature being developed. When it's clear that you've done some research into failures before asking questions, your team members know that you've done your part, as opposed to expecting them to take up the slack.

By doing the QA job to the best of your ability and developing a working relationship with the larger team, you create improved code and increase the company's business value.

QA testing is a unique talent

As a QA, you have power: the power to persuade, influence, and contribute significantly to the growth and development of the team. As noted, QAs work most effectively by building relationships, and in a DevOps context that will typically mean all the members of the software development team.

A particularly effective QA talent is the willingness to learn and stretch the standard definition of the QA role. The QA role is more than executing regression tests and entering defect reports. The exceptional QA will take part in discovering design by testing first, developing documentation through test cases, and looking inwards, upwards, downwards, and sideways to find bugs in every direction.

Stand by your bugs

I've had QAs tell me to only test in my area, that it wasn't my job to look outside my assigned zone within the application. Seriously. I couldn't believe it, and I ignored them. Members of that development team got angry when I entered defects, even though they were valid defects from areas that had never been regression-tested after the release. I stood by my bugs.

Now, it was the product manager's decision to close them or fix them, but I stood by them because I believed they were defects. Many of those bugs would have been easily noticed by customers if they'd known the functionality existed. However, I was careful and explicitly defined each and every step. I included screenshots, data comparisons, and error logs when applicable.

And ask good questions

Because a couple of my defects were "working as designed," I made sure to ask questions. But in that case, I should have asked better questions and verified, in a certain case, how the application was intended to display data. I learned from that mistake. The next time I had a question about a defect I was entering, I asked for input first.

In this way, QAs build relationships. I didn't stubbornly insist my view was the only view, and I didn't ignore the defects outside of my zone and hope another QA would catch them. I learned to ask more questions of my developers and the product owner because they knew how the function was intended to work. Sure, they closed a few of my defects, but the bulk of them got fixed. We worked it out. A QA is there to support the team, learn, and test.

Be so good you can't be ignored

Being a QA means doing your job and doing it well, and not expecting developers or other team members to do the work for you. It means digging in and learning how to read code, following along with design discussions enough to understand the point, and always maintaining a user's point of view. It's essential that the QA team member develop the team while protecting the best interests of both the team and the end user.

Here are a few final tips:

  • Before I ask a question, I know I've researched it as deeply as I can. I generally set a time limit of one hour or less. If I can't do useful research within an hour, then it's faster to ask for help and instruction.
  • On that same note, I don't keep information to myself. I create reference documents and share those for reuse elsewhere on the team.
  • I've stretched my QA role boundaries to include setting up and verifying deployments, verifying data updates and transfers, and producing secondary customer-facing documentation from test cases and reference documents.

So will I ever be as important to the company I work for as a developer is? Probably not, because I cannot fix or create application code. But do I care? No, I don't. When I'm on a team, I do my job to the best of my ability. I test, I learn, I ask questions, and I stretch my role in any necessary direction to build a solid working relationship with my team.

What do YOU think? Are developers more important than QA testers? Add your comments below.

Topics: Dev & Test