Many want to do automated testing. Not many start doing so. Few succeed. The reason why hides in the way we used to do our work and how we assess the performance. We prefer to see the results straight away, on the spot, now. Whereas it takes a while for automation to start paying back. The difference in time and efforts before it starts doing so can be recognized as a waste. In other words you would get an immediate result if you'd manually test your application instead of re-writing map files after UI change. Defects found and removed from the system is what is being scaled against investment in automation that will start paying back in months.
On the other hand, having automated tests saved many projects putting them back on track timely. The beauty of automation is that you so not need to make trade-offs, select regression tests carefully, adjust plans, and procure more resources if you found that more testing is required. You just run them all (except for the situation when there are too many or your resources are limited).
The dilemma grows even bigger when you project size grows. For big projects this is even more difficult to find resources for automation, the lead time is even longer, however the outcome is usually more tangible. You should have firm intention, high motivation, and be prepared for a challenge if you want your automation to start paying back one day. Below are simple recommendation for those who started on this path:
- Get commitment from the management, sell off the idea.
- Set right expectations in stakeholders (automation will start paying back when we reach X% of tests automated; usually about 30 if you start from the most important ones).
- Plan efforts for automation (don't expect people to spend their free time due to pure enthusiasm).
- Stick to the plans, treat automation goals as project goals, equal in the priority.
- Allow enough contingency buffers in your plans, so automation will not suffer just because something happened and your plan does not have any fat to cope with the situation.
- Get skilled hands to work on automation (test automation is more of programming that testing, so make sure people who do it are rather developers).
- Follow best practices in code engineering. It will save you massive efforts in maintenance. Make test code isolated from accessibility functions and GUI maps.
- Run your tests often not to allow them get outdated, so as it is not reasonable to invest in the updating. A test that sits n the shelf a year will unlikely work any more. Now imagine that you have got thousands shelf-ware tests.
- Use data-driven and control-driven approach.
- Involve more people by implementing pseudo-languages (a command driven test with a language that anyone can easily use to create test sequence; such a sequence drives the test code responding to the commands and data parameters in it).
- Consistently deliver the message that automation is not an immediate ROI. Nonetheless it's got one of the biggest ROI in the software industry.
If you follow this you would save yourself tonnes of nerves.
Good luck!
On the other hand, having automated tests saved many projects putting them back on track timely. The beauty of automation is that you so not need to make trade-offs, select regression tests carefully, adjust plans, and procure more resources if you found that more testing is required. You just run them all (except for the situation when there are too many or your resources are limited).
The dilemma grows even bigger when you project size grows. For big projects this is even more difficult to find resources for automation, the lead time is even longer, however the outcome is usually more tangible. You should have firm intention, high motivation, and be prepared for a challenge if you want your automation to start paying back one day. Below are simple recommendation for those who started on this path:
- Get commitment from the management, sell off the idea.
- Set right expectations in stakeholders (automation will start paying back when we reach X% of tests automated; usually about 30 if you start from the most important ones).
- Plan efforts for automation (don't expect people to spend their free time due to pure enthusiasm).
- Stick to the plans, treat automation goals as project goals, equal in the priority.
- Allow enough contingency buffers in your plans, so automation will not suffer just because something happened and your plan does not have any fat to cope with the situation.
- Get skilled hands to work on automation (test automation is more of programming that testing, so make sure people who do it are rather developers).
- Follow best practices in code engineering. It will save you massive efforts in maintenance. Make test code isolated from accessibility functions and GUI maps.
- Run your tests often not to allow them get outdated, so as it is not reasonable to invest in the updating. A test that sits n the shelf a year will unlikely work any more. Now imagine that you have got thousands shelf-ware tests.
- Use data-driven and control-driven approach.
- Involve more people by implementing pseudo-languages (a command driven test with a language that anyone can easily use to create test sequence; such a sequence drives the test code responding to the commands and data parameters in it).
- Consistently deliver the message that automation is not an immediate ROI. Nonetheless it's got one of the biggest ROI in the software industry.
If you follow this you would save yourself tonnes of nerves.
Good luck!
No comments:
Post a Comment