The Full Stack Tester

I am a generalist. I am tech affine. And I am a perfectionist. A couple of years ago, I decided to take a full-time employment as a software tester. The key reason being, that I have a good starting point to take on that responsibility and it could be fun. And fun I had. Oh boy!

Expectations for a tester

In the years to come I have seen and used a wide variety of terms for what I do. Job offers, job contracts and business cards said something along these lines:

• Quality Assurance Manager
• Quality Assurance Tester
• Quality Assurance Specialist (truly, those guys/girls are “special”… 😂)
• Test Engineer
• Software Tester
• QA

I tried to discuss the topic of naming and responsibilities with many factions, including testing colleagues, developer colleagues, head of development, HR and tester friends — but people try to avoid this topic. I guess it is because they don’t see any difference in it or something to be gained from good terminology. Regarding the responsibility, it is also fuzzy. At my current job I directly asked the whole development team what they expect as a result from hiring a tester. The only answers I got was “to find more bugs with better descriptions” and “to improve the quality of our digital products”. Well, these are like the super low level and the super high level of a responsibility description — but a vast empty space in between.

The discussion about naming for tester responsibilities would make a different blogpost. What I want to focus on in this post are the responsibilities and skills: The one good thing about the fuzziness in testing related job descriptions is, that testers are free to define the scope of responsibilities for what they do around a core responsibility that is implicitly expected by the software development staff.

Levels of functional testing

Development of digital products is mainly driven by software development. Every development project starts with software developers. Then come the system administrators, either dedicated hardware or cloud services. Only later designers are hired, then come the product people, at latest if at all some testing guys. Almost never copywriters and security experts.

Similarly the testing need is perceived: First comes code quality and code styleguides, then unit tests. By now most developers are already responsible for that on their own. The next steps are feature tests, integration tests and regression test setups — something that developers prefer to hand over to somebody fully responsible for.

This point of time is mainly where companies start to hire testers. The idea is, if I hire a tester for a lower wage than a developer, he can do this stuff for the developer and the developer has more time to focus on implementing functionality instead of testing it. So, a tester is considered foremost a test engineer who does the dirty work implementing and executing automated checks — with a fallback to manual checks if progress on automation is lagging behind. Why this line of thinking is absolutely wrong on many levels would be several more great topics for blog posts, but let’s focus on the tester perspective for now.

Beyond functional testing

In a recent twitter discussion I stated the following:

Testers aren’t judged by the progress of quality of the digital product, instead they are judged by the amount of bug issues they produce.

This bug found count metric fits very well with the job description of being a clean up guy for the software development staff. But this is all based on an outdated idea of how software development works: A waterfallish process measured in KPIs, where you can add and subtract process steps and thus improve the result of the whole process chain.

We live in the year 2015, agile methodologies have been around for quite some time, many companies have understood by now, that a product is a holistic thing. And the only KPI that matters is the user experience it generates. You can’t hire people to add something on top of an existing product, and you can’t add stuff sequentially. Security, graphic design, wording, functionality, service design, privacy, internationalisation, UI design, accessibility, localisation, sound design, etc. — these are all integral parts of a product and have to be considered right from the beginning — even if only with mock placeholders for a later addition.

So let’s not limit the role of testers to software testers, but embrace the opportunities of being a product tester. This is not to be confused with user tests — a product tester is responsible for helping the product development team to create products with better quality, to check the quality of a product on all levels, for reporting on the results of those checks — for the sake of creating a hassle-free product experience for the users. And with product development team are meant all who contribute to the end result.

The full stack tester

The full stack tester is in the team right from the start, where in the first steps the strategy of a new product is discussed. He advises on pitfalls and estimates, as quality is one of the four components of every project that need to be roughly estimated: scope, time, budget, quality. He helps creating a customer journey map and how the product fits with the service design. He discusses product scope and feature sets. He advises on product strategies regarding privacy and security. He reviews UI and graphic design suggestions. He helps to find a consistent wording style, he informs about the challenges of internationalisation and localisation, and he both warns about UX pitfalls and suggests UX wins.

And he checks — aaaaaall the things.

The natural enemy of a full stack tester is Murphy and his infamous Law — someone truly dedicated to help the team produce great products doesn’t want everything that can go wrong to actually go wrong — this is exactly what he tries to prevent.

This is the big contrast to a test engineer that is measured by how many issues he can find before stuff is released to production. Such a test engineer loves Murphy and things going wrong. The more things go wrong, the more he can find. The more difficult the errors are to find, the more credit he gets when he discovers them. And the more messed up the product development process is, the more work and importance he gets. And his personal risks are quite low — either the bugs he doesn’t find aren’t visible in production. And those that are found, well they were implemented by someone else that can be blamed. And you can’t find everything — especially if noone knows how large “everything” is. And it wasn’t really that bad, right? Well, except for that one weird user, but his strange setup is not really supported, is it?

Priorities

What is the conclusion of this post? A full stack tester should get his priorities straight:

• Prevention > Finding
• Advising > Criticising
• Draft checks > Result checks
• Early on > Later on
• Perfection > Good enough

And he should not limit himself to functionality with regard to some specifications. A product has so much more aspects than functionality, and there are much more facets to every aspect than what is specified.

Leave your comfort zone! Discover new areas! Become an expert of understanding everything! And help your team to grow! Digital products are a magical world — go exploring! And have fun 😄🐞

Author : Andreas Beer