“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare
The above quote had been sent around recently and it hit chord in me. I have started to look at everything with this quote in mind which brings me very swiftly to testing roles.
The list below is what I managed to find in a 15 minute search for roles online:
- Test Analyst
- Test Engineer
- Test Manager
- Quality assurance (QA) analyst
- Agile test analyst
- Automation test analyst
- Test specialist
- Manual test analyst
- Functional tester
- QA engineer
- QA Lead
- Performance tester
- Non-functional tester
- User acceptance tester
- Programme test manager
- Software Design Engineer in Test (SDET)
- Developer in Test (DIT)
- Test Architect
No doubt I have missed some but if we start to add in levels such as Junior, core, senior and consultant. Also consider specialisms in regards to industry i.e. manufacturing, avionics, finance, etc. it starts to get a bit ridiculous.
It really shouldn’t be this difficult.
As a test community we have been driving for our place within projects as we’ve often been the first to be cut and i’m still having to explain what we do in some instances. With this level of role confusion I can’t blame non testers for being a little frustrated.
If you hire a developer or a project manager their roles are a expected to cover the length and breadth of a project. Yet testers are split into various bands. If you consider developer roles everyone has an expectation that they should be able cover everything along the software engineering spectrum.
In my opinion there are two clear paths for testers and maybe the image below is an oversimplification but we all need to start somewhere.
Technically Focused Testers
With Developers In Test (DIT), Software Development Engineers in Test (SDETs) and TDD help increase the levels of automation we are seeing a strong drive across businesses for technical skills in testing.
So while QA engineers, SDETs and DITs target technical efficiency, it creates a new gap.
User Focused Testers
It may be argued here that this would be a ‘traditional tester’ (whatever that may deemed to be). There is however a clear need to keep the focus on the user, putting yourself in their shoes, working with the business to ensure the technical side doesn’t forget who it is delivering its product to.
With automation taking away the mundanity of repetetive tasks it allows people to focus on Exploratory Testing. For those who have had the pleasure of running in an delivery environment that promotes exploratory testing, you will find it difficult to go back to scripts.
Let’s not forget that UAT still stands and user focussed testers should be working with staff in regards to handovers, training and potentially early support.
Planning and ‘The Blend’
Whether it’s Agile methodologies or traditional sequential delivery we still need to plan! All testers whatever their role need to be involved to help keep quality a focus, drive the necessary plans and outputs.
Skills need to be transferable and both camps should be learning new skills from each other. A user focussed tester as an example should understand HTTP/API’s and technical focussed testers should spend time within a UAT phase to learn more about their users.
Keeping it simple….
This is a very simplistic way of looking things and yes there are many avenues that could be discussed. But, keep the quote in mind…… It is only as difficult as we choose to make it.
There are two other blog posts worth reading by James Bach that helped drive this particular post: