This is a guest posting by Simon Knight. Simon Knight works with teams of all shapes and sizes as a test lead, manager & facilitator, helping to deliver great software by building quality into every stage of the development process.
The terms “testing” and “checking” tend to get used interchangeably for activities performed by development teams to verify readiness and/or completeness of software products. Testing and checking could be easily interpreted to mean the same thing. However, as with most words in the English language, both testing and checking are in fact multi-faceted terms, layered with meaning and nuance depending on your context and audience.
For example, if you Google the question “what is software testing?”, you’ll get back a facsimile of the ISTQB definition:
“Software testing is a process of executing a program or application with the intent of finding the software bugs. It can also be stated as the process of validating and verifying that a software program or application or product: meets the business and technical requirements that guided its design and development, works as expected and can be implemented with the same characteristic.”
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
That settles the matter then, right?
You’d think… But on the other hand, Context Driven Testing (CDT) figurehead Michael Bolton asserts that testing is “a process of exploration, discovery, investigation, and learning.” Whereas according to him, checking is “a process of confirmation, verification, and validation.”
In case that’s not sufficiently clear in the context of the checking-versus-testing debate, checking may typically mean activities we can program a computer or robot to do; it’s low-skill, repetitive work. Testing on the other hand, is exploratory and dynamic, normally requiring human intellect, often utilizing a dedicated and skilled resource.
Thanks, I feel much more informed now. So, what’s all the fuss about?
Some people within the wider (i.e. non-CDT) testing community think that the distinction is used as a form of intellectual bullying. The way the difference between testing and checking is debated, taught or otherwise discussed in project teams or within organizations has been perceived to be uncharitable in nature.
Specifically, Brett Pettichord co-author of the classic software testing book Lessons Learned in Software Testing (mentioned in a previous blog here) and Marlena Compton who, on May 18th decided to start a fire on Twitter with the tweets below:
Go and check out the full thread. It makes for an interesting read.
Is it important enough to argue about?
Although it may be counter-productive to bring it up in a conversation with Joe Developer, the distinction between checking and testing is an important one. Understanding the difference between tests that help you learn something new, versus tests that confirm something you already knew (checks) can help to steer a successful testing strategy.
The point of the Twitter debate (in my humble opinion – treading on dangerous/controversial ground here…) was to call out some people in the industry, a minority hopefully, who might use that distinction as a kind of blunt instrument with which to beat developers during discussions around what to test and how: Consultants and Trainers using “testing” and “checking” as buzzwords to drum up business; overzealous CDT followers looking to raise their profile and gain popularity with peers by using trending terminology.
So why do I need to know about this?
What you need to know about testing and checking, is that they’re both valuable strategies in a balanced approach to carrying out your testing.
Test to explore, learn about and detect new bugs in your product. Test to ensure you built the right thing, and that you built it right.
Check to verify that what you think you know about the product is still true. Check to ensure nothing has changed or regressed since you last tested it.
Distinguish between testing and checking to the extent it serves your test strategy well. Use checking as a heuristic to help you determine when, where and how to automate. Use testing for discovery, learning and creativity. Find a balance between the two, and communicate that to your people.
But for goodness sake, be careful how you talk about your testing. By all means replace the word “test” with “check” when referring to your automation stack if it helps. But don’t try and make everyone else do it. And don’t pick other people up when they don’t do it, unless there’s a very compelling reason to do so.
Precise language is important. Relationships more so. Your team will thank you.
