I’ve been thinking about testing activities and tester roles lately, or more lately, since it seems to be a recurring topic on this blog. I have to admit that I remain a bit surprised how often testers argue about what is and what isn’t testing.
So – let me throw a few examples of potential testing activities out there for discussion or comment. For the scenarios below, consider two questions:
- Does this describe a testing activity?
- What role typically performs this activity?
Alex practices Test Driven Development. He consistently writes unit tests before implementing the code those unit tests verify. Over time, he’s built up a large set of unit tests that verify the correctness of all of the modules he owns. His unit tests give him the confidence to refactor or add functionality at any time.
Beth works closely with another teammate to ensure that the code implementation is highly testable. This includes pairing on many of the coding tasks, as well as adding hooks or accessible interfaces to the implementation when necessary. Her work results in code that the team finds straightforward and easy to test.
Chuck spends a lot of time analyzing code. Mostly, he’s a rock star code reviewer, and has found dozens and dozens of critical security and reliability issues in his team’s code base during the review process. He often uses tools and techniques like static analysis and complexity measurements in order to target his efforts. The whole team looks to him for critical code reviews, and he’s a mentor for many of the new team members.
Denise painstakingly enters test cases into a test case management system, and then regularly runs subsets of those tests as dictated by her management. She likes the predictability and structure of this approach and his attention to detail makes her successful in her job.
Frank finds product bugs by the handful. He uses a variety of test techniques, approaches, and tools to find several high quality bugs every day. Everyone on the team values his efforts, and many people on the team look to him for coaching on test approaches. His approaches are unscripted, but nobody doubts the effectiveness of his approach.
Fiona spends most of her day writing automated regression tests, and is constantly learning new approaches to writing automation. She writes high quality, trustworthy code that has few false positive / false negatives, and has earned the respect of everyone on the team. She enjoys writing automated tests and is proud of her accomplishments.
Greg works closely with the user experience and project management teams to ensure that the customer experience of his team’s product is of high quality. He frequently analyzes reports from customers and makes sure that all relevant team members know what the most critical issues customers are facing. He uses his broad knowledge of customer data to be influential on both product and test design.
Helen is a bit of a tool-smith. Although her team uses a lot of open source tools, she writes the applications and utilities that stitches the tools into an end-to-end testing framework. She loves thinking “big picture” and ensuring that all of the components in the system work together seamlessly. She doesn’t perform any product testing, but her work enables many of the testing activities to be successful.
To me, I could make a case that each of the scenarios above describe a testing activity – but I could also make a case that many do not. I’ll leave my observations at that for now and see what happens in the comments.