Ways of aligning Test Engineers with Developers

As a testing professional, I know how tough it is to align each of these communities during SDLC cycles. Most of the time there are lots of differing priorities that lead to arguments and damage to the final goal to be achieved. Developers focus on delivery of the code and Test engineers focus on quality.

Most of the teams have adopted agile but how effectively they have adopted this model is still a big question mark. Recently I attended a STEP-IN conference and in one of the presentation it was stressed that do we really need agile? Are we following agile in a right manner? And many more such questions were highlighted…..In the agile model, we are writing user stories, doing daily stand-up, doing short iteration, planning, giving demo of the implementations, retrospective etc. but are we really following agile? If you notice minutely, in many of such teams test teams end up working in waterfall model only, small iterations end up working in waterfall. They are always waiting for the build and are looking to test and build the quality from end to end in the system. User stories when come to the test engineers they have to work hurriedly to finish them before the end of the sprint . There is always one question asked : Can testing be finished on time? And to meet the deadlines, the test engineering team ends up working late, over weekend ..All this process leads to delayed feedback, short test cycles and loss of quality ownership. It remains with few instead of the whole team.

Some of the following tricks help both these communities to work together at each phase instead of serially:

What teams need to adopt?

1. Focus more on UX approach (User experience) :

I attended one session in STEP-IN forum where the stress was on UX approach leading to better quality. I completely agree with that approach. Most of the time test engineers keep on finding the defects that might not be the relevant areas for the users. Don’t follow the specifications or user stories as such but try to understand what users are going to do with the application and where their focus will lie.

In one case I was involved in, the application had an error-reporting feature that passed all the functional tests and had a great look and feel. But customers complained that they weren't able to easily understand from the report where the highlighted problem actually was.

Always think of your users and don't test just to say that you performed a test. Users don't care how many tests you ran on your application—they care about the product quality and that it answers their needs.

2 . Share responsibility

Everyone should be responsible for the quality of the product. In an agile team, there are no more "us" and "them." Developers should be responsible for their code and make sure they write the relevant unit tests. QA should test the whole system.

Yes, QA are the gatekeepers, but everyone in the agile team should have the same responsibility for the quality of the product.

3. Prioritization and focussed areas

As a gatekeeper, you can't fight over every single defect. Understand which fights are worth fighting and where you can let go. Otherwise, everyone will spend a lot of time fixing things that are not that important.Define your own "red line" of things you simply won't compromise on, and focus only on those things. For example, I've avoided fights about installation tweaks for on-premises solutions that only get installed once.

Many teams set up a "defects committee," which predefines showstoppers vs. other bugs before each sprint or version is released. This helps focus everyone's efforts.

4. Be constructive about defects

No amount of testing will ensure that you have zero defects. Some will always escape even the most rigorous testing procedures and be discovered by external users. The key is to keep calm, learn from these "escaped defects," and improve your next release.

Developers love to ask QA engineers, "How did this get past you? Didn't you test?" The reality is that software gets very complex, and you can't always test every single scenario and configuration. We conduct risk-based testing and test the user flows we see as most important and common according to the time we have.

In some cases we consult with product management, commercial stakeholders (sales, pre-sales, etc.), or even the customers themselves. If something gets through our web, we do a debrief to discover what happened and why we missed it, and, we create an automatic test for escaped defects.

5. Create visibility into your activities

Visibility improves collaboration and trust in any team, and agile teams are no exception. You shouldn't assume that developers or any other stakeholders know what you're up to, how you're testing, or what your standards are. Review what you're planning to test with the developer.

When you share your work with developers, they can start paying attention to the things that matter, upstream. Having bug-hunt days, with additional stakeholders from product management, support, and architects, not only widens the scope of testing efficiently, but also gets more eyes to scrutinize the product. Publishing important lessons learned from customers has the added benefit of establishing you as a subject matter expert who represents the end user.

6. Don't punish developers or users

I often hear QA threaten that they won't approve a feature because of low quality. In my opinion, this is really the worst thing you can do as a tester. Think of the outcome here: By not approving a feature, you alienate the developer, and, worse, your users will not have the chance to use it.

There are many things you can do in case of low quality: Have a task team dedicated to improving quality; only release the first part of a feature (one that is sufficient quality); and the list goes on. A common tactic is to mark a feature as "alpha," "beta," or "early access" to set expectations. This means that users will be able to start using the new feature, understanding that it's perhaps half-baked. I think this is a win-win: The users get the feature, we get feedback from them, and our "quality conscience" stays intact.

Take initiative

Skilled QA engineers don't wait for some magic process to make everything run smoother. Instead, they take initiative and improve collaboration with their developers, remembering above all that delivering a high-quality experience to the user is paramount. Testing is a means to end—that end being the quality itself.

7. Know what the developers have developed and tested

I have underlined both these words viz developed and tested. Because a test engineer if knows what the developer is developing /has developed then he/she can give an earlier feedback.

Now why test engineer need to know what a developer has tested ? It gives a good idea to the test engineer about the risks in the code. Accordingly the test strategy can be framed and hence the risk based approach is followed better.

8. Know what the developer is worried about?

This feedback needs to be there in developer/tester hand shaking process. This helps again in making the test strategy and where the tester needs to focus more.

Although there are many benefits that can be gained by following these steps but working closely (between developer and test engineer) but we also need to be cautious and ensure that people shouldn’t be dependent on test engineering community to catch up all the weak/missing areas in the user stories. In these situations, some gentle encouragement and tutoring from the tester, such as steering the discussion toward how the developer might have caught an issue in the user story, defect in the functionality through automated testing etc to keep both parties in harmonious balance.