6

Testers and developers don't always get along due to a wide variety of reasons.

What can testers and other people can do to make software developers lives easier, more productive and more enjoyable?

Insipred by How can developers improve relations with testers?

closed as too broad by dzieciou, user246, bish, Helping Hands, JustARandomGuy Jan 4 '16 at 4:58

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Kate you had a good idea :) – Michael Durrant Jan 1 '16 at 13:17
  • 1
    I love this question as much as I love my profession but books have been written on that topic and "there are either too many possible answers, or good answers would be too long for this format.". Hence, I'm both upvoting and voting to close this question. This question describes everything this whole forum is about and should be rather split into smaller areas: regarding communication, bug reporting (which actually is form of communication between qa and dev), resolving conflicts, involvement of QA in root cause isolation. All those deserves separate questions. – dzieciou Jan 1 '16 at 22:34
  • @dzieciou - I'm voting to reopen for the same reason I disagree with the companion close votes for the paired question. Yes it's a very broad question, but it's also a very valuable one. – Kate Paulk Jan 4 '16 at 12:13
  • @KatePaulk, maybe then it makes sense to turn it into a community wiki? As there's no single answer. – dzieciou Jan 4 '16 at 12:45
  • 1
    @dzieciou - I think a community wiki is the way to go for this and the companion question. – Kate Paulk Jan 4 '16 at 17:47
6

In addition to Michael Durrant's excellent answer :

Take time to make accurate bug reports. My rules of a thumb(I've been on both sides of the equation, which helps) :

  • Every hour spent in digging into the bug from the tester's point of view spares one day of work for the developer. Properly checking the exact conditions of the bug, the exact parameters, helps a lot for the correction.
  • Every bug report completed in less than 15 minutes is doomed to lead to a correction that is not correct. Make both screenshots & a full text description of what's happening.

"Entering low amounts in the tax fields crashes randomly" is far less informative to the developer than:

"in the tax field

when the customer has an address abroad

when the tax amount is strictly inferior to 1.00$

when you press the continue button

a technical pop-up appears with the following information

tested on machine blahnlah version 3.14159, occurs also on machine blublu with the same version 3.14159 - worked fine on version 3.14158"

If you add a few screenshots to show what's happening, the developer will have an easy job. And they are going to like you.

OTOH, if you limit yourself to the first line, without any screenshots or additional information, they're going to doubt your added value.

  • 1
    Good point. I've also started taking QuickTime movies for workflow bugs – Michael Durrant Jan 1 '16 at 18:06
4

The primary thing is to try really hard to find bugs. This may sound obvious but in fact often QA folks are intimidated by software developers and in addition many organizations reflect this in their workflow and processes. It is easy for a QA person to think, well if I PASS this and the developer can move on I will make them happy. While that might be true of inexperienced junior developers, a mature professional developer will actually be very happy for a tester to find relevant bugs that they missed and over time trust can grow.

In addition:

  • Test the edge cases that developers often don't look at
  • Test on a wide variety of devices, browsers and versions that the developer may not have tried
  • Test sad paths the developer may not have tried
  • Ask to pair on test plans up front
  • Share testing tools with the developers that will use them
  • Work in the same physical area
  • Respect working habits, 'flow' and learn how/when to interrupt and when not to for each dev
  • Share a common wiki that documents the environment setup knowledge, code to use, seed data to load, database scripts to run, etc.
  • Work on making sure environments are the same so that bugs found are not just due to environment differences
  • Use a "three amigos" (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) approach to help bring QE, product and dev together to work collaboratively
  • Clearly document the steps to reproduce bugs that are reported and include: exact URL, data used, steps to follow, options to choose, etc.
  • Document the environment used when experiencing bugs, e.g. Virtual Machine, Operating System Version, device, browser, version. Try using other systems and see if they also have the error.
  • Pair with a dev when experiencing / recording a bug. They will frequently ask "show me the console" or "show me the network requests" or "show me the database record for that", etc. This can be helpful not only in fixing it but also in ascertaining the initial priority and importance and whether it should even be worked on.
  • Use screenshots and desktop movies when recording bugs.
  • Learn the business domain as much as possible so that assessment, prioritization and description of bugs is related to business needs.
  • Study the skills behind good QE and be an advocate of them to developers with presentations, emails, adhoc conversations, etc.
  • Thanks for the amigos link. Very useful - even if my shop is not agile. – gazzz0x2z Jan 1 '16 at 17:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.