Many want to add automated test harness to their tool-set. Some start. Few succeed. There are many reasons for this unfortunate trend to develop, but I want to focus on just one - automated tests are expensive on resources. You simply need to invest more time and efforts into making it happen or you are most likely set to fail.
Despite hiring more engineers to write tests looks like an obvious option, unless your are Google and do not really care about money, it is rarely something that you can sell to your bosses. So, the point is to make the best use of the resources you already have. All those people who are working hard running manual tests could have been used as an additional workforce. Not only would it increase the number of tests dramatically, it would probably increase their motivation and enthusiasm by doing really cool stuff and learning a bit of programming.
This is good that we advanced so far in thinking but there is another problem. What if those people do not have the required experience? Indeed, I would not expect them to start writing an effective and reliable locator method from the start. But as far as they know how to write a cycle - they are good enough. All you need is to re-balance the tasks so as to make the best use of either 1. highly technical personnel, guru and 2. people capable of doing some of coding.
In case when first group of engineers is involved in all stages of automation you probably waste their time and experience on dealing with tasks that can be performed by group 2. Moreover some tasks in automation may be even more suitable for people with manual testing experience, like creating new test scenarios. So it seems like creating test sequences is better to be done by people from the group less experienced in automation, but more savvy in manual test design and execution, knowing concepts of equivalent portioning and boundary conditions. Whereas technical aspects, such as locator engineering and test architecture design should be left in hands on gurus.
This will allow you automation champions to spend more time doing more complex tasks, leaving the simple stuff to their colleagues from manual testing wing.
In practice this schema can be implemented by doing test design with stubs created by automation team, followed by test case implementation by manual testing team. Tests do not work until automation team implements all the accessibility and validation functions. Until implemented the function should report themselves as not implemented.
I have successfully employed this schema more than once. Hopefully this will be of help for someone else out there.
Happy test automation!
Despite hiring more engineers to write tests looks like an obvious option, unless your are Google and do not really care about money, it is rarely something that you can sell to your bosses. So, the point is to make the best use of the resources you already have. All those people who are working hard running manual tests could have been used as an additional workforce. Not only would it increase the number of tests dramatically, it would probably increase their motivation and enthusiasm by doing really cool stuff and learning a bit of programming.
This is good that we advanced so far in thinking but there is another problem. What if those people do not have the required experience? Indeed, I would not expect them to start writing an effective and reliable locator method from the start. But as far as they know how to write a cycle - they are good enough. All you need is to re-balance the tasks so as to make the best use of either 1. highly technical personnel, guru and 2. people capable of doing some of coding.
In case when first group of engineers is involved in all stages of automation you probably waste their time and experience on dealing with tasks that can be performed by group 2. Moreover some tasks in automation may be even more suitable for people with manual testing experience, like creating new test scenarios. So it seems like creating test sequences is better to be done by people from the group less experienced in automation, but more savvy in manual test design and execution, knowing concepts of equivalent portioning and boundary conditions. Whereas technical aspects, such as locator engineering and test architecture design should be left in hands on gurus.
This will allow you automation champions to spend more time doing more complex tasks, leaving the simple stuff to their colleagues from manual testing wing.
In practice this schema can be implemented by doing test design with stubs created by automation team, followed by test case implementation by manual testing team. Tests do not work until automation team implements all the accessibility and validation functions. Until implemented the function should report themselves as not implemented.
I have successfully employed this schema more than once. Hopefully this will be of help for someone else out there.
Happy test automation!
No comments:
Post a Comment