Testers and Developers: Bitter Enemies or Secret Lovers?

testers and developers

When we think of the major forces shaping our civilization, you may think of governments and corporations, or breakthroughs in science and technology. Usually we consider these forces by the end results, like improvements in city transportation or cures for disease, rather than the dynamic relationships between people who really drive it all forward.

Lately, there have been quite a few inquiries flying around the Web about the differences (or lack thereof) between software developers and testers. It’s become somewhat difficult to know if the two are converging, diverging, secret lovers or bitter enemies. But when I took a step back to examine these fundamental roles in software production, I began to see the dynamic between developer and tester as a critical element shaping the future of software. Let me explain…

Much like all of life around us, software production arose from of a primordial ooze. This one was a messy mixture of data geeks, gear heads, and brilliant visionaries mostly operating out of their garages. Back in the heyday of early computer science, the “developer” and “tester” roles hadn’t really evolved yet. We often forget, in our debate about their differences in personality, skills, and video game preferences, that these job functions—absolutely essential to our world today—are relatively new and still evolving.

So much has happened in such a short period of time that it’s mind-spinning.  In one generation, we introduced a large fraction of humanity into an interconnected web of information, entertainment, and unprecedented opportunity literally held in the palms of our hands. So, why do I see the developer/tester relationship so fundamental to that grand creation? Some of it is a little obvious—one creates the content, the other makes sure it fulfills its purpose and works for the people who use it..  They each grow in response to each other, they are inexorably linked and dependent on each other, and as one is revealed to be essential for the world we are creating, you have to see the other in a new light.

Right now, attention is falling on the importance of the software tester, and for good reason. Major software security issues are threatening critical sectors. Software defects rack up huge expenses for individuals, businesses, and countries every year. As our civilization increasingly relies on the enormous gifts of software technology, making sure those programs and products do what they are supposed to will never not be absolutely essential.

The importance of quality software follows our dependence and interest in using software. And the more people trust software as a fundamental aspects of their lives, work, entertainment, and education, the more software will continue to thrive, to grow. So, the tester/developer relationship is one that can’t be divided, and (as we’ve seen in the past few years) is only growing towards greater collaboration. Yet, the distinction between the two roles, I feel, will continue to be clarified as the importance of both the developer and tester continues to be recognized.

Software developers and testers are the dynamic roles the whole of software revolves around, originates from, and feeds back into. And, since it doesn’t look like the ship of civilization will be steering away from its reliance on software anytime soon, I say we all could stand to stop and consider what’s really going on in the creative soup between tester and developer…and give them both their due props!

What are your thoughts on opinions on Testers vs. Developers?  Are they friends? Enemies?  Should they fight to the death, or hug it out?  Weigh in with your experiences in our comment sections.

Meg Cater is Technical Content Manager at SmartBear Software. Before entering the software world, Meg was a journalist specializing in STEM education and global environmental issues like clean water and sustainable chemistry. Her current passion centers around the investigation of how software is shaping our globalizing world and international security, communications, medicine, entertainment, art and culture.

See also:


  1. Kevin Peck says:

    As a developer personally I love QA. Developers tend to take the happy path through the code. They know where potential problems exist and don’t want to go near them. Sure, we test as best we can but in the end we don’t have the time or energy to test all the edge cases.

    QA is not the enemy. They are just helping you avoid issues with clients out in the field. I would rather have QA find the bug when I have a few weeks to fix it properly than have a client find it and have a few hours to hack in a patch while people are breathing down my neck.

    Software is getting harder to write. Back in MS-DOS days you probably had one path through your software. Start on screen A, press a function key and go to screen B. Now you have Screen A with a menu, hot-key, toolbar button, right mouse button and an automated script that can access Screen B. All those items have to enabled / disabled in sync. Developers forget all the paths when they do a test. QA has a big test plan to hit each one of them in a variety of situations.

    I am very happy that QA has the time to beat on all the little things and various paths. I want to get it running, have the core of the functionality working and to turn it over to QA in the best shape possible for them to weed out the edge cases. But I don’t use QA as a crutch. I test it first and only give it to them when I am pretty darn sure it is done and usable. I know developers who just toss it over the wall and figure it is the job of QA to find all the issues.

    Yes, I hate bugs. I feel a little bit of failure when QA finds something but I don’t hate them for it. I fix it and move on. They also act as usability testing. Does a certain operation take way too many steps? Listen to them and make the software easier to use. Did they have a heck of a time finding a feature? Why can they do it from a toolbar but not a right mouse button menu? Why is there yellow text on a white background that is barely readable?

    • +1 to what Kevin wrote

      Making devs cry is just so 80s, where I work they appreciate what I do and try to learn how I find the bugs they missed

    • Meg Cater says:

      Right on, Kevin. Thank you for your thoughtful comment. I think your point about software getting harder to write is so true. And it will only get more complex as it’s integrated into everything we do… even into our physical bodies! So necessarily, QA will gain in importance, and all software dev will hinge more on the co-working, goal oriented relationship between dev and QA. Developers need to be free to develop and not worry about testing too much. But, I respect that you don’t use QA as a crutch. That’s a sign that you care and are a good coder—and will only get better.

    • Jamie Young says:

      +1 for me as well.
      Testers and developers ultimately share the same goal; to provide quality software to stakeholders. There’s no reason for the two teams to ever be on different pages or be combatative towards one another.

      I’ve unfortunately been on teams where devs and testers were more often at odds with each than not, and it’s impossible to get anything done. And if something actually does get done, its quality suffers exponentially.

      Fostering a good relationship between the two is extremely important, because in the long run that collaboration only serves to make us better professionals.

  2. Roberto Balducci says:

    I think testers and developers should be neither enemies nor lovers.
    They should just collaborate to achieve the goal. The goal is to release a feature without bugs that meets the customer requirements as soon as possible.

    • prashantkaw says:

      So true. Not tribe of developers and not a tribe of testers but a united tribe of awesome customer experience.

  3. perfect title to describe this two careers. Both careers have everything similar incense of knowledge and skills. But difference came when one built’s and other one spoils or gives advises but both have to cooperate with one another. They give us quality work with assurance of working their analysis helps us to improve our services. You can say that they have originated from the same field. Answer to last question is yes they should work together.

  4. Having the idea of Testers being against Development work is an idea that should be removed, specially if the team is small and they are following Agile methodologies. If is correct anyway that the tester work is to detect the defects and bugs and verify the application is developed as the client requires, the way the tester should follow up the defect management is to being proactive with the rest of the team to help provide a solution rather to put the blame on the other elements.

Speak Your Mind