This is part three of my test automation blog posts. I previously talked about why test automation is important and to start as a developer or team, investing in knowledge is important.
So you know now you should start with test automation to survive in this world. To start you should invest in knowledge before you are able to start. But then what? Some tests are made and some coverage is shown, then everyday life kicks in and you go back creating functionality without creating tests again.
Best way to make sure you keep on creating tests are the next 8 points:
- Put test automation on your Definition of Done (DoD)
- During code review of your peers take a look at the automated tests that are created
- Make sure collaboration takes place between test and development experts
- Agree what test automation types you use in different situations
- Make sure the feedback from the automated tests come at least once every day.
- Make transparent that spending time on creating the tests in the end saves time
- Create a test automation backlog were you address the scenario’s that cover the threads or risks for the product or even the company.
- Start with specification by example to drive your test automation.
Put test automation on your Definition of Done (DoD)
When you put test automation on your DoD as a team including the Product Owner, it is clear that it should be part of everyday development. You are able to refer to it when tests are threatened to fall of the table under pressure of delivering functionality.
During code review of your peers take a look at the automated tests that are created
Make sure that looking at the test automation code is just as important as looking at the application code. It is part of the production code and just as important.
Make sure collaboration takes place between test and development experts
Collaboration between test experts and development experts needs to take place. It is good to invest time together from the start. With start I don’t mean when you start working on a user story, but during refinement when you are talking about a story. At that moment it is good to already take a look at do I have the information to test it and to build it? What am I missing? This way it is possible to manage expectations on time instead of to late during a sprint or even later.
When you really start working on the user story it is good to talk about what are we going to test, what is the approach, what to cover with what type of test?
This way both are stimulated to actively work together to achieve the best results possible.
Agree what test automation types you use in different situations
It is good to create a high-level plan of approach on test automation. What sort of applications do we have? What type of tests do we need to tests them? What tools/frameworks do we use for that? What is the preferred ratio per test type?
Agree on this on a high level so it is clear what the approach is, but have the freedom within the teams to adapt to the current situation if necessary.
Make sure the feedback from the automated tests come at least once every day
Feedback is de keywork. You need this fast, you need this often and it should be reliable. Run your unit tests local every time before you checking the code. During a build or as a next step also run your integration and UI tests so feedback on that part also follows as soon as possible. At least run these tests once every day so every 24 hours you know the status of your product quality.
Make transparent that spending time on creating the tests in the end saves time
This one is hard. Keyword is measuring. But what do you need to measure?
In the end the main goal of a team should be delivering value to the customer. The faster you are able to do this while maintaining quality and stability the better.
So some examples of what to measure;
- How fast can we put an idea in production?
- How much time do we spend on manual testing?
- How many defects do we report after a release?
- What are the root causes of a defect?
- How fast can we solve and release a prio 1 defect? How is this different from a normal release?
Like to know what you measure and why, please leave a comment to share that knowledge?
Create a test automation backlog
When you are dealing with a legacy product this can help. With the entire team brainstorm on the risks and threads the company has looking at the product. Then determine what tests should always work to prevent or reduce those risks and threads. Order this list with the highest risk or thread on top. Then determine how much time do we need to test this manually and how much time will it take to automate these tests.
With this information, discuss which items on this test automation backlog you will take into the sprint. Do this as long as you feel that the risks or threads are high enough and the effort for automating them once is a good investment over doing it manually every release.
Beside that you also have to change the way of working so new development is done with test automation in mind and DNA as described in the other points.
Start with specification by example to drive your test automation
Specification by example works really great. It makes requirements so much clearer so everybody understands them. Parts that are missing will come to surface much faster because people can imagine the scenario’s. Based on the scenario’s they come to the conclusion that examples or edge cases are missing. It helps teams work together form the start. All disciplines can talk about the examples and think about how to test and how to build this? What do we miss to test or build this?
In the end, we eliminate a lot of defects and wrong expectations even before we write actual code. When you are used to using examples, you can also use these to drive your functional tests. This way you have live documentation with executable specifications.
Conclusion
Test automation takes time and sometimes is hard to keep up. But in the end it pays of when done the right way. So invest in knowledge and start changing your DNA and mindset!
Really would like to know what challenges you face and how you overcome them on the Test Automation area, please leave a comment behind with your experience?
Kind regards,
Pieter Versteijnen
PS. Missed why you should even start Test Automation? Read it here.
