5 Tips to Follow for Productive Testers-Developers Relationship

QA engineers and developers are from two different worlds. Someone may say that they are just like well-known Tom and Jerry. Most likely, common activities will not be able to benefit if their relationship and mutual understanding are at a low level.

A simple example: if a tester regularly pulls the developer on trifles, writes poor test cases, and makes a lot of small defects, then the developer will only get angry and build up hate towards QA engineers.

This article presents 5 effective tips that help junior testers to find a common language with any developer!

#1 Keep a balance between quality and quantity: the search for bugs should not be more important than a product

Sometimes, junior QA engineers in software testing companies try to cause a software crash by all means. They start with a set of negative cases and overload the developer with minor things. As a result, they don’t keep up with positive scenarios because the time for testing is over.

Ideally, the tester should first run all available positive cases and verify that the software functions correctly under all possible scenarios.

#2 Analyze a defect before you add it to the bug tracking system and send it to the developer

For example, testers may often assign the task to the wrong department. Let’s say, when testing the site, some pages fail with a 500 error. An inexperienced tester may decide that this is a problem at the front end and create a report for the front-end developer to fix the bug.

It would be a good idea to check the status of pages in DevTools and decrypt the response code from the server. Maybe the problem is there (on the server) and then the defect must be fixed by back-end developers.

Also, a big mistake that is commonly made by junior testers is ignoring the current relevance of the specification (technical requirements for the project). At the start of the project, these requirements may have only one version, but in the process of developing, this content may be changed. And if the QA engineer won’t monitor documentation updates, he may record a bug that isn’t actually one. Hence, the development team will spend a lot of time trying to find the roots of the problem.

#3 Don’t forget about developer convenience

Tasks and fixes that testers send to the development team must be described in detail and clearly stated. Here’s a checklist that may be helpful here:

1. All steps to reproduce a bug are written without missing any. The developer can follow them exactly and reproduce the bug.
2. Screenshots and video files are attached.
3. Current configurations of the tested environment are also mentioned.
4. There are credentials for users with a bug.
5. There’s a screenshot or a link to the place with a bug.

#4 Improving technical skills

Sooner or later, QA consultants start to ask the following questions:

1. How to view log files?
2. How to change configurations of a tested account without the developer’s help?
3. How to test API?
4. How to test the integration of desktop and web versions correctly?
5. How is the interaction between the site and the CRM programmed?

Skills to work with Postman, MySQL and Bash don’t just improve the tester’s knowledge but also are an incentive to improve the technical expertise.

#5 Communicate with each other

QA engineers and developers should always discuss controversial issues. This is an axiom since some tasks can be effectively solved only together (e.g. when testing database migration, the test environment needs to be returned to the previous version).

Also, it’s worth discussing with developers the main interaction principles before proceeding to work on tasks:

• Should defects be recorded separately or together?
• Choose time and days when you can come and discuss some nuances of work.
• Request the data to develop automated tests (if there is any automation).

Conclusion

Communication between testers and developers is a fairly important aspect of software development, support, and testing. QA engineers should speak with the developers’ team in the same language. But at the same time, testers should be able to handle some minor issues on their own without developers’ help. And it’s definitely a bad idea to gloss over controversial points: try to say everything at once and on the merits.