Collaborating with Developers

Most of my interaction with the developer comes from trying trying to explain the issues that I have found during the testing phase. Other ways I interact with them include, thinking of edge cases for the project at hand, what the best approach is for testing, and defining the status of the project to the project manager during the testing phase. This blog will give a few tips and tricks on collaborating with developers.

Collaborating with developers

Brainstorming Ideas Photo by on Unsplash

Understanding the Programmer

If Software development were left solely in the hands of developers, applications would be pretty much as they were twenty-five years ago. Not in terms of what functions they perform, but in the sense that only those whose vocation is computer technology would be able to use our product - Brett Petichord

Developers look at software and focus on a sub-system or module, more often than not, depending on code that they haven’t written with no comments. They are not the primary users of the software that they are going to build, so they think more about the having to satisfy the requirements set out on the ticket. In contrast, the tester looks at the system as a whole, a generalist on how the new feature will interact with the different parts of the system already in place. Understand that developers rely on the testers’ unique perspectives to give a ‘real-world’ point of view.

Like every person, we all have our own mental models. When a programmer says “How could that bug have happened, I did not change that part of the code”, they’re not saying that that it doesn't make sense. They’re saying that what you just found doesn’t fit with their mental model that they believe was to be true. One thing that has helped my testing improve and the way that the developers think is to have a session before implementation about what I expect to happen in a face-to-face meeting, let’s face it - no one wants to read the long documents given to them. The focus of the meeting is not the nitty-gritty, but a general overview of what you should expect to happen.

Better to let the experts spend time on bug-finding because testers are usually faster, more efficient, and better at finding those elusive bugs that, for us, are not reproducible - Tom Flaherty

Developers use their energy trying to understand the system they are building. Their concentration on what they have been asked to do keeps them from looking at items that you may think are important. As the tester, you find things in the product other people aren’t even aware of. People depend on you for your attention to detail.

Thank goodness a tester’s mind works like that; to do that, to focus after the thirty ninth run of the same test, would drive most developers out of their trees 

Roll with the programmers

Don’t develop a sense of testers against programmers mentality. Your team will be more effective if both of you share information like their implementation plan, early prototypes, and design documents.

The earlier in the software development life cycle you interact with the programmers, the more at ease your team will be. Members of a team that communicate often are more likely to succeed and most importantly be happy. I’m sure you’ll understand when I say that Developer’s do not like to hear about things they don’t know about. They need your support on confirming that what they are doing is right and also vice versa, making sure that you are not wasting your time on testing the wrong bits. The developer wants your confidence in knowing that the requirements are up-to-date and you give them a heads up on serious problems. In this post, I talk about getting your voice heard, if you disagree with something let them know.

This post provides things that you can do to roll with the programmers and the summary are as follows:

  • Offer early feedback on prototypes
  • Find important bugs fast
  • Act as the light in the dark to let your managers know about the progress of their build (Developers love it when you say that your halfway through testing and haven’t found anything yet)

These are but a few examples on what you should do. Understand that to become more effective with your interaction with the programmers, you have to be accountable for what you do, and also for whatever happens around you. If you do not have the mindset of accountability, you’ll never figure out how to break your plateau of doing the same thing over and over again.

Demand respect through actions

What you do speaks so loudly that I can not hear what you say - Ralph Waldo Emerson

Ultimately, your role main role is to report problems that the users may experience. Your quality offer is your primary work product, these documents mold everyone’s perception of you so take these into account to:

  • Report problems crisply - Lay out a step-by-step (NO UNNECESSARY STEPS) action on how to recreate the issue. Describe the failure symptoms and what you expect to happen. The better your reports, the better your reputation. Understand that developers rely on you for information. If the developer comes to you asking for an explanation on what the issue is, you are wasting their time and programmers will try to avoid you.
  • Focus on the work, not the person - If you see bugs, report them. See bug, report bug. Don’t report “Programmer X screwed up”. He may have screwed up, but you ruined the team’s effectiveness. If you make it your job to report problem programmers, you will get less information from them that may be critical for your testing. This leaves you ineffective, and most importantly, the team alot less effective.
  • Find Important Bugs Fast - Test that the core functionality still works before looking at the new functions, test items of high-impact before testing items of lower impact. Find the big problems fast, so they can get resolved quicker.
  • Draw the report to the stakeholder affected - We are not the actual users, we don’t know how it’s going to affect us. If we see something odd, we need to get the attention of the stakeholders that may be affected. In the end, if it’s an issue for the user, it is an issue for you. You will get more respect from everyone by having considered their point of view.  In the United States, it is illegal to discriminate people with disabilites and websites should be accessible for them.

For a more detailed explanation on how to report an issue, go to this post.

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.