However much your team uses automation to support your testing, I’m betting the road to where you are now was hard fought, and full of myths to be busted and misconceptions getting in your way.
I’d also wadger, that job isn’t finished yet, and you’ve still got more blockers to adopting automation in a healthy way that fully supports human testing and development.
So, have at it, what are your war stories? What are the blockers that remain? Maybe by posting them here, we can realise we are not alone, and share tips on how to overcome the problems we face!
Misconceptions I’ve seen recently:
Unit tests with mocks all the things, fast is king only
Unit tests and TDD mean we reduce the need for other testing (partly true… at a stretch)
In writing it I realize that a lot of misconceptions crop up because the language around automation testing is so imprecise. Half of the reason why people can’t agree on when to write a unit test is because they can’t even agree upon what a unit test is.
Truth here, all the way! What a unit is, and how to test it, are so fundamental and yet lack so much agreement and clarity. I suspect I would get slightly different answers from each Dev I work with.
Automation test repository is a sacred land only QA are permitted no one else can’t contribute the test script
Test automation have to separated from dev repo
Use BDD and only believe that it make test automation write/maintain easier
Test automation = Every QA focus write every test every scenario in UI level
Look a bit deeper I think all four point kinda link into how people do collaborate, make the team more cross functional rather than work. on their own silos.
Or, related to the one by @theology:
Automated checks are supposed to catch many bugs. If not, then automation is not worth it.
As if regression finds many bugs in all but the worst of code bases, regardless of automated or not.