How to Improve Communication Between Testing and Development Dayana Mayfield , Dayana is a QA engineer turned technology writer living in Milan, Italy. She's always down for a smoothie. January 4th, 2017 Developing in an agile environment brings together requirements, design, maintenance, and deployment so teams can hit the constantly moving target of user expectations. Nowadays, products see more releases more often, which requires more interplay between dev and QA. Testing and development have come closer together in the last 10-15 years than would have been thought possible, and while testing can still be seen as a commodity (instead of a critical step), all that proximity has led to greater knowledge transfer and ultimately more skilled testing. Still, the communication barrier between testing and dev is an age-old conundrum in the software world. Here are some of the ways that teams can break down the barrier and build better products together. Share a common language Testers can still struggle with basic terminology within JavaScript, CSS, Java, PHP etc. Sometimes, fear of miscommunicating or sounding juvenile can keep testers from speaking up. Testers are wise to take beginning development courses, attend workshops, or simply to peruse online glossaries for commonly used scripts and languages. You don’t have to be able to code to get a grasp of various elements, functions, and query types that will enable you to communicate any input or concern. I am more and more convinced every day that communication is, in fact, what makes or breaks software projects. Gojko Adzic Developers can also work to include testers in the overall project plan by speaking in terms of user stories and project requirements, rather than code. This keeps everyone on the same page. Have clear requirements from the start Agile acceptance testing—which is an evolution of black-box requirements testing where iterations are verified in terms of requirements—ultimately helps redefine testing as integral to the project. Looping testing and all other phases into agile sprints can only occur when specifications and requirements are clear. Linking user stories to testing is essential to go beyond finding bugs and ensure that a product is truly ready to release. But this is only possible when requirements are clearly communicated and updated at each and every iteration. Requirements must be written in a way that they serve everyone on the team. Keep QA and development on the same iteration Test driven development is when fail tests are actually written before a single line of code, so that development aims at passing the test. This completely flipped model may not be desirable for every team, but the concept of keeping QA and development tightly interlocked is what counts here. Even in agile development environments, testing can still get left until the end, or lag so behind that testers will be off by a sprint. But that isn’t truly agile. And it doesn’t lead to quality. When testers have time to learn about the development process and system specifications at the start of the iteration, then they can initiate a test plan simultaneous to development and be ready to test sprints very quickly. Ultimately, this helps developers to actually get the feedback they need when they need it. Even when deadlines are tight, it’s important to keep QA on the same page. Otherwise, teams risk devaluing testing which further breaks down communication. Prioritize bugs and find solutions When there’s a breakdown in interaction and communication between testing and development, each new bug report can feel like testers are “passing the buck,” being picky, or worse unhelpful. Meaningless bugs are probably the number one complaint by developers. Of course, with improved reporting processes, issue video recordings, and clear test cases from the start, every bug can be given meaning and made to be helpful. But there’s more to it than that: prioritization. Which comes back to having common goals centered around project requirements. Testlio has a number of ways (from the graphical to the managerial) to keep bugs tightly prioritized and inline with sprints. When testers are on the same sprint as developers, understand the aim for each iteration, and share a common (project-specific) language, then prioritization is made that much easier. As testers become more skilled, they can also start to identify possible solutions or root causes, further increasing collaboration with development. Performing end-to-end checks on actions that haven’t had issues can help testers start to identify root causes, which will lessen the volume and increase the quality of individual bugs. Make more time for exploratory testing Testing and time? Hmm… One way to make time for testing is for QA to happen simultaneously. QA can get started interpreting requirements, developing test plans, writing test cases, and running certain automated tests all while development is still going on. But with exploratory testing, a feature needs to be largely ready. Exploratory testing allows testers to function almost like users, and the inputs are invaluable. Not only is exploratory testing essential for helping meet the requirements of an individual sprint, but it can also help define goals for the next round. Developers can learn about testers’ concerns for a proposed new feature before developing it, find out how existing features interact within complex use cases, and get a clear understanding of the intuitiveness of the design. Get some distance With all of the increased interaction between QA and development, you might be thinking that co-located teams have the advantage. Not necessarily. Some argue that a remote environment leads to better testing. Think of it this way: when working side by side, all sorts of assumptions can be made. Assumptions of what someone knows, understands, or is currently working on. Innovative tools that co-located teams would ignore can give remote teams an upper hand. Screensharing, chat, and other types of messaging or project management tools can help keep everyone on track in unique and creative ways. Project conversations and more likely to be archived and later pulled up for review. Also, lack of face-to-face interaction can often lead to more clear, deliberate communication. So long as there is commonality between project goals and terminology, dev and QA teams can improve communication whether they are remote, co-located, or some combination thereof. For high-quality testing aligned with your development, contact us.