Getting QA engineers and Developers Cooperate
A work-in-progress. This is a word-match to describe the relationships between developers and QA specialists operating on the same software product. Apart from the long-lasting stereotypes, some of the strategic pitfalls and lack of focus on the things that matter hinder both: working environment and project growth.
How Agile helps?
It`s pretty common for some software development companies to work on features independently from testing, to pass code over to the QA team, hearing back from them only when a defect is found. When product developers and QA teams work by Waterfall model, they practice this frequent disconnect, since the software testing is performed at the end of each coding phase. Here QA engineers provide detailed analysis on the way the software should have functioned. Since Waterfall is a downstream process, programmers and QA engineers work independently and, therefore, rarely practice communication and project engagement.
Agile methodology requires organizations to rapidly respond to the changes in project development. To really be agile, the companies need to have their QA and development working together at the project start. Agile team has a developer and a QA engineer involved in the current sprint to both code and test a feature. By doing so, a team adapts to changes and iterates the product development process.
Why TDD matters
For sure, developing and testing a feature in one iteration is no easy task. The approach requires coordination and discussion on the way feature performance is going to be checked.
Since traditional methodologies (e.g. V-Model) follow the “test-last” approach, it imposes certain time limitations for project growth. Test-driven development (TDD) on the contrary utilizes a “test-first” method by which unit tests are written before the code. This idea applies feature development where tests drive the whole process. TDD works both ways: while developers know more about the testing process, QA engineers are aware of the coding stages and the deadlines when certain parts of a feature are ready for testing.
How it works
Zephyr suggests using the same scenario to feature development & testing. The necessary tests verifying if a feature functions correctly is a starting point. Developers and QA analysts define the types of tests to run; programmers start writing the code necessary to make these tests pass. Once the code is ready, it is handed over to QA specialists who execute the tests against the feature code. This is a step-by-step process where each piece of code undergoes check-up throughout the iteration. In such a way, a feature is both developed and tested at once.
And some additional tips to accelerate effective cooperation between QA specialists and developers.
Establish clear requirements
In other words, go into acceptance testing. Acceptance criteria is another agile-related term. While user story is more about client requests, the acceptance criteria include a specific list of the features to develop. They are at the core of checklists and test cases QA engineers create to verify both the criteria and user story and ensure the software corresponds to the initial requirements. Developers and QA engineers, therefore, breakdown the strategy into the smaller tasks to achieve the results customers expect. Linking user stories to testing determines the requirements essential for future product release. Although they are always modified, especially in the Agile environment, the acceptance criteria identified before the first iteration will help to stay user-oriented.
Take a quality focus
This is a tip for both teams. Testing and coding are just the means to achieve the goal — a successful product release. A unified approach to project growth lies in taking user perspective. As a developer or a QA engineer, make sure you understand what is important for the customers and focus on that. After all, the core task of the whole team is to answer user needs wisely following the required strategy.
Prioritize defects
If QA specialists are on the same iteration with developers, they get the aim of each stage and effectively prioritize the errors they detect. Our QA engineers remember that perfect software is a fiction. Instead of fighting over every single defect, we identify the critical errors first. Since our team studies product specifics and analyses users, they report the bugs hindering the software performance as “blocker,” “critical,” or “major” to efficiently focus everyone`s efforts.
Distance is not an issue
You read a lot about the importance of open communication, task sharing, corporate culture when trying to create a healthy environment within the team working on your project. All these strategies might work well for co-located teams sharing common messenger, memes, and insider jokes.
Not necessarily.
Modern communication tools would give an upper hand for the remote teams. Chats, Skype calls, screen- and video sharing, pool of project management tools, bug-tracking systems help everyone to be informed about each other`s tasks and to stay tuned with the overall progress. Daily online meetings, iteration discussions, project conversations can be archived and later opened for review. In fact, this is the way most of the software testing companies establish cooperation with the remote development offices.
Final Word
We won`t recommend applying certain life lessons; improving working relationships is a tough job. Yet the quality of project growth depends on the safe and open working environment along with the strategic combination of development and QA engineering. You know your team better than anybody, try what is best for their comfort, and the project will succeed.
Good luck!
