There is a lot of talk at the moment about whether development teams need a dedicated tester.
The argument goes roughly like this - "the whole team tests, we utilise TDD (Test Driven Development), we have unit tests, integration tests, peer review and code quality checks, developers test their own work and we have front end automation tests, we don't need a dedicated tester".
This viewpoint, or something similar, has existed for a long time and WebDepend exists to challenge this outlook and reiterate that some form of dedicated testing is needed for practically all software development teams.
More recently, with the increasing capabilities and adoption of AI, the volume has been turned up on the argument that dedicated testing is no longer needed. The term 'manual testing' is generally used but mostly what people mean is simply 'testing'.
As with automation testing, I would not expect AI to be able to effectively and fully test a website, web application or mobile app any time soon. There still needs to be a dedicated tester focused on testing, learning the whole application, asking the 'what if...' questions, discussing and prioritising findings with the team.
Stepping back from arguments around whether dedicated testing is needed or not and whether AI can do all the testing for the moment, the aspect that I wanted to highlight is around the mindset of the person or people tasked with doing some form of testing.
For me, mindset is fundamental for effective testing and in finding a lot of bugs. When a person is dedicated to testing, their mindset shifts to asking questions of the product or feature being tested, the tester is challenging the product to not only demonstrate that it can work in certain situations but that it can work across all realistic and even unrealistic but still possible scenarios and combinations.
To do this level of testing requires, in my view, a tester's mindset.
Consider a developer or engineer mindset:
A developer mindset is related to building the feature, thinking about how that feature integrates with the existing codebase and coding it correctly (semantically, reusable, performant, secure, to coding standards, etc.). The testing part of that is usually writing some unit tests, maybe demoing it to the product manager and perhaps running through the feature a few times looking for bugs.
This mindset is good for building features but it is only carrying out very rudimentary testing.
A testers mindset goes far beyond this to ask more questions of the feature being tested. Not just the broad 'are all the requirements met' type testing or the happy path scenarios but also going further to explore the feature, consider all the potential scenarios and use cases, understand what circumstances might lead to problems and raise the issues in ways that can be understood by developers so they can be prioritised and fixed.
A tester is not only trying to find problems and bugs but also discover gaps in requirements, unexpected situations that become apparent when exploring a feature more fully or identify UI that is different to understand or may pose a problem. This is possible with a tester's mindset - focused on thinking about testing, finding issues, working out how problems might occur and how users might get into a less than ideal state.
On the whole, developers and software engineers do not have the time for this level of testing, the inclination or even the motivation, they would prefer to build things and not get caught up in finding problems with things they have already built. This is not levelling any criticism at developers at all, if I was a developer I would want to build things as well and not spend my time trying to test.
Very occasionally, I see or work with a developer that is able to switch their mindset from building to testing. This type of developer is adept at testing and possibly even enjoys it to a degree. However, I've worked with hundreds of developers and only seen this type of developer a handful of times.
In my experience, adopting a tester's mindset is what uncovers many more issues and, in the majority of cases, only happens when there is a person dedicated to testing on the team.
Photo by Austin Distel on Unsplash
