Transcripted Summary
One of the default tester answers might be: "It depends." Context is crucial and you know your context best so try things out in that context.
Every story is unique and can just provide examples or inspiration. Only if you run small experiments, or probes, you will see what works for you in your special context.
When it comes to automation and continuous testing, the whole team approach, or collaborative ways of working, there are even more things that can help you on your journey.
For example, BDD, Behavior Driven Development.
You can create shared understanding very early on by having conversations before implementation and this way illustrate behavior by examples. This can guide development and testing. The shared examples can then be used for automation and documentation as well.
Another thing is to implement a zero-defect tolerance. It's worth considering. This means, whenever you find a potential issue just clarify right away if it's a real issue. If it is, decide whether it's worth fixing. If yes, you can fix it within the story or any other ongoing story where it fits in. If it doesn't fit in, you can still create a separate ticket and pull it into the sprint for the next one who has free capacity. The product backlog stays free of issues this way. This approach really reduces waste and frees up your team to focus on the most valuable things.
Grow even more full-stack is another topic. Consider growing into a truly cross-functional and T-shaped team, where everyone is helping with testing. Everyone's helping with automation, with development, with user support, with preparing presentations for stakeholders. Basically, any other task. This will increase your lottery factor a lot along the way.
Another useful thing is to have regular on-site use of visits or user research labs. Getting in contact with your actual users is highly valuable. Collaborating closely with them will help you understand the value you can provide. This can trigger lots of insights and ideas, which again feeds into your test strategy.
In the end, it's all about the people. How we work together, how we solve problems together, and how we improve together.
What helped my teams was to experiment a lot. Experimenting is just a great tool for learning but for this you have to be ready. And not all teams, or team members, want to try something new. So, find that sweet spot where they are willing to experiment. With every step they probably will open up a bit more and more. Remember that change takes time. You cannot change the world overnight so don't try to change too much at once. Rather, one thing at a time.
Now, if they're ready, then be sure you know what's the actual problem you want to solve, and which are the potential solutions to try. And then you can experiment. Come up with a hypothesis and have a measurement so you'll know whether you have succeeded or not. You can also learn from failed experiments.
It's all about doing many little small probes to learn from and to show you the way.
When it comes to the things you've heard in this course, try them out! See what works for you.
Whether it be a scientific experiment or rather a probe — but gives things a real try. You will learn. You can adapt approaches where needed and find your own way. Only if you try things out, in your context, you'll know whether they work.
Whatever the result might be, consider sharing your stories so others can learn from them as well and get inspired.
That's it! We've reached the end of this course. Thank you for staying with me until the end. In case you'd like to go deeper on any of the topics addressed, make sure to check out the provided resources. Also, feel free to reach out to me directly, at best via Twitter.
Thanks again and have a great day!
