Why do we need a QE at all?
This is a great question someone asked me this week. In terms of the context I was having an ideation session with my colleague on what topics to cover on a talk around Quality Engineering. They are well aware of the value QE brings. It was more coming from a place of explaining to others what it means.
I thought I would come up with some ideas to answer this question. If you have any input, I’d enjoy hearing from you in the comments or you can message me on LinkedIn.
Quality Engineering is an academic discipline
Quality Engineering is an academic discipline that requires training and on the job experience. There is sometimes a theme of ‘anyone can test’, which is true — anyone can test -
Can they test effectively?
Quality engineers bring in the techniques, approaches, tooling and quality mindset. I have observed lots of ‘testing’ that has gone on, but that has been ineffective due to no formal training or the approach/techniques/tooling/mindset is missing.
Courses I can think of — I can also recommend so many people to learn from in the community who are talking about their own learnings.
- MoT Software Quality Engineering Certificate | Ministry of Testing — This is a NEW training and is so exciting as it’s the first course I’ve ever seen focused on Quality Engineering
- Agile Testing Fellow | Training I haven’t done this one, but have heard good things about it.
- BCS training Software testing certification, BCS — ISTQB certified | BCS I have done the foundation and Intermediate certificates. There is a lot of foundational knowledge that you can build upon. I personally found this a game changer at the start of my career when I was at junior level and helped me move to more senior and made my own mind up about topics.
- BBST® By Cem Kaner — Black Box Software Testing Courses Online I’ve heard good things about these courses. I haven’t personally done these
Another thing you can look out for is whether people have learnt not via courses, but via other ways, such as attending conferences, books or blogs they’ve read.
There is a lot to think about and gaps are inevitable
There is a HUGE amount to think about when it comes to building products. Gaps are inevitable. If you have a person on a team that is observing and making an assessment of what’s going on, then gaps can be identified and resolved, rather than a gap snowballing into a major problem. An example could be thinking about testability and how easy the product is to test. Test automation as we go. Or thinking about what the user experiences.
Bias in testing your own homework
If I were to be building anything (like writing this blog post), I would want to be testing it. I often paste this into a document and do a spelling and grammar check for example. However, what’s missing here? It’s the bigger picture and whether the semantics of what I mean is being translated. I could feel that I have said what I meant, but then a second person reads it and does not understand or takes a different meaning from what I intended.
This is the psychology of human bias and testing your own homework. You are more likely to see your work more favorably.
There are absolutely techniques that you can use here — for example another developer can test another developers work.
The question would be what mindset are they approaching the testing. Is it simply from a coding perspective — or is it approaching it from a bigger picture, exploring risks and unknowns.
