How Business, Development and QA Can Work Together to Get the Project Completed

What People Want – Understanding Stakeholder Needs

Too often, we (QA/Testers) are focused on our own needs instead of those of others. We need to discover and help satisfy the needs of others, and we also need to show that our needs are in the best interests of others.

But what are the needs of others, and how do they affect us?

Layered on top of this, your organization may be siloed (where the stakeholders avoid talking, throwing work over the wall), Agile (where there is more interaction), or using DevOps (where roles blur requiring understanding of everybody else).

Let’s begin by assuming job confidence and competence so that everyone’s priority is succeeding in their role, be it Development, Business, or QA.

We All Want Different Things

What Do Developers Want?

Developers want to get their work done then move on to the next thing, and when you’re a developer there is ALWAYS a series of next things fighting for your attention.

This encourages developers to cherry pick easy-to-fix bugs first, especially since they know that it helps make their manager feel happier when they see the open bug count drop.

What Do Developers Want from QA?

Developers want QA to write up reproducible bugs with accurate precise details, where the detective work has completed for them; this cuts down on the time they need to chase things down before getting to work fixing and checking in their bug fix.

Developers get very annoyed when they spend a lot of time unable to reproduce a bug due to QA’s lack of helpful details, which jams Development’s fix-the-bug assembly line.

Recommended read => How to Make Developer and QA Relationship Healthy

QA’s avoidance of sloppiness in the bug database can save developers time.

An attached log file may help pinpoint the details and exact location of the bug.  Related bugs, especially other pages where the same bug occurs, should be listed or linked so they can all be fixed at once, while duplicate bugs should be removed, as it will frustrate the developer who now must seek out subtle differences or lose time trying to reproduce and fix something that is already fixed.

A copied or cloned bug needs to have each copied field verified to safeguard against Development having to chase down wrong information.

QA’s proper inclusion of bug details can save developers time.  The bugs should be easy to reproduce from the given instructions, and the scope should be clearly outlined (“happens on all devices”, “only happens on IE”, “only happens when the field is filled by CTRL-V”, “fill in field by any method”).

An attached log file can help pinpoint the exact location of the bug, and an attached screenshot can help clarify what, where or how something happened.  If you can read code and have access to it, include the bug fix in your bug report – that REALLY saves time for the developer.

The “What’s Expected” part should refer to something clearly defined instead of being invented or challenging the spec.  Otherwise, clear it with Business that this change makes sense, instead of making the developer do extra work talking to Business due to your lack of effort.

Developers want fewer bugs in the way we report bugs

To be honest, these are all things that just make you more effective at your job.

We should really be thanking Development for QA-ing our work to help it run smoother!  And Development is not angry with you for finding bugs, even if they kiddingly say they are.  Development knows that the bugs were already there, waiting to be found.

What does Development want that QA also wants?

QA and Development both want for bugs to get fixed sooner instead of later and to get fixed on the first try without breaking the code in other places.

Specs that give you enough details for you to determine the logic that the code should use, as well as the performance expectations.  The release getting out the door as scheduled, with everything that entails, based on that deadline we keep hearing every day.

Talking about all that we have in common should make friendship as allies easy; we are the team that makes the SDLC happen and cooperation helps that process.  But first, we need to realize that not all bugs need to be fixed now, or even later.

QA’s job is to find and log the bugs; someone else can decide the immediacy of which ones are needed for the current release, or at all.  Maybe we were too picky or found something that is impractical or impossible to fix, or just not a high priority.

What does Business want?

Business wants to make the people happy who are demanding change. Business wants the delivery date they promised to work, despite promising that date before all knowns were known.  Business wants to be able to count on everyone putting in the time needed to enable to project to succeed.

This requires knowing how Development and QA work.  This means knowing if any new purchases are needed.  This means knowing if any of the team is on vacation or in need of training, which cuts the resource needs.

What does Business want from QA?

Business wants QA to quickly find the bugs to help produce a product that is good, and ready to release. 

They know that our role is to find anything that might get in the way of release.  Business wants more than to just know “Does it work?” – they are also concerned with the requirements (features that the new “it” must have) and getting the new “it” out in a timely manner.

QA and Development think more about all of the bugs, while Business focuses more on new features and a small set of specific known high-priority bugs.  The big concerns of Business are determining what the next release must contain, and getting it out on time, while being aware that QA has the ability to block the release.

Business is thinking about all projects including future releases, not just the current project details we stay focused on.

We need to make Business aware that the details of each project spec they define can greatly affect the completion date, which is appropriate because Business so desperately wants to meet the expected completion date.

And what we (Development and QA) seem to need from Business is early decisions on the specs so we can begin our work.

In the end, a game may get played to make the schedule work where either the release date gets pushed, some items get moved to a later release, or hotfixes/partial releases deliver a few final bits late.

Business and Development and QA need to all sit together in a room and say, “OK, here are the requirements that this release needs to cover.  Using these, let’s have Business nail down some specs derived from those requirements, which will help us estimate the number of hours needed for completion.

QA and Development will ask questions, and respond to spec details which will continue to hone time and logistical estimates, and we’ll continue to revise the specs as needed as we proceed, including ‘if we have enough time’ items.”

The clock is ticking, and a time management game has begun called People x Days Available = Doable Work.  Testing requires compiled code.  Compiled code requires specs.  Specs require decisions to be made on how to implements the requirements.

It is understood that specs are not set in stone and may get revised over time, which may generate new layers of code changes and scenarios.

Recommended read => What Do Clients REALLY Expect From the Software Testers?

We All Want the Same Things

The common ground lies in wanting to focus on our jobs and get things done on time.

Stumbling blocks laid by other stakeholders are bad, and things that help us move along are good.  We need to realize that each of us is thinking this, and we can all help each other get through this together.

Business and Development and QA all want the project to succeed and seek clarity from each other while needing to be aware that that requires providing more clarity to each other.  We want and need each other to do our own jobs to enable, in fact, to empower us to continue the cycle.

The trick is working together on achieving the joint solution of getting the project completed and out the door on time, and basking in the synergy.

Conclusion:

We are all really more alike than not alike, and changing your mindset to see that, will make everyone’s life easier.

Focus on questions and concerns that all stakeholders will share, and you’ll realize what they need from you, and how to ask for what you need from them.

About the Author: This post is written by Douglas Fink from QualiTest.  He has worn the hats of developer, Business, SQA and technical writer, and also enjoys making crossword puzzles and palindromes.

What do you think – what development, business and QA want? Please share your experience/comments below.