Fantastic read! At my ex-employer, we did switch from a siloed role to being a quality team that leads testing initiatives. There is, perhaps, scope to go even further. When product teams are mature enough, they can handle, and sustain test coverage / test suites even without an embedded quality specialist on the team. The quality engineers can instead steward the processes and build the test infrastructure necessary for product teams to serve themselves. Is that a fair perspective?
Thanks for sharing, Alessandra. I completely agree with having an automation goal before starting - so many teams miss this and assume everyone is expecting the same outcomes with automation.
I particularly liked what you should cover during whole team discussions: Layers of testing, critical paths, and priorities all help build that joint understanding of what will and will not be covered and how it helps the team achieve their goal, too.
Excellent article! Very few team at my company follow this process. Most of them are working in silo... so sad to see a team so proud of their 25k automated test missing critical issues found in pre-prod and sometime in prod because they don't know what are there critical user journey. I think I'll write an article on the subject in our next internal R&D newsletter and point to your article as a reference, if you don't mind.
Hi Andre, it is sad to see the focus on vanity metrics like the number of test cases, and not on the metrics that really matter, like escaped bugs. And of course, feel free to use this article as a reference wherever helpful.
Great read Champion. Would love to work with you again one day , especially if Australia ( Australian based company) can draw you back to our beautiful shores.
Fantastic read! At my ex-employer, we did switch from a siloed role to being a quality team that leads testing initiatives. There is, perhaps, scope to go even further. When product teams are mature enough, they can handle, and sustain test coverage / test suites even without an embedded quality specialist on the team. The quality engineers can instead steward the processes and build the test infrastructure necessary for product teams to serve themselves. Is that a fair perspective?
Thanks for sharing, Alessandra. I completely agree with having an automation goal before starting - so many teams miss this and assume everyone is expecting the same outcomes with automation.
I particularly liked what you should cover during whole team discussions: Layers of testing, critical paths, and priorities all help build that joint understanding of what will and will not be covered and how it helps the team achieve their goal, too.
Looking forward to hearing more from you
Excellent article! Very few team at my company follow this process. Most of them are working in silo... so sad to see a team so proud of their 25k automated test missing critical issues found in pre-prod and sometime in prod because they don't know what are there critical user journey. I think I'll write an article on the subject in our next internal R&D newsletter and point to your article as a reference, if you don't mind.
Hi Andre, it is sad to see the focus on vanity metrics like the number of test cases, and not on the metrics that really matter, like escaped bugs. And of course, feel free to use this article as a reference wherever helpful.
Great read Champion. Would love to work with you again one day , especially if Australia ( Australian based company) can draw you back to our beautiful shores.