I want to hear, what is the most misunderstood part of your job?
To put it another way, what part of your job do you wish your colleagues, recruiters, and hiring managers would understand better?
Is there anything you’ve done to try to tackle the misconceptions and ignorance in others? Was it successful?
This week I introduced a new dev on our team to Quality Engineering, and how we handle Quality and Testing at Ada, and in our team. He had only worked previously with testers who were called “Automation QA” and “Manual QA”, and was surprised to hear that we have people in quality assurance roles there were not software testers, so we avoid using that word for testers (who we call Quality Engineers, arguably a role that is or isn’t Tester, depending who you ask).
Testing is not just about test cases, automation of test cases, and checking the acceptance criteria of the requirements.
How I tried to tackle this was to practice context-driven testing using SBTM, in a risk-based manner with exploration, experimentation, and questioning every time and everywhere.
Only got through to 3-4 senior-level devs/managers, out of maybe 20 that couldn’t care less or were annoyed by my inquisitions.
How it changed them was that they started to think like: what would Stefan ask or think of here(so they started asking themselves many questions), I can’t show this to Stefan before I check my work and I’m fairly confident about it(so they checked, rechecked, and tested their developed code more carefully)…
But it easily slips through this thinking mode and reverts back to whatever, once I’m gone.
It’s not exactly a direct answer to the question, but I’ve been doing software testing for about 1 year now and get an inkling that the rest of the Dev team see Testers mainly as glorified checkers/verifiers.
I wouldn’t blame them though, as I’d say that’s the fault of the approach from the test team I.e. lots of test cases and large focus on processes/procedures/documentation etc.
QA Engineer… just clicks buttons right? “Just finding bugs”
Of course, we can explain shift left, automation, … etc
If a bug is found in Production… WHY DIDN’T QA FIND IT?
By QA you mean the whole team right? Because QA is done by the team.
Anyone can be a tester
Sure, yes everyone can be a tester. But good testing requires a deep understanding of testing principles and how testing is done and the techniques very much differ from person to person.
You can only test at the end.
Obvious one to explain shift left.
When people ask " Is it bug free?" or “Is it completely tested?”
100% test coverage doesn’t exist
“Testing and Quality Assurance are the same thing right?”
Quality assurance involves processes, standards, and methodologies to ensure quality. Testing is a subset of QA, focusing on verifying software functionality through testing activities.
I would say: “Testing happens in the brain, not in the fingers or documents”
And I would say we are the most to blame for this, when, during reporting, we put the artifacts and tools in the forefront.
(Developers also suffer from this, but I think to a lesser degree.)
I think a byproduct of this is the expectation that the tester’s activities are predictable and straightforward, with no new problems: “Given a problem, look at the book for the solution, and implement like it is written”
It was raised in a retro that someone did not see the value in spending time testing the whole flow of a new feature thoroughly since we had already tested the individual parts of the system in depth as they were developed.
Of course it’s extremely important to perform full end to end testing of a new feature, as we would not find bugs affecting the interactions between parts of the system when doing component testing on the individual parts.
Challenging these judgements can be difficult as from the outset, this person doesn’t understand the difference in the testing which is occuring, and is probably assuming there is duplication of effort happening and that is why they are raising it, in an attempt to improve things. So it’s important to educate whilst keeping their potential assumptions in mind.
I also come up against the confusion as to wether a not a QE is a tester, so when asked I will advertise myself as a tester
I am part of a central QE team within a platform that stretches various applications systems, all with their own Dev’s/Testers and we are advertised as “Governance” and I think this word/role is regularly misunderstood
I get the impression teams think I’m there just to play boss, to review test documentation and apply the rules/processes - which is defo not something I’m into
Where as I see my role is much bigger, I wanna be able to help teams grow/develop, removes silos and create better transparency/collaboration across the teams, spot opportunities for new ways of working/tools, act as a point of escalation, help with test strategies and be an advocate for Quality practices
I don’t think this type of QE role is common, I think the role I do is more representative of a Test Manager, ya know kinda oversight across all the testing teams but I wanna be more than that!
