Three Ways Developers can Work with QA
Writing bug free software from the very beginning is virtually impossible. Writing great software from the beginning is slightly more possible. There are always bugs along the way, and that can make or break some organizations. In traditional software development life cycle processes, there is usually a tradeoff between quality of software and time: The better the software, the longer it takes because of lag time from one team to the other. IN this situation, developers would write the code, and then give it to QA who tries to find as many bugs as possible before it goes to the next person.
Organizations understand that the process needs to change – therefore many development teams are working with in an agile process where the lines between QA Engineers and Developers are often blurred. This ambiguity can cause frustration for the team because in their traditional roles: developers want to deliver code while QA want to deliver quality. Having different priorities can affect how the team collaborates, but here are three ways to help bridge the gap:
- Uniting the Team
In an agile world, testing code doesn’t mean running a test and reporting it for the next team to work on it. This siloed way of testing is counterintuitive to the end goal – which should be to deliver quality software. There shouldn’t be a “my team” and “their team” mentality, but instead QA and developers should look at this as “our team.” Both roles need to communicate with each other to break down barriers and form the one team.
To unify the team, teams can share responsibilities or swap roles. By sharing the responsibilities, there is not one person at fault for not getting the job done. This allow allows both roles to see what each one is doing and how it gets done, and they can cross train each other on best practices they have learned over the years to find/fix bugs.
- Focus on the Customer
Software development teams need to build with a customer centric approach where quality is the upmost important. Customers and end users are the people who are buying and utilizing the products, and they should be at the forefront of all decision making. The end user doesn’t care how many tests a team runs on the software – they care about the quality of the software and if it solves their problems. Don't just look at the user story definition. Try to think like the users and make sure the application will make sense from their perspective.
- Understand that there will always be bugs
At the end of the day, we can focus on quality all we want – but there will always be a bug. To catch bugs earlier on, testing should start from the be the beginning when the code is created. Developers and QA should work on the iterations together to not only report, but to fix the bugs. Tools such as TestLeft can help the development team shift left in the SDLC by testing bugs in their IDE.
Having Developers and QA work together is not an easy feat, but when they do work together, organizations can deliver higher quality software in a shorter time span. Communication should be the priority to get Developers and QA to work together, and organizations should help foster that bridge.