Apr 20, 2022
Education For Testers
There’re a lot of advice on the internet and LinkedIn about what testers should or shouldn’t learn. It typically ranges from ISTQB to concrete tools. I disagree with a lot of such advice and I’ll outline why in this article.
This will be a highly subjective and even biased article, so if you don’t like that, don’t go further :)
ISTQB
Let’s start with this one. I’ve done two of these exams — the foundation one and the agile one.
I’ve also been a tester for last 5 years and I have yet to find a situation where anything mentioned in the ISTQB would be actually useful to me.
My current opinion is ISTQB is that it’s overrated by many. And useless for many. I don’t find the advice in the syllabus particularly useful or well-worded.
One example from page 13 of the foundation syllabus:
Software testing is a way to assess the quality of the software and to reduce the risk of software failure in operation.
When I think about it now, I can agree about the assessment of quality. However, what do they mean by quality?
I don’t agree with the second part of the sentence. Reducing a risk is hardly what testing can do for you. As a tester, I share information about the product. That typically includes what problems there are with the product. But it doesn’t mean that anything will change with the product. That’s a decision typically made by more people — the project manager, devs, the whole team, etc. If we don’t act on the information I bring to the table, nothing will change, hence the risk will stay the same.
I can find more such example in the ISTQB syllabus, but let’s not go into it. Everyone can read it and make their own conclusions. That’s the point after all. I think it’s many times missed by testers who recommend this material. They simply recommend it because someone else told them to, or because they asked about ISTQB in some interview. But really, testing does not equal ISTQB.
On a more personal note, I’ve never been asked about ISTQB in any of my past interviews. I can’t say whether me having it had some positive (or negative) impact on the employer’s decision to hire me (or not), but we never talked about it once in my life.
What I was typically asked about was:
- concrete examples of my work
- test ideas about a particular thing (e.g. how would you test a login page?)
I think your approach to testing and your actual skills matter more in the end. If you think ISTQB helps you with that, go for it. But I have serious doubts.
Last but not least, I don’t agree with what some might say about that you need to go through some ISTQB seminar before the exam. The exam is simply not that difficult, so you can easily prepare on your own by reading the syllabus and researching things on the internet as you progress. I even think this is a better way because you learn to research things on your own, perhaps you learn how to use an advanced search in a search engine, or something else. You won’t learn any of this by sitting in a class listening to someone. Being an independent learner is also your goal. And this won’t happen by going to seminars.
Tools
Another broad area what I see recommended that testers should learn is tools. Usually some tools for automation.
I mean why not, tools are important. Every tester uses some tools so they should also know them enough to be able to achieve what they need with them in a timely manner.
On the other hand, there’s a danger of over-relying on tools. That can, in my opinion, typically happen to novice testers. If someone is starting in testing, or even starting with technology or IT, it can be very dangerous to learn one, or a few, particular tools. It gives you a false sense of understanding things when in fact you simply understand a few concrete tools.
An example: someone new to testing goes straight into Cypress. They skip learning JavaScript, they skip learning how different computational models work (client-server is one example), they skip learning about browsers and how browsers process web pages, they skip learning about browser DevTools. The result is they have some knowledge of Cypress but it stands on unstable foundation.
And it’s not only about tools. One has to learn how to think, how to experiment, how to take test notes, how to share information with others, and much more.
Unfortunately I’m also guilty of this. A year or so into my testing career, I tried to learn a lot of different tools. Then I hit the wall and realised that was not the way for me. I had to stop with all that, learn the basics, learn to think better, learn the principles first. And the result is I can fluently switch between various tools and I can learn new ones in a very short period of time — switching between Cypress, WDIO, Playwright, Puppeteer, Nighwatch.js, and what not takes me a few minutes because they are all more or less the same.
So now I don’t understand the questions in interviews that go like: “Do you know X tool?” I typically reply something along the lines: “I know JavaScript, this is yet another JS library, so I can likely use it very quickly.”
I’m probably not 100 % right on everything here. It’s simply my current view on things, I might change it later as I mature in testing.
What I recommend, however, is thinking for yourself, making your own conclusions, rather than relying on what someone says on the internet and then going straight to an ISTQB seminar.
