How much do you agree with this statement?
To become a Quality Engineer, you must first become a software tester
- Agree
- Somewhat agree
- Somewhat disagree
- Disagree
0
voters
Bonus points for added community commentary
Software testing is a part of quality engineering, but quality engineering is a broader process that includes more than just testing. If you test your own code or someone else’s - at any level - you are software testing. It does not mean you have to have had the title “software tester”. We of course know that Quality Engineering is a strategic approach that includes activities like requirements gathering/discovery, risk storming, design sparring, development (which includes testing). Unsure how you would be able to become a Quality Engineer and skip the testing part of the skills and experience.
I’ve somewhat agreed with this as I feel testing fundamentals are an absolute must to be a quality engineer. That said I feel you can learn the fundamentals without everything else that a software tester needs to know.
Starting as a software tester can be helpful, but it’s not the only path to becoming a Quality Engineer. Diverse backgrounds, including development or DevOps, can also lead to this role, as long as there’s a strong focus on quality and process improvement.
As I have seen at most workplaces, quality engineers in the IT Industry do the same tasks that software testers do.
Titles like quality engineer hold more significance in industries like manufacturing, FMCG, etc. In the software industry even though many people hold titles like software tester, quality engineer, SDET, etc. at the end of the day they are testing software manually or automation or both and hence contributing to the quality of the product.
One reason is that there is a very rare chance that in an organization there will be quality engineers as well as software testers also. So if the organization has someone who holds the title of quality engineer there, then they have to primarily do the task of software testing. And so either you are a software tester or a quality engineer somewhere the words are different but the task done by you is same i.e. writing test cases, scripts , test the functionality manually ,etc.
This connection to testing seems to be problematic and we often end up if same role different title as a result. Seeing a lot of QA Engineers now who only do test activities and when they explain the difference its actually only very poor testing compared to slightly broader testing.
You can apply quality engineering to testing, it neither negates nor replaces good testing.
I’d sort of expect a quality engineer to impact all of development and not just testing, for example positively influencing the code review process, if it is only testing then it’s often closer to a software tester who is applying good quality engineering practices to their work.
You gotta love to find the bugs and show those bugs found. Thats the bread and butter for QA to exist. Now, QA engineer in by necessity fluffy. I’ve been one of 100’s of testers in mega telecom projects, and been the sole tester in small organizations. I’ve also had different managerial roles. You CAN become something in the test area without having done, and loved, finding bugs, but you will thrive if you know what’s done on the factory floor.
so, an “agree” from me
Quality Engineering is about reducing the number of bugs to be found. Software testing skills are useful because through them we understand bugs better. Quality engineering started with Taguchi. To be a quality engineer, we also need to understand the practices associated with Japan that enable companies to produce better quality products.
“Quality Engineering is about reducing the number of bugs to be found”
This is an interesting stance that can cause misunderstandings alongside a drift away from software development ideas and more towards software building ideas.
Consider mass production assembly lines, here QE will specifically focus on that statement and revolves almost entirely around the system of work often significantly reducing that need for QC and verification further down the line. Here everything is already known very well. Prevention is better than detection fits here.
Software development though is about research, learning, discovery, experiments, knowledge feedback loops as the product evolves/develops over time. Here there are unknowns and quality engineering can look at ways to bring thoughs unknowns into the light but they do not go away entirely.
So are we shifting towards software building where the QE is straight forward and testing is mainly about verification or are we still developing where QE is designed with unknowns in mind and testing is more about discovery, investigation and experimentation of risk. Detection here is continuous, its of really high value the the idea of prevention being better is a distraction, QE is less about that here.
I do not know if the shift to the more straight forward building is the right move or not but we are seeing a lot of language which to me at least infers that drift is believed to be happening.
I suspect Taguchi approaches can be used well with both build assembly line approach and also development prototyping approaches but differently, the same with QE and software.
Here is an interesting example of QE. The team found their exploratory testing appeared very ad-hoc, haphazard and not producing a lot of value in terms of what it found, they were not really applying good QE to this activity. So if you apply good QE to this activity, perhaps it shifts to say a session based testing approach, with risk charters, stucture and goals and this increases the bugs found. Here QE has been very specifically about increasing the number of bugs found.
Bottom line it is good QE practices in software development to create a system of work that caters well for unknowns, that accepts there will be bugs. There is no doubt about it if you are not applying good QE to the system of work you are going to have more bugs so yes good QE versus no QE will have a side effect of reduced bugs but you can also apply QE to the activities associated with learning and apply QE to things like testing and as a result become better at finding bugs.
Perhaps this is overthinking it a bit but that shift to build is happening with little consideration of what we are losing in the transition.
Yes, @andrewkelly2555 I agree with much of what you say. It is worth noting that Taguchi won the Deming Prize in 1960, and that Deming wrote that “more important.. figures .. are unknown and unknowable” (Out of the Crisis, 1986, page 344). Quality has always had to struggle with the unknown and unknowable.
The approaches from Japan, which include Taguchi, are widely influential in software development. An example of their influence would be DevOps, which is based on Deming’s philosophy. These approaches see engineering as being about learning.