One of the most significant issues I often see in automation is lack of goals.
Team do automation write lots and lots of tests. But they will never consider if their test or automation is coming closer to their goal.
Brent from AB Testing podcast likes to say „Customer don’t buy software they buy the solution to their problem”.
I like to think the same thing goes for automation we shouldn’t buy „just automation” what we want to buy/make is the solution to our problem.
I am going to steal and repurpose another quote from AB testing, and I will say: Thay your overarching goal of automation should be „Accelerate the Achievement of Shippable Quality.”
But this is a vague high-level goal for each solution/automation project you want to have a more detailed goal. And then when you are writing each and every test, you should ask yourself: „Is this helping me to achieve our goals”?
You would be surprised how often the answer will be – no this test won’t, or there is a better test to write.
Here lies the hardest part, having enough discipline to admit what you do is not the best thing you could do.
I have experienced that! Not too long ago, I caught my self-doing very convoluted explanation to myself why the actions I am taking are actually helping me achieve my goals! And here’s a hint if you can’t explain it in a straightforward sentence, you probably are lying to yourself
So why I am not presenting you any example goals?
Cause I am hoping for discussion under this post 🙂
Present me your proposition, and then we will discuss them.
If you want more 300 you can read it here.
Great post. I’m just wondering about specific goals you use? I know you asked us to post ours, but I’ll be honest this is something I have struggled with and I’m not sure I have good ones that I could share. I have fuzzy things like, „find regression bugs quickly”, or „verify important workflows”, or „check obscure workflows that aren’t used except by one important customer” but I don’t have a lot of specif stuff.
Hi, David problem with a specific goal is you need to have details – I haven’t given a specific goal due self-imposed limit of 300 words.
I will share with you my favourite way of designing automation goals:
1st part is „Bring Value to my team both in Sprint and Marathon” by Sprint I mean fast, not necessarily scrum sprint and the second part is about long term. In the beginning, I think the ratio should be (80/20 going to 60/40 later – I am still tuning the numbers)
This leads to sub goals – for example, I decide that Most value can be brought on UI. Then it will lead me to look which part is most fragile and this will lead me to select the tool.
For example, I will go with unit test in JEST – then I will look about good practices for unit test and Jest and it will lead me to do design more specific goals.
I hope my answer Helped you 🙂
thanks for your reply. That is helpful 🙂 I like the idea of breaking down the short term vs. long term payoff and making sure we aren’t giving up too much value now in the sort term for potential gain later.
Yes, but it also goes without saying that >>NOW<< is paying the bills, and if we concentrate too much on the future project will die due to not bringing enough value now. That's why I am not against "dirty fixes and workarounds" - as long as we are aware of their costs for future. Bad future is still better then no Future 🙂