Test Automation: Bruises, Not Scars
Nov 19, 2024
Sappo
I was recently chatting about good QA practices and noticed I quoted a seemingly unrelated book.
The book was Jonathan Haidt's The Anxious Generation. You might be surprised if you've read it. If you haven't read it, consider checking it out. The broad strokes of the book cover themes of mental health, technology, play, and responsibility affecting today's young.
You might ask, "What does this have to do with good QA practices?". Well, not much on the face of it. But after noticing that I'd referenced it twice, I've realized how useful some of the terms in the book are. I'll cover just one in here: bruises, not scars.
The book introduced me to "bruises, not scars". The idea - with children - is that you're not trying to avoid all injuries, just the larger ones that would cause more significant damage or leave a permanent mark. In fact, the smaller ones, the bruises, help children learn to be more careful and become more responsible. These skills, in turn, also help to avoid scars.
Bringing this back to quality assurance, we use the "Breath before depth" mantra when taking on new consultancy work. For our clients, this means they'll get wide coverage with a light touch very quickly before going deeper on areas identified as most worthy. This is different from the common AC or in-sprint approach, where the items in play (regardless of their overall priority) get automation tests.
The in-sprint approach means you're trying to avoid minor bruises while leaving yourself open to several inches of stitches.
We should stop being fearful of bruises. Bruises are ok; sometimes, they can even be good. They may highlight gaps in your processes, which could lead to scars and force us to become more responsible. But most importantly, the goal of protecting against all bruises is exceptionally expensive.
Of course, we want the highest quality standard possible, but time costs must be balanced with potential adverse effects. I have seen teams automating an accordion showcasing the comprising materials of a product. This is fine until you understand there wasn't a single test covering email delivery or function. Nor were very common purchasing options covered.
The engineering team gets a valuable lesson if a defect is discovered with the new accordion. They might find the developers and UAT both missed something; maybe this has been overlooked before, and adding a default AC to a template is a good idea that could avoid more bruises and even scars in the future.
It's hard to imagine a "higher-up" losing their cool over something like this, but it's even harder to imagine them being consoled by the knowledge of the accordion tests when payments or emails go down.
Test automation has a bit of bad taste to many "higher-ups" we talk to. We hear automation is too slow, too expensive, and frankly, a waste of time. We hear companies have unit tests, integration tests, contract tests, component tests, API tests, and everything else...
... but they don't have any confidence.
It's common by the point we're talking to them that they have already invested hundreds of thousands into migrating into Cypress from something that wasn't working now hear, "Cypress has limitations, we should migrate to Playwright".
Please take this away; you must factor in your stakeholders, your "higher-ups", and how they see test automation. If you protect them against 20 bruises, they won't have a clue; if they end up getting minor bruises from a lack of coverage, they probably won't even notice it. But you must have good coverage in critical business areas and protect them (and, by extension, yourself) from scars!
If it helps, share this in your next retro and start a conversation on how best to increase confidence by focusing on what matters.
Reach out if you would like assistance adding critical coverage asap. We can help with short-term solutions while you build your capabilities or as a migration.
I was recently chatting about good QA practices and noticed I quoted a seemingly unrelated book.
The book was Jonathan Haidt's The Anxious Generation. You might be surprised if you've read it. If you haven't read it, consider checking it out. The broad strokes of the book cover themes of mental health, technology, play, and responsibility affecting today's young.
You might ask, "What does this have to do with good QA practices?". Well, not much on the face of it. But after noticing that I'd referenced it twice, I've realized how useful some of the terms in the book are. I'll cover just one in here: bruises, not scars.
The book introduced me to "bruises, not scars". The idea - with children - is that you're not trying to avoid all injuries, just the larger ones that would cause more significant damage or leave a permanent mark. In fact, the smaller ones, the bruises, help children learn to be more careful and become more responsible. These skills, in turn, also help to avoid scars.
Bringing this back to quality assurance, we use the "Breath before depth" mantra when taking on new consultancy work. For our clients, this means they'll get wide coverage with a light touch very quickly before going deeper on areas identified as most worthy. This is different from the common AC or in-sprint approach, where the items in play (regardless of their overall priority) get automation tests.
The in-sprint approach means you're trying to avoid minor bruises while leaving yourself open to several inches of stitches.
We should stop being fearful of bruises. Bruises are ok; sometimes, they can even be good. They may highlight gaps in your processes, which could lead to scars and force us to become more responsible. But most importantly, the goal of protecting against all bruises is exceptionally expensive.
Of course, we want the highest quality standard possible, but time costs must be balanced with potential adverse effects. I have seen teams automating an accordion showcasing the comprising materials of a product. This is fine until you understand there wasn't a single test covering email delivery or function. Nor were very common purchasing options covered.
The engineering team gets a valuable lesson if a defect is discovered with the new accordion. They might find the developers and UAT both missed something; maybe this has been overlooked before, and adding a default AC to a template is a good idea that could avoid more bruises and even scars in the future.
It's hard to imagine a "higher-up" losing their cool over something like this, but it's even harder to imagine them being consoled by the knowledge of the accordion tests when payments or emails go down.
Test automation has a bit of bad taste to many "higher-ups" we talk to. We hear automation is too slow, too expensive, and frankly, a waste of time. We hear companies have unit tests, integration tests, contract tests, component tests, API tests, and everything else...
... but they don't have any confidence.
It's common by the point we're talking to them that they have already invested hundreds of thousands into migrating into Cypress from something that wasn't working now hear, "Cypress has limitations, we should migrate to Playwright".
Please take this away; you must factor in your stakeholders, your "higher-ups", and how they see test automation. If you protect them against 20 bruises, they won't have a clue; if they end up getting minor bruises from a lack of coverage, they probably won't even notice it. But you must have good coverage in critical business areas and protect them (and, by extension, yourself) from scars!
If it helps, share this in your next retro and start a conversation on how best to increase confidence by focusing on what matters.
Reach out if you would like assistance adding critical coverage asap. We can help with short-term solutions while you build your capabilities or as a migration.
I was recently chatting about good QA practices and noticed I quoted a seemingly unrelated book.
The book was Jonathan Haidt's The Anxious Generation. You might be surprised if you've read it. If you haven't read it, consider checking it out. The broad strokes of the book cover themes of mental health, technology, play, and responsibility affecting today's young.
You might ask, "What does this have to do with good QA practices?". Well, not much on the face of it. But after noticing that I'd referenced it twice, I've realized how useful some of the terms in the book are. I'll cover just one in here: bruises, not scars.
The book introduced me to "bruises, not scars". The idea - with children - is that you're not trying to avoid all injuries, just the larger ones that would cause more significant damage or leave a permanent mark. In fact, the smaller ones, the bruises, help children learn to be more careful and become more responsible. These skills, in turn, also help to avoid scars.
Bringing this back to quality assurance, we use the "Breath before depth" mantra when taking on new consultancy work. For our clients, this means they'll get wide coverage with a light touch very quickly before going deeper on areas identified as most worthy. This is different from the common AC or in-sprint approach, where the items in play (regardless of their overall priority) get automation tests.
The in-sprint approach means you're trying to avoid minor bruises while leaving yourself open to several inches of stitches.
We should stop being fearful of bruises. Bruises are ok; sometimes, they can even be good. They may highlight gaps in your processes, which could lead to scars and force us to become more responsible. But most importantly, the goal of protecting against all bruises is exceptionally expensive.
Of course, we want the highest quality standard possible, but time costs must be balanced with potential adverse effects. I have seen teams automating an accordion showcasing the comprising materials of a product. This is fine until you understand there wasn't a single test covering email delivery or function. Nor were very common purchasing options covered.
The engineering team gets a valuable lesson if a defect is discovered with the new accordion. They might find the developers and UAT both missed something; maybe this has been overlooked before, and adding a default AC to a template is a good idea that could avoid more bruises and even scars in the future.
It's hard to imagine a "higher-up" losing their cool over something like this, but it's even harder to imagine them being consoled by the knowledge of the accordion tests when payments or emails go down.
Test automation has a bit of bad taste to many "higher-ups" we talk to. We hear automation is too slow, too expensive, and frankly, a waste of time. We hear companies have unit tests, integration tests, contract tests, component tests, API tests, and everything else...
... but they don't have any confidence.
It's common by the point we're talking to them that they have already invested hundreds of thousands into migrating into Cypress from something that wasn't working now hear, "Cypress has limitations, we should migrate to Playwright".
Please take this away; you must factor in your stakeholders, your "higher-ups", and how they see test automation. If you protect them against 20 bruises, they won't have a clue; if they end up getting minor bruises from a lack of coverage, they probably won't even notice it. But you must have good coverage in critical business areas and protect them (and, by extension, yourself) from scars!
If it helps, share this in your next retro and start a conversation on how best to increase confidence by focusing on what matters.
Reach out if you would like assistance adding critical coverage asap. We can help with short-term solutions while you build your capabilities or as a migration.
