QA and Dev Team in Agile Sprint
“Share the pain and find together the solution.“
Written by Aida Mackovic and Deniz Kesten, QA engineers at Softray Solutions
The relationship between QA and the development teams is a topic that QA encounters in its daily work, whether it is writing automation tests or doing any type of manual testing. Below we will see some of the advantages and disadvantages of the two teams working together, what should the QA’s relationship with developers look like, and tips and tricks on how to handle this relationship for the sake of improving the quality of the end software, which is our goal.
There are companies that are organized in such a way that Dev and QA teams are under the same roof, on the other hand there are companies where this is not the case, which bring together only QA teams that perform their tasks away from Dev team and where face to face communication between Dev and QA team is minimized and restricted only through mails and other communication channels. Both approaches have their advantages and disadvantages.
One of the main concerns of the QA and Dev teams working together is communication.
Why do Dev and QA teams sometimes clash?
The essential difference lies in the different tasks of each team. Developers are only focused on specific functionality and sometimes forget how that functionality will fit into the wider picture, or the whole application. QA engineers, on the other hand, need to look at the bigger picture and the user perspective, i.e. how any one functionality will fit into the overall application.
What can the QA team do then to prevent this and realize the full potential of agile development?
• We can give one example where the application passed all functional tests and had a great appearance, but users complained that they could not easily understand the application, which is actually the main problem.
• Responsibility — It is very simple; in one agile team everyone should be responsible for the quality of the product or application. There should not be us or them in the agile team. Developers should be responsible for their code and make sure to write proper unit tests, while the QA team should test the entire system. Yes, the QA team should be the last link before the functionality is delivered to the client, but in an agile team, everyone should bear the same responsibility for product or application quality.
• Prioritize — It is very important to determine what things need to be fixed immediately and what can be tolerated for a certain amount of time. Otherwise everyone will spend a lot of time fixing things that are maybe not so important. For example, you can specify showstoppers around which you simply will not compromise against other bugs. In addition, if you are burdening developers with minor things just before production while there are things that are showstoppers which inhibit your ability to go into production, it will surely cause frustration.
• Be constructive about the disadvantages — We all know that as much as you tested the code, it can never be completely bug free. There can always be a glitch that will eventually be discovered by the end user himself. The key is to stay calm, learn from mistakes and improve the next iteration of production. Developers often ask questions: “How did you miss this? Didn’t you test that?” However, the reality is that the software becomes very complex and not every single scenario and configuration can always be tested. Testing is performed on a risk basis; we test those things that are considered to be the most important and commonplace according to the time we have.
Another important thing is to share with the developers what the QA team is doing. Often it is really important to share with the developers what we plan to test next. This way they will start paying attention to the things that are important to the QAs and look at the bigger picture.
Communicating with the rest of the team and presenting the system as it is used by end users can extend the scope of testing. Doing this also provides an extra pair of eyes to test the application in more detail.
For example, once our QA team presented to the rest of the team the greater functionality of our application that characterized that sprint, which proved to be very useful to all team members for a better understanding of business logic.
“Keep calm and enhance your team testing culture.” — Claudia Badell
Don’t punish developers or users
Very often we can hear our colleagues threatening in some way that they will not make new functionality due to lack of quality. In our opinion, this is a very bad decision. When we think about the outcome a little bit and don’t approve of new functionalities, our fellow programmers may feel inadequate, team tensions may become apparent, and even worse, end users may not have the opportunity to use said functionalities. In this case much can be done, for example: Approve a part of the application that meets the quality standards while emphasizing to users that the functionality is not complete, then make a list of defects and fix them in the next production. This means that users will be able to use the new application, understanding that it is half completed. We think this is a win-win situation: users have received new functionality and we have feedback from them personally.
“A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being.” — Joel Spolsky
Finally, we must emphasize that it is essential to take the initiative.
Skilled QA engineers do not wait for magic to happen on its own, in order for everything to work as it is supposed to. Instead, they take the initiative and improve collaboration with their developers, keeping in mind that providing high quality software to users is a goal they all share.
If you enjoyed reading this, click on the clap button so others can find this post.
