A couple months ago, I perused an online article which purported to tell developers what they should learn in order to communicate better with testers. Number one on the list was, “Learn to use the bug tracking system.” After I screamed, I resolved to float some more useful ideas.
Programmers know they need to get on the same wavelength as the testers on their team. I like to think you already know that bug tracking systems aren’t the answer to better inter-team communication for programmers and testers. As Ron Jeffries once told me, “I have never participated in a really great meeting with people sitting around the issues database.”
Instead: Take a “whole team” approach to quality, and get everyone working together towards a common goal of building the best possible software product.
In some organizations, that’s easier said than done. The programmers on my team say they feel comfortable communicating with me because I have a programming background; I understand the system architecture; I use the same IDE they do; and I come up to speed pretty quickly when they explain design decisions or code issues. This understanding of another’s world works both ways. We all benefit.
The Whole Team Approach
Everyone on a cross-functional software development team must understand and embrace a “Whole Team Approach” to quality. I think we can all agree that nobody can “test quality in” to a existing code. We need a team made up of people with diverse skills and viewpoints to produce the best possible software. Everyone must take responsibility for quality, and ensure that all necessary testing activities get done. (See some examples of teams using the Whole Team Approach on my blog.).
A good place for programmers to start learning more about testing is by studying the Agile Testing Quadrants.
Brian Marick, one of the charter Agile Manifesto signers, first described this matrix back in 2003, and it’s a useful taxonomy. The quadrants get across a lot of information, such as the different types of tests, their purpose, who might do them, and whether they must be automated. The quadrants do not imply any particular order of which tests get done when.
The concepts of tests that support the team, tests that critique the product, business-facing and technology-facing tests give us a common Agile testing terminology. We can use these to discuss and plan all necessary testing activities, and ensure we have the people, data, hardware, and software to do the job.
A central testing practice for agile teams is Specification by Example, also known as Acceptance Test-Driven Development (ATDD). Eliciting examples of desired system behavior from customers and turning those into tests that help guide coding requires both testing and coding skills.
You can find plenty of information about this online such as The ATDD Arch. There are also some excellent books on the topic, such as Specification by Example: How Successful Teams Deliver the Right Software by Gojko Adzic (along with an introductory blog post that covers the key ideas), and Lean-Agile Acceptance Test-Driven Development by Ken Pugh.
Automating tests above the unit level is problematic for many teams. Back in the 90s, test automation back focused on GUI tests, using tools that designed for non-programmers. However, test automation is really coding. It deserves the same care and attention as production code, and the programmers need to help with automating tests at all levels.
Mike Cohn’s Test Automation Pyramid provides useful guidance on figuring out where to make test automation investments.
Unit tests provide the best return on investment. However, most applications also need automated regression tests at higher levels, such as the API level and even the GUI level. Each software team needs to decide on the right automation approach for its situation.
Understanding the Value of Testers
Many programmers these days practice test-driven development, (TDD) whether or not they are on self-proclaimed “Agile” teams. Although TDD is really a design activity, it does produce automated unit-level regression tests.
Agile development in particular is all about shortening feedback loops, with practices such as continuous integration and frequent releases. Testers are expert feedback providers. Where testing is treated as a separate “phase,” programmers may not be used to working closely with testers. Learning to treat testing as an integral part of the development process, as important as coding, helps programmers appreciate the feedback testers contribute.
I’m often asked: If programmers are doing these tests, why do software teams need specialized testers? The answer lies in the particular skills that testers bring to the party.
Exploratory testing may be the most important of these. Experienced exploratory testers aim to learn more about desired and undesired behaviors of the system. They aren’t just looking for what doesn’t work; they are alert for missing features, and they apply critical thinking to many aspects of quality, not only functionality. Programmers needn’t aspire to becoming skilled at exploratory testing, but they should understand the value that a good exploratory tester contributes.
A good starting place to learn more about exploratory testing is Elisabeth Hendrickson’s work, such as these slides introducing exploratory testing in an agile context. She explains it in more detail in a chapter in The Art of Agile Development by Jim Shore and Shane Warden.
Domain Knowledge
Understanding your business domain does not only help you communicate better with testers, but it helps the whole team help your customers. If you’re working on a team that practices collective code ownership, you probably have a good idea of how your system works at a high level. Testers tend to start with this “big picture view.” In Agile development, we work on tiny user stories, but good testers are always thinking about how that little chunk affects the rest of the system.
My team once budgeted time over several iterations for each team member to sit with business people as they did their jobs. That gave us a better understanding of all aspects of the business, not just the parts automated by our software. We documented what we learned on our team wiki, and identified several weak areas. We subsequently delivered simple automated functionality that prevented mistakes, and reduced the number of “production support requests” asking for manual intervention. Testers are good at communicating with subject matter experts, but if programmers are also good at this communication, it’s a huge advantage to the team.
Learn by Doing
Perhaps our teams are most efficient when each member does the activities at which she excels. But when it comes to testing, every team member needs to pitch in.
When my current team made its initial transition to Agile development, we had no automated tests. After consulting the customers on the parts of the application that really had to work, I wrote manual regression test scripts covering all those. The last two days of each two-week iteration, everyone on the team, including programmers, split up the manual scripts and did the regression testing. Each team member got to feel the pain of manual regression testing, which motivated the programmers to come up with a test-friendly code architecture and design.
I work on a testing-intensive application, and testing tasks sometimes fall behind coding. When this happens, we don’t bring in new user stories to write more code. Instead, the programmers pitch in on the testing tasks. As I’m writing this, we just finished a sprint in which one or the other tester was on vacation much of the time, so testing cards piled up on the task board. The programmers took on both manual exploratory testing and test automation tasks so that we could finish in time for release.
Thinking Skills
Skills such as collaborating and communicating well are often called “soft skills” (even though they can be hard to learn)! I prefer Isabel Evans’ term, “thinking skills.” Good testers need good thinking skills such as problem-solving and the ability to elicit examples of system behavior from customers.
When I initiated a discussion on this topic on Twitter, Liz Keogh noted that giving feedback is the primary communication skill that developers need to communicate better with testers. Feedback is the pivot where ideas become real. For James O’Sullivan, having developers and testers pair test and pair to fix bugs helped build trust and respect for each others’ roles. Catherine Louis suggested we think about not what we are doing, but why we are doing it. All of these approaches promote understanding and trust among different roles. They also all share a common theme, captured by Paul Grenyer; he suggested that we should all remember we’re on the same side.
Get Started Now
In Agile development, we do the “simplest thing that can possibly work.” Therefore I recommend that if you’re a programmer, invite a tester over to your workstation. Show her what you just coded, and ask her to pair test it with you. This might be a new experience for both of you, but it’s the beginning of a new level of teamwork. Learning to communicate better with testers will not only improve your software product; it’ll make your job more enjoyable.
Oh — and the defect tracking system? My advice is to use that as little as possible!
Naturally, if you are going to use a defect tracking tool for any purpose, SmartBear — the sponsor of Sofware Quality Connection — would like it to be DevComplete.
About Lisa Crispin
