Looking at the title, it's not hard to guess that I'm a QA engineer, and as such, my work quality depends on the synergy with software developers. Let's go one step further — taking care of the collaboration between the QA and development teams influences the quality of the development process.

For such an important topic, it's underresearched and misunderstood, as my experience has shown me. Having joined a small software development company — Evojam — I could observe it directly.

It all started with feedback.

At Evojam, you get feedback from your colleagues every quarter. The first time I participated in this process, I felt nervous. What will they say about my work? How will they rate it?

My worries were completely unnecessary. My teammates were enthusiastic about my accomplishments and satisfied with my contribution. If it were a test, I would pass it with flying colours. Phew!

What struck me was the number of questions as to how they could support me in my daily tasks. To give you a general context, I'm the only QA engineer at the company, and some of my teammates haven't had a chance to work with QA testers before.

No wonder they were confused and expected some guidance. I'm sure they're not the only ones.

If you feel like you could be an author of such a question, this article is for you!

The artificial division between software developers and QA engineers

Let's start with something basic — the role of QA teams. It's not as evident as it seems, and some companies tend to diminish it.

According to some people, QA engineers and testers:

  • just click around;

  • are not technical;

  • find edge cases and bother software developers with fluff; and

  • don't have an important role, as only programmers write code.

There's a tiny grain of truth there — only programmers write code. But this code often doesn't come without defects, which affects the client and end user. So it's better for the internal team to spot them beforehand, right? After all, our goal is to deliver software of the highest possible quality in the allotted time.

If we don't detect them, we might even lose a customer.

Now, I don't mean to dismiss any negative experience you might have had. In your career, you could meet a QA engineer or tester who has:

  • reported as many tickets in Jira as possible,

  • reached out to you without checking the documentation first,

  • not inquired about the reason the error occurred, and

  • pushed tasks on different people to keep an unblemished reputation.

If you can relate to this description, your negative opinion is more than justified. Still, skilled QA engineers don't work like that, and this list isn't a rule.

On the contrary, it applies to the minority!

How to improve the testing process as a developer

So, you implement new functionality, add a new collection to the database, and hand it over for testing. It is a perfect opportunity to improve collaboration with the QA team and product quality.

During a handover, point out to QA engineers and testers where to pay special attention. Consider:

  • whether the correct values are set in the DB;

  • how to manipulate them; and

  • what is the desired effect, and what is not.

Not much work on the software developer's side, but it makes much difference.

I appreciate such gestures as they prove that the task team realises bugs happen and won't settle for low-quality code.

If it hasn't been standard practice at your company, introduce it. It only requires one developer to hop on a call with QA engineers and show how each point works.

If there's no time for such a meeting, record a simple DEMO.

Both actions increase the quality of tests and the chance of the functionality working correctly. And if there are ever any regression-related bugs, QA engineers and testers should be able to identify where the error lies more quickly.

Win-win, right? And there are more easy wins that rely on developers' goodwill. Let's explore them together!

When stuck in the middle of working on a new feature, call a tester

And when you do so, start the conversation with what you've done so far.

Simple discussion and articulating the problem can show you what you need to add or improve. Talking it through, you can add test cases to cover possible paths.

This way, QA engineers and developers work together to ensure the functionality does precisely what it's meant to, and regression-related bugs can be caught already at the unit/integration testing stage.

An added benefit is the detection of a bug at an early stage, which translates into a much less costly fix.

I'm a big fan of such calls because we get a chance to solve issues together and build our working relationships.

The bug's title alone might not be enough

As a QA engineer, you receive a testing task. The title doesn't say much; the description is just white space characters. The best part is that even the reporting person often forgets what they meant. What to do with such a bug report?

At this point, not much. But we can avoid these situations altogether.

Here's how:

  • Report the ticket correctly.

  • Attach a screenshot or, even better, a video showing how to reproduce the bug.

Only two steps and they will make everybody's job easier.

Say goodbye to tasks with technical descriptions only

Somewhere in the development cycle, it turns out that developers need to add something and spend extra time doing so. In response, they create a technical task on the fly. Then the development team adds new lines of code, moves the task on the board, and submits it for QA testing. QA engineers read it and... understand nothing!

To start testing, they need to get rid of confusion, though. So, they ask the person responsible for the task what it's about.

"Oh, it doesn't matter; you don't have to test it!"

I think it's worth fighting in this case to get an answer. One of the most important lessons QA teams can get is a deep dive into what's underneath the app.

So, spend some time explaining what you've done and how it's affected the application's performance. It's an additional step towards improving quality, even if it doesn't feel so at the time!

Take these steps before moving the task to the "for testing" status

  1. Ensure that all Acceptance Criteria (AC) have been implemented.
    Seemingly obvious, but it can slip your mind.

  2. During Code Review, pay attention to the solution.
    In the current project, developers also test the solution their teammates implemented. Sometimes, they write that some functionalities don't work in some instances. It takes the pressure off the QA team as they know their co-workers focus on the outcome and care about the quality, too.

  3. Verify design compliance.
    If some changes have been introduced and approved by commercial stakeholders during the development process, write them down in the task. We often wonder why something is different from the initial design, and suddenly no one remembers the reason for alternations.

  4. Add a PullRequest link to the task.
    When time allows, we visit the linked pages, review the post-written tests, and try to find instances that aren't covered. I run my tests, look at PR, check the paths, and focus on cases I haven't managed to test. This way, I can spot the bugs and fix them with developers before passing them on to the client.

  5. Check whether the code deployed to the environment is complete.
    On a daily meeting, somebody decides to hand over a new module for tests, which requires adding new values to the form. Developers deploy code to the testing environment and inform QA engineers they can start their tests. After all, checks have turned green on CI/CD.
    In the meantime, the tester finishes the remaining tests, which takes longer than anticipated. It's 3 pm. The tester completes the backlog and starts testing a new module.
    He clicks "add new values to the form," fills in the inputs, clicks the "save" button and... nothing happens. The change is not visible.
    "Well, okay, maybe if I refresh the page, the data will appear," hopes the tester.
    Not a chance.
    A glance at DevTools and everything becomes clear — no request goes through. He looks at his watch, and it's already 3:30 pm.
    He immediately sends a message to the team, informing other members that the module doesn't work as it should. Here comes the eagerly awaited response:
    "Philip was doing a deploy, and he works until 3 p.m. He'll check it tomorrow."
    Theoretically, the tester has 1.5 hours of work left, which is ok — he'll find something else to work on. 

The worst-case scenario is when the teams work in different time zones.
The moral of the story? It's better to check whether all the necessary code has been deployed correctly to the environment!

The takeaway points

What I’ve told you today might seem obvious. And I hope, one day, it will indeed be for all developers out there! 

As a QA engineer, I ask you to write comprehensive descriptions for each task. 

I also encourage all QA engineers and developers to start working closely together. It will be beneficial to both parties. QA engineers will understand better how the application works and be able to test it more thoroughly. Having understood how testers think, developers will be able to write more resilient code.

And the outcome for the whole development team? It’s a higher quality of the delivered code and software product, which is what we all care about the most!