A familiar question from Management
Hello All, I'm sure this is a very familiar question that we have all gotten from our management at some point. How long will the Automation effort take to automate a particular application....
Forum Discussion
Hi Mike,
Another (or complimentary?) approach to those mentioned by Gennagiy might be the following one: you must make a test strategy first and answer the question: "What for and for how long do I need this test?"
If the test is intended to be executed just several times (3, 5, up to 7) and you are not going to use it for a long time (for example, you need to automate some test to concurrently access database and check if this triggers deadlock), then you may consider (keyword) record and playback approach. Most probably, you will get operational test very fast (maybe as fast as you perform the manual test) and the chances are high that it will work quite stably on the same test environment. Definitely, you are likely have false failures if execute it with different builds, on different environments, etc., but it was our original trade-off.
If your test is intended to be executed frequently, with different builds and in different environment, then you should consider standard development approach mentioned by Gennadiy - use of scripting, but not keyword record/playback, development of the common reusable code library, etc. You should make it clear for your management that in this case test automation must be considered as a development sub-project within your main one (with the clear understanding and agreement that the fact that this is a sub-project does not mean it can be treated as a low-priority one. The priorities of both these projects are the same because otherwise the development go ahead and you will not be able to do a relevant automation to cover all required areas.). Definitely, such approach means that you will have to develop and maintain the common reusable library, organize reporting, test data access, etc. but in the long term you are getting stable reliable and reusable tests that can be managed and adjusted quite easily.
Obviously, these approaches can be mixed - you can create recorded tests to quickly validate a new functionality or the functionality that is inconvenient to test manually while writing tests to be used for a long time for build acceptance and regression testing.
Another (or complimentary?) approach to those mentioned by Gennagiy might be the following one: you must make a test strategy first and answer the question: "What for and for how long do I need this test?"
If the test is intended to be executed just several times (3, 5, up to 7) and you are not going to use it for a long time (for example, you need to automate some test to concurrently access database and check if this triggers deadlock), then you may consider (keyword) record and playback approach. Most probably, you will get operational test very fast (maybe as fast as you perform the manual test) and the chances are high that it will work quite stably on the same test environment. Definitely, you are likely have false failures if execute it with different builds, on different environments, etc., but it was our original trade-off.
If your test is intended to be executed frequently, with different builds and in different environment, then you should consider standard development approach mentioned by Gennadiy - use of scripting, but not keyword record/playback, development of the common reusable code library, etc. You should make it clear for your management that in this case test automation must be considered as a development sub-project within your main one (with the clear understanding and agreement that the fact that this is a sub-project does not mean it can be treated as a low-priority one. The priorities of both these projects are the same because otherwise the development go ahead and you will not be able to do a relevant automation to cover all required areas.). Definitely, such approach means that you will have to develop and maintain the common reusable library, organize reporting, test data access, etc. but in the long term you are getting stable reliable and reusable tests that can be managed and adjusted quite easily.
Obviously, these approaches can be mixed - you can create recorded tests to quickly validate a new functionality or the functionality that is inconvenient to test manually while writing tests to be used for a long time for build acceptance and regression testing.