In this post I explain the definition of Software Testing, what it is, what is isn't and then attempt to define what Software Testing is in my own words. "So, What is Software Testing?" Initially, in the early stages of my career, the answer to this question was not something I really thought about much. When I was studying for the ISTQB exam, I had no previous information or understanding on what Software Testing is and during the course we were given a high level, some-what technical definition in our course materials and at the time, the definition was gospel for me. It goes:
"The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations" (ISTQB Glossary, 2010 - the glossary has been updated since, here)
In short, testing detects, measures and improves software quality which is achieved via various processes and testing techniques/approaches.
I now knew what Testing was! Were anyone to ask me, I'd repeat the above, often sounding like a robotic parrot whilst doing so! I only started to really think about this when I started my first role as a Tester. The Project Manager would approach me and literally say, just do what you can to try to break the application. So my work environment started to shape my approach to testing. I'd now try to break applications. Data injections, load testing techniques and doing things that end users will never do. No doubt I had broken many applications working under this manager but I quickly realised, I was finding things on the applications that didn't necessarily work as they should BUT the system was not 'broken' by it. As an end user, am I most likely to get frustrated when I run a HUGE unrealistic query that doesn't return results OR when my surname is entered in a field on a sign up form, but doesn't carry over to my profile?
Examples like these, show that Testers are not there to just break things. Had I only tried to break the application, I may have never raised those fundamental issues in relation to the end users' needs/expectations.
Following this, I worked on another project which was the complete opposite. This time, the product met the specified requirements however, those requirements defined by the customer were FAR from quality, in fact they were poor. Detailed, yes, but the overall application they required, down to the appearance and functionality was quite bad and dated. How do I, as a Tester add to the overall quality of software? After all, this was one of the modules we had spent so much time on during the course. I'd scrutinise requirements and point out the potential issues but I would get the simple response 'It's what the client wants'. Other managers that I would come to work with later would encourage the feedback and relay this to the customer who would often agree and the documentation would then be updated retrospectively but before then, here I saw myself in another interesting situation, a Tester testing a piece of software with what are essentially, accepted faults in the application.
So we have two examples where I had to focus on two different spectrums of the Testing process. The first, I was told just try to break the application, which then dictated my testing approach, and the second example showed that Testing was overlooked in during the requirements stage.
I mention these examples because I found that, though the definition of 'software testing' has the 'official ISTQB glossary' definition, over time my understanding of software testing through the various projects and teams I've worked with has shaped the definition to me personally. I say that to say, I have attempted to define Software Testing in my own words below, and I hope this helps you, the readers, in your roles/journeys as Testers:
Software Testing is the process of utilising an application, verifying it meets customer requirements by executing checks on what IS SEEN* and NOT SEEN** on the application under test.
*IS SEEN:
- Front end functionality
- Front end design
- User Interface
- User Experience
**NOT SEEN:
- Requirements documentation
- Back end/Server side
- Back end/Databases
- Back end/Source code
So, there you go. That's my definition of Software Testing which is SUBJECT TO CHANGE! I hope though, it still conveys that testing doesn't just begin once the application has been developed and it doesn't just mean you click buttons and try to break things.
Thank you for reading! What do you think Software Testing is/isn't?
All the best!
J Vickery
