Don't be afraid to delete automated checks. They may have been the right checks then, but what about now?
Regularly review them. Understand them. Know what them being green really means.
Has a check been superseded by any? Is that area of the system still heavily used?
Regularly review them. Understand them. Know what them being green really means.
Has a check been superseded by any? Is that area of the system still heavily used?
What value is it bringing?
If it failed, would anyone care?
Would it become a bug that goes into backlog Antarctica?
Do you know what the initial risk was?
Is that risk now mitigated by monitoring/observability?
How strong is that codified oracle? Could it be improved?
If it failed, would anyone care?
Would it become a bug that goes into backlog Antarctica?
Do you know what the initial risk was?
Is that risk now mitigated by monitoring/observability?
How strong is that codified oracle? Could it be improved?
Automated checks need refactoring just like code. As devs learn more about new tech and the system usage/design they improve.
How often are you doing that?
How are you keeping yourself upto date with system behaviour? When was the last time you did some testing?
How often are you doing that?
How are you keeping yourself upto date with system behaviour? When was the last time you did some testing?
Or are you stuck in a continuous maintenance cycle?Draining depressing cycles. You need that knowledge to create valuable automation.Don't take your eye of it.
A important distinction here is that you rarely 'fix' automated checks. What happens is you use alot of the existing
A important distinction here is that you rarely 'fix' automated checks. What happens is you use alot of the existing
check. You may alter the state, the algorithm, the steps, or change the codified oracle/assertion, or update libraries. Resulting in a new check. A lot of the time we gather this information while 'fixing', which tends to take longer IME. But that information is gathered by
exercising the system, by being in all those conversations. Coding/Automation skills are valuable, but being in those conversations, gathering that system knowledge, understanding those checks and the part they play in the testing approach is more valuable
It's those skills and those actions that allows decisions to be made by the team on green, or rules added I to pipelines. Without all those skills we end up in automated check hell, non deterministic checks, low confidence. No fun.
But as good testers, we should still remain skeptical of green, even if its just a few seconds of thinking when it goes green. But regularly review, adding, deleting, keeps it at a few seconds of thinking. Procidestbsg fast feedback teams need.
My turn to drive now :)
Time in the forest got my brain racing!
Time in the forest got my brain racing!
Providing***
