I recently had another interesting conversation about testing. I’ve had this discussion many times throughout my career: What is software testing? Or perhaps more specifically, what isn’t testing?
Typically, these conversations start with someone stating something that limits the bounds of testing in a way that I either don’t understand or don’t agree with. After twenty-plus years, my view has not shifted much. This article is not meant to be the universal truth. However, everything is based on what I have learned and experienced in a couple of decades working in the software development industry.
The definition and misinterpretation of software testing
If you look up the term software testing, you might get definitions that look something along these lines:
“Software testing is a way to assess the quality of the software and to reduce the risk of software failure in operation” – ISTQB Certified Tester Foundation Level
“Software testing is the process of evaluating and verifying that a software product or application does what it’s supposed to do” – IBM
“Software testing is the act of checking whether software satisfies expectations.” – Wikipedia
All of these can be interpreted very narrowly or broadly. In my experience, many people (especially those outside of testing communities) interpret it as running software, performing some type of task, and analyzing the results.
I believe that software testing is a lot more than that and that people interpret the traditional definitions more narrowly than the definitions intended.
The terms “shifting left,” and “test early, test often” have been around since Larry Smith first coined them in 2001. But we can go further than that. In his 1981 book Software Engineering Economics, Barry Boehm stated that finding bugs is exponentially cheaper the sooner we find them, with requirements being the starting point and operation (production) at the end.
Yet I still see testers being limited, and limiting themselves, to verifying and validating code once it has been written. Even though software development methods have seen testing as an important part of the whole development cycle since at least the 70s, we still seem to struggle to build that idea into our real life.
And while I argue the definitions never limited it, our development processes certainly have. From the Waterfall Model to the DevOps Loop, they all show testing as an isolated step even when they talk about it as an important aspect throughout the process.
Testing is part of the entire SDLC, but we don’t actually teach it
I studied software development at University — not engineering, but software development. I spent three years learning things like human-computer interaction, software development methodology, database design, and programming. I can’t recall a single course talking about tests or testing. It was assumed you took responsibility that your code worked, sure, but we didn’t talk about what that actually meant or explore how to do it.
When I got my first job as a developer, I was thrown into a small project group building a niche system for a particular customer segment. In that project, we had the following roles: developers. That was it. We had one person who acted as the liaison towards the customers, but we were expected to do everything: figure out requirements, design the system, build the whole stack from the database up to the graphical user interface, test, train our users, build the installation package, and then support and maintain the system in production.
I can’t say we knew how to do any of those things, but I do think it built a solid base for my respect for different parts of the development lifecycle and experts in any parts of it. To me: they are all connected, they all rely on each other, and they are not fully separate from each other.
…
This is a snippet of an article I wrote for Qase. Read the article here.
