I was lucky enough to have experienced these things first hand. Thoughtworks taught developers how to test their code, and delete their test code when it no longer served a purpose. I still think their developer training is some of the best I've ever seen a company put together. It's also what made them incredibly fast at building things.
You might or might not be surprised how much businesses will pay for folks like Thoughtworks to come in and build something, and also train the developers around them to build in a similar way, only for it to fall apart because management or the whole huge "QA" department pushes back on developers owning all the functional code. Then when times get lean, they can those QA folks and devs are left to figure out test code they didn't write and is often in a language they aren't using.
What's left behind is a little footprint of clean code that everyone can read and maintain, but can't remember how it was created and why it was so good. (Two major things were involved - unit tests, pair programming).
Still baffles me that companies don't require developers to know how to create unit tests, not even for TDD, but just unit tests period. You can almost predict the companies that wrote software that skipped this vital scaffolding will have it all come crashing down in five to ten years under the weight of technical debt they can't keep up with. (I've personally seen this happen three times.)
The last time I created any UI automation, it was 2018, for a company creating software that had no unit tests and no longer exists. I wonder how many other folks that work around test automation have seen this happen or even made the connection. Could be coincidence, but given data from Accelerate, it looks like correlation to me.
>Because my post is about testing, I expect a bunch of testers will tell me I’m wrong
Probably, but I'd step back and ask how many of them have had the experience you've had where you get to see, first hand, the benefits of the points listed out in "The Future State of Test Automation" and the direct benefits to your career growth by being freed up to focus on better things.
The first time I heard that first point "devs should be writing most of the tests," was about 14 years ago. I didn't buy into it, since I knew how to write all those special selenium selectors and I was feeling pretty good about what I knew, until I witnessed (with shock) first hand the rest of those points listed there used to successfully release new products time and time again. Was everything perfect? No. Did I change my mind and find better things to do to add value to what I learned? Yes.
This culture shift comes from the top. If the majority of the testers in 2024 are still measured and paid by how many test cases they can write or how much a dev likes them for making sure that the tester has UI automation to ensure their home page renders with 3 images that they can't even verify on their own local build (I have stories), then nothing is going to change.
----
At all these many expensive test conferences that they have through the year are there any work shops that bring dev and sdets together to work on a problem and solve it in two different ways? Traditional waterfallish vs Agile where in the latter the devs are writing the tests withe tester as a guide. Maybe they can get their own insights and start from there?
I'm also tired of the "A" word, but possibly for a different reason. "A"utomation is one of those words like "A"gile or "A"rtificial that have been so overused and misused that we can't help but hate them.
My experience as a tester taught me that what I called automation was essential. Some of the test challenges I faced involved a large state space that needed to be explored. Things like the set of programs that will run on a computer, or the set of interactions among different network flow control algorithms that share a given resource. To test, you need a model of what is correct and incorrect behavior and a way to apply that model to large combinations of parameters. Automation is clearly required to ensure tests cover the state space well.
It's also essential in checking results when you include the implied expected result "and nothing else unexpected happens."
I love this post for so many reasons, but i specifically wanted to say that i got a great chuckle out of this line :
> (and you probably would have also found the tab layout bug that the “test automator” worked around).
I was lucky enough to have experienced these things first hand. Thoughtworks taught developers how to test their code, and delete their test code when it no longer served a purpose. I still think their developer training is some of the best I've ever seen a company put together. It's also what made them incredibly fast at building things.
You might or might not be surprised how much businesses will pay for folks like Thoughtworks to come in and build something, and also train the developers around them to build in a similar way, only for it to fall apart because management or the whole huge "QA" department pushes back on developers owning all the functional code. Then when times get lean, they can those QA folks and devs are left to figure out test code they didn't write and is often in a language they aren't using.
What's left behind is a little footprint of clean code that everyone can read and maintain, but can't remember how it was created and why it was so good. (Two major things were involved - unit tests, pair programming).
Still baffles me that companies don't require developers to know how to create unit tests, not even for TDD, but just unit tests period. You can almost predict the companies that wrote software that skipped this vital scaffolding will have it all come crashing down in five to ten years under the weight of technical debt they can't keep up with. (I've personally seen this happen three times.)
The last time I created any UI automation, it was 2018, for a company creating software that had no unit tests and no longer exists. I wonder how many other folks that work around test automation have seen this happen or even made the connection. Could be coincidence, but given data from Accelerate, it looks like correlation to me.
>Because my post is about testing, I expect a bunch of testers will tell me I’m wrong
Probably, but I'd step back and ask how many of them have had the experience you've had where you get to see, first hand, the benefits of the points listed out in "The Future State of Test Automation" and the direct benefits to your career growth by being freed up to focus on better things.
The first time I heard that first point "devs should be writing most of the tests," was about 14 years ago. I didn't buy into it, since I knew how to write all those special selenium selectors and I was feeling pretty good about what I knew, until I witnessed (with shock) first hand the rest of those points listed there used to successfully release new products time and time again. Was everything perfect? No. Did I change my mind and find better things to do to add value to what I learned? Yes.
This culture shift comes from the top. If the majority of the testers in 2024 are still measured and paid by how many test cases they can write or how much a dev likes them for making sure that the tester has UI automation to ensure their home page renders with 3 images that they can't even verify on their own local build (I have stories), then nothing is going to change.
----
At all these many expensive test conferences that they have through the year are there any work shops that bring dev and sdets together to work on a problem and solve it in two different ways? Traditional waterfallish vs Agile where in the latter the devs are writing the tests withe tester as a guide. Maybe they can get their own insights and start from there?
---
Can I have a penny?
In your experience, what would have prevented you from working with a developer so that they could build the tests you described?
Maybe the developers time is more valued when they are writing code? Like 10x dev?
Maybe culture. It just the way its always been.
Maybe the org needs QA as a scapegoat when things go wrong, while talking up quality belongs to everyone?
I'm also tired of the "A" word, but possibly for a different reason. "A"utomation is one of those words like "A"gile or "A"rtificial that have been so overused and misused that we can't help but hate them.
My experience as a tester taught me that what I called automation was essential. Some of the test challenges I faced involved a large state space that needed to be explored. Things like the set of programs that will run on a computer, or the set of interactions among different network flow control algorithms that share a given resource. To test, you need a model of what is correct and incorrect behavior and a way to apply that model to large combinations of parameters. Automation is clearly required to ensure tests cover the state space well.
It's also essential in checking results when you include the implied expected result "and nothing else unexpected happens."