So there have been a few people blethering recently about Testing as an Activity. I’ve been discussing this subject recently with Steve (Janaway), as he has been talking about it on his blog and at conferences: see here, and here.
I agree that testing is an activity, in the same way that coding is an activity. Or peer reviewing, or writing automated scripts, or running automated scripts – all activities. The one thing that I disagree with in the sentence, is the singularity of the word “activity”. I suggest that testing is actually MULTIPLE activities. So, this post isn’t intended to be based on “testing as an activity” being the misconception. The singularity of the words “an activity” in the sentence is the instigator of the misconception that “anyone can test… since its a single activity that everyone is responsible for, right?” [Yes. I have actually heard this statement being made, which stemmed this post actually.]
Let me explain in more detail…
When we think about the entire team being responsible for quality and for testing, and we think about that in the context that testing is actually multiple activities, then it is clearer that every project member should own some of these testing activities, relative to their discipline. For example:
- Developers focus on writing unit and integration tests, performing code reviews, performing “happy path” tests and also doing other various checks (such as error handling and validation rules, etc). These are all testing activities.
- Testers perform Exploratory Testing, Requirements Analysis, are involved in Performance Testing, Web App Security Testing, Accessibility Testing and many other aspects of testing. These are all testing activities.
- Developers in Test (or SDETs), they will also have different testing activities such as building Automation frameworks, writing automation scripts and running/maintaining the automation suites, etc.
- There might be other project members involved with other testing activities, for example with building environments, you might have a release management team, you might have a web ops or support team. These will all have some testing activities involved. They might also have some development activities involved too, without being developers…
So, what am I talking about? Testing isn’t randomly clicking around the software to see if you can spot bugs.
There are many different testing activities. And these different testing activities require different specialist skills (e.g. you need coding skills for writing automated scripts, writing unit tests and for reviewing code. And equally you need lateral thinking skills for performing exploratory testing).
When I hear someone say: “Anyone can test”, I like to reply with: “But not everyone can test well”. This is the same as saying “anyone can write code, but not everyone can write code well”. I heard this from James Bach on his RST course a good few years ago now and it still comes in handy in discussions today.
Good testing requires skill. So, you’ll want those specialist members in your team (a football team full of goalkeepers is not the right way to go).
To avoid falling into the trap with this misconception, remain aware of the fact there are different types of testing activities and think about how each project member should have different responsibilities surrounding these activities relevant to their skill sets, knowing that the whole team is contributing to “testing” overall. It highlights nicely that everyone is responsible for quality. 🙂