We frequently search testers for our agile Web Development teams. Therefore I sit very many times in job interviews, and very many times we have to reject the candidate. In this post I want to sum up the prerequisites for having a successful application talk in this domain. Hopefully this helps to give candidates a clearer view on what to expect and what is expected.
The world I describe here will of course not match to all companies. I am coming from a setup with agile development teams. In such teams you will find some specific characteristics. I name two crucial ones next.
Tools are as open as possible and accessible to all team members
The times where the tester in the team had a specific testing tool, which only the tester understood, are blessedly over. Such tools are usually heavy-weight, do not follow any established (coding) language, live in their own repository, etc. What you want is a tool that is light-weight (e.g. a framework for an already existing language), which lives in the same repository as the development code, etc. In our current setup I was confronted with such a heavy-weight tool called Tosca. So one of the major achievements was to migrate from Tosca to the wonderful open source Codeception test framework for PHP, a language which was heavily used already for the web development. So all team members had a common language from that point on.
The gap between a developer and a tester is as small as possible
When using a tool which is code-based it implies that the tester can code in that language. I am coming to that point in more detail below. In general, the tester must also understand code, and the developer must also understand testing. Having a tool based on a common coding language, no one can give excuses anymore like “I do not know that testing tool”. And please do not come up with that weird argument that a developer does not have that mystical “tester-mindset”. A developer who can only think in happy cases is simply a bad developer.
Having this said, here are the most important prerequisites when applying for a tester position in an agile web development team:
A tester must also be a decent coder (not a developer)
It is not enough to have had a foundation course on Java five years ago. You need to be fluent in the language type of the test tool (usually some OO language). You do not need to be already fluent in PHP when there will be a PHP-based tool at the new job, but you need to be fluent in some OO language. Fluent does not mean that you are a developer. But you must be able to code small programs using all common OO techniques. You can read code, and you know where to find answers to coding problems. You know how to debug a program, and you are not scared to deep-dive into a complex coding issue. You really like code. If you do not like code, you will never be a good tester.
A web tester must understand (not master) all basic web technologies
It is really annoying when someone sits in a job interview for a web tester position, and we show some web page, and then the candidate does not even know the basic constituents of a web page. You really must know how to inspect a web page element. You must really understand the basic web-related technologies, like:
- Responsive Design
Again, you do not need to be a developer and master these topics. But you must know how they work. So it may be sufficient to do one of the countless online web developer courses out there. You will probably know enough to be a very good web tester afterwards, even if you are still far away from already being a full stack web developer. And you do not need to be.
I would have really liked if people were aware of this before applying for the job. Then they know how to prepare, and when it is realistic to get the job. I hope that more people stop aiming at this ancient ISTQB-defined tester role, where a tester does not touch code. You still need to know your testing techniques, of course, so the ISTQB stuff is still valid. But you also need to like code and web technologies. And that makes you as valuable as any other role in the agile team.