- The Need for Skepticism
- Controversy
- Challenges
- Ideas for the Future
- Conclusions
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Ideas for the Future
Where can conventional software testing and test-driven development meet and combine forces?
Pair Testing with Developers
I started pairing with developers during TDD because they wanted another perspective. The developers wanted to work with someone who thought about testing all the time, instead of working with other programmers who were thinking predominantly about programming. While it can be a bit intimidating to work in a technical environment where writing software code is the dominant activity, you don’t need to have development skills to pair with a developer doing TDD. All you need is to bring the testing knowledge you already have, a willingness to learn and be taught, and a willingness and confidence to share testing ideas. Combining a skilled software tester who has technical and non-technical experience with a highly technical code-level tester (the programmer) is powerful. For testers who want to do more with TDD, basic programming skills are required. To do pure TDD full-time, you’ll need to become a developer.
Because I was a tester, developers told me I provided a valuable service when I pair-tested with them when they did TDD. I sometimes felt that I wasn’t providing a lot of value during the generative phase, but we felt that with practice I could spot "code smells" and provide the design feedback they wanted, even without becoming an expert programmer. Smart testers can learn how to spot these patterns in the code in their own way, even if they aren’t programmers.
If you’d like to start pairing with a developer, the elaborative phase of TDD is probably the easiest place to start. Developers are looking for test ideas at this point, and software testers are full of all sorts of test ideas from functional testing, customer testing, and a wealth of experience with defects and testing challenges. I’ve written an article that provides some ideas on how to start pair testing. In TDD, talk to the developer about the different phases, and agree on a good place for you to step in and start. If it works out, move to the generative phase of test-driven development, and learn how to spot design problems from a testability perspective.
A key to remember is that if you’re a skilled software tester of any kind, you can bring your ideas and learn with a TDD programmer, without having any programming skill to start out. You’ll learn what you need as you go.
Why Limit Pairing to Testers?
Software tester Dana Spears points out that this activity of pairing with TDD programmers to help them as they develop a quality product need not be limited to testers. Systems analysts, designers, business analysts, and others with software expertise could also add a lot of value during TDD. I’ve witnessed these kinds of pairings, and the teams have said that they were very useful.
Exploratory Testing
I recently gave a talk on exploratory testing (simultaneous test design, execution, and learning). Most of my experience with exploratory testing is testing through a graphical user interface, the way an end user would use the software. TDD work has opened my eyes to other testable interfaces, and I’ve done some exploratory testing using an application programming interface for a program. Some software I tested was used by other machines, not humans, so I didn’t have a GUI to rely on.
I’ve also written about interactive automated testing, which involves using automated testing tools to interface into an application instead of using the GUI. In the TDD world, we’re always thinking about testable interfaces, and sometimes we do exploratory testing by changing the values of our test inputs based on the results we had from the last test run. We don’t do this very often—usually on areas that are either critical for the product to work, or are giving us trouble.
Several TDD developers attended my talk, and they asked me about combining exploratory testing with TDD even more extensively. They felt that sometimes the TDD automated tests contributed to a brittle design and hoped that doing more exploratory testing earlier in the process would help deal with this problem. Exploratory testing is a powerful way of thinking about testing, so test idea generation, execution, and the resulting learning would help improve the design and the reliability of the product.
There’s a lot of room for testers and developers to collaborate by combining exploratory testing with TDD. Testers and developers could try to use more exploratory testing in the generative phase, as well as the elaborative phase, where it comes more easily. Like our rule of "every tenth time we run the suite, we run a functional test with a database in a real system," exploratory testing could be done in conjunction with the automated unit test runs. More frequent staging-type tests would add a lot of value earlier in contributing to a design instead of feedback coming in the form of bug reports later.