Testers and Developers, stop the hate

In the field of creating digital products, there exist a few minor conflicts between different professions, such as developers vs. designers, front-end developers vs. back-end developers, testers vs. developers and project managers vs. everyone. In this article, I want to highlight developers vs. testers and point out a few things (from a developer’s perspective) that testers can do to enable these two adversaries to get along. I am not implying that it’s only testers that need to change for us to all work well together, there’s a lot more that developers can do to make testers’ lives easier, but for now, I can only share from my own perspective.

Here are a few simple pointers that testers may apply:

It’s not about finding bugs but by ensuring that we all produce working software.

In many cases, I have found that testers tend to work more independently and that their sole purpose is to show how incompetent an application is. I believe that the goal of every member of a team should be to produce working software. I believe that testers should find joy not in how many bugs they have found, but in how many bugs were resolved. It may seem like the same thing but think about it like the pessimist/optimist analogy of a glass being half full or half empty.

Understand the business requirements that were given to the developer.

In most cases, testers join the project towards the end of the project or after some component has been built. I think it works better when testers are there from the very beginning; even as early as when the requirements are being defined. This helps the testers understand the requirements that were given to the developer and why something may have been developed the way that it was. While testing, if a bug is found, the tester will be able to understand if it is really a bug or a bad requirement that needs to be changed by the client.

Don’t hate the player, hate the game.

When communicating a bug that you have found, focus on describing the problem without ridiculing the developer who is responsible. Finding a bug in a developer’s software does not mean he/she is incompetent; I’m sure even some of the best coders have bugs in their software. And even if a developer seems to be incompetent, there are ways to communicate this without crushing their spirit.

Clearly describe how the error can be recreated.

I’m sure every tester hears the following phrases far too often from developers:

• “But it works when I do it”
• “But it works on my local machine”
• “Try it with this data”

This can be avoided by clearly describing how you got to the error. It can also be annoying, and time-consuming for developers to try and replay the bug that you have described. To avoid these problems, testers should try clearly describing the steps taken to arrive at error.

For example, a good definition of a bug would be as follows:

• Upon opening the Login page on the test environment
• I entered the username “Roger” in the user tab
• I entered the password “rogersPassword” in the password input box
• I was then given access to the dashboard even though the password for this user is incorrect; the correct password is “rogersPassword123”

Instead of:

“It allows me to enter even when the password is wrong!”

Find a way to manage the testing while further development continues.

This might involve discussions with project managers and/or clients. It is important to have a way for time to be allocated for bugs to be fixed. It is rare that a developer will have their hands free while their work is being tested. Most of the time, while something is being tested;

developers continue working on another feature. Switching between this development and fixing the bugs can be quite challenging. Therefore, ensure that the project allocates time for the bugs you find to be addressed. Don’t expect them to be fixed immediately and don’t record it as another bug when you find it again.

Get a scope of what is being tested and how intensively it should be tested.

As a tester, your priority is always to ensure that a high standard of quality is maintained. And for that you cannot always be limited by a scope. Although everyone appreciates your supernatural abilities of finding even the tiniest bugs, it is important to understand the scope of what needs to be tested and what can be addressed in a specific project.

For example, when testing a web application and you find a bug on the browser you are using, that’s awesome, but don’t log that as a bug for the developers (perhaps log that bug in a bug bounty program and make yourself some good reward money!)

Get to know the developers in the team.

Getting to know the developers and which parts of the system they are responsible for may help to efficiently communicate the bug to the right person. Depending on the project, developers may be organised in terms of front-end, back-end or according to features or parts of the application. Knowing who does what can make things a lot easier. No one likes fixing someone else’s bugs unless they must (even when they have to they still don’t like it)

Learn a bit of tech, have some context as to how the system is being built.

This may be frowned upon since it can be beneficial to have the perspective of a non-technical user testing the software. But I think it can be useful for testers to have a high-level knowledge of how the software is being built. It can help you converse better with developers and give you better perspective of the amount of work that must be done to fix it. Sometimes a bug may seem like something that can be easily fixed, but more work must be done behind the scenes to resolve it.

Make sure you are on the same page with the developers as to what is being tested.

Get a confirmation from the developers that what you are testing is ready for testing. Don’t test something that is not ready for testing or that is known to not be working yet, and then proudly log a bug when you see something wrong.

What can developers do to make testers lives better?

Although I am not a tester, I do believe that there is a lot that developers can do that testers would appreciate a lot. Having worked with testers in the past, I noticed that they find it frustrating when the developer releases code for testing that they themselves didn’t even test. These are those major easy to find bugs that show that the developer didn’t bother to check if something works before deploying it.

Another pet peeve that testers have is when an error keeps reappearing over different deploys and in different features. This shows a lack of unit testing from the developer. If a bug was previously discovered, a developer should try to add a unit test to make sure that it doesn’t come up again.

Overall I think developers should appreciate working on a project which has a testing team since they bring such a great value to the project. We need to be mature enough to allow them to criticize our work without taking offense.

With all this in mind, let’s go out and work in harmony to produce some working software!

This article was originally posted on the Retro Rabbit blog: http://blog.retrorabbit.co.za/testers-developers-stop-hate/