Lately, I have seen a trend where new test automaters do not know what a test automation framework is. I thought I'd enlighten everyone by sharing with you what it is and why you need to know what it is.
If you search for the term on Wikipedia, you come up with the following page and the following description of what a test automation frame work is:
http://en.wikipedia.org/wiki/Test_automation_framework
"A test automation framework is a set of assumptions, concepts and tools that provide support for automated software testing. The main advantage of such a framework is the low cost for maintenance. If there is change to any test case then only the test case file needs to be updated and the Driver Script and Startup script will remain the same. Ideally, there is no need to update the scripts in case of changes to the application."
This is a very high level way of looking at what it is. To be more precise, I've listed what I think need to be included with a test automation framework:
- Solution Design Document - how you came up with your chosen framework and its alternatives.
- Naming Standards Document - how you should name all your assets that exist under the current framework.
- Best Practices Guide (Includes Coding standard) - how test assets should be designed, developed, built and implemented.
- User Guide - how a user of the test assets would go about using the stuff built.
- Implementation Guide (optional) - how you would setup a test automation engine that follows the current framework.
(Google the above if you don't know what they are)
Above are the only things you need for a test automation framework. Like any other framework, establishing a basic structure underlying a system, concept, or text is all you need to implementing a host of test automation assets. The test automation engine and its test assets are the end products of the initial framework that is setup.
The test automation framework and the test automation engine are two different things. Yet, to this day, I have still seen people referring to them interchangeably. Used loosely, I understand why but really, this should not be happening.
Why?
This is because for a proper implementation of a test automation framework, you need more than just a test automation engine but all the structures in place to ensure that the framework in place is of higher maturity.
Next, I'll talk about Test Automation Framework maturity.
Monday 25 February 2013
Monday 18 February 2013
Test Automation - why would you want to?
Lately, test automation has become a buzz word. I'm seeing a lot of business stakeholders suggesting and letting us go forward with investing more into test automation but rarely do they truly understand the purpose for automation.
There are many preconceptions that go with test automation but I will not get into them. Rather, I'd like to share what you do get out of test automation if done properly.
The first reason why you would want to invest in test automation is because it should hasten the turn around time for the testing phase of a project. If you have built a mature test automation engine that follows a mature framework, you will have the ability to run the test automated regression suite at any point in the testing phase(s) to flush out bugs in old functionality in the new code. Not only that but you can hasten the turn around time after the initial build. Keep in mind though, the ROI is achieved over time. The initial development time for a test automation engine is very significant. I won't get into that in this blog but just keep that in mind.
The second reason why you would want to invest in test automation is because if the automation is developed with a mature testing framework,;with test scenarios chosen that are suitable; you will get return on investment over time. The savings only become somewhat significant over time.
Over the years, I have seen ROI lost because people do not truly understand what should be automated. Suitable scenarios need to be tests that are highly repeatable, do not change often or save a mountain of time compared to manual execution of the scenario. If you compare manual preparation and execution with automated development, maintenance and execution and completing the scenario manually costs more, then it is a true indication that the scenario should be automated. Everything should not be automated!
The third reason for investing is due to the fact that automation can be run at any time and should be faster than manual execution. If this is not the case, the framework maturity is not at a level that is adequate. This will lead to loss in the return of investment you should be getting with the investment in automation. Going back to the point, if you can spend time out of hours without human intervention while the automated suite is executing, you can invest time in other activities. Thus allowing more efficient and effective use of the test resources in your team.
There are many other reasons why you would want to invest in test automation but the above reasons are, in essence, the primary reasons you should invest in it.
There are many preconceptions that go with test automation but I will not get into them. Rather, I'd like to share what you do get out of test automation if done properly.
The first reason why you would want to invest in test automation is because it should hasten the turn around time for the testing phase of a project. If you have built a mature test automation engine that follows a mature framework, you will have the ability to run the test automated regression suite at any point in the testing phase(s) to flush out bugs in old functionality in the new code. Not only that but you can hasten the turn around time after the initial build. Keep in mind though, the ROI is achieved over time. The initial development time for a test automation engine is very significant. I won't get into that in this blog but just keep that in mind.
The second reason why you would want to invest in test automation is because if the automation is developed with a mature testing framework,;with test scenarios chosen that are suitable; you will get return on investment over time. The savings only become somewhat significant over time.
Over the years, I have seen ROI lost because people do not truly understand what should be automated. Suitable scenarios need to be tests that are highly repeatable, do not change often or save a mountain of time compared to manual execution of the scenario. If you compare manual preparation and execution with automated development, maintenance and execution and completing the scenario manually costs more, then it is a true indication that the scenario should be automated. Everything should not be automated!
The third reason for investing is due to the fact that automation can be run at any time and should be faster than manual execution. If this is not the case, the framework maturity is not at a level that is adequate. This will lead to loss in the return of investment you should be getting with the investment in automation. Going back to the point, if you can spend time out of hours without human intervention while the automated suite is executing, you can invest time in other activities. Thus allowing more efficient and effective use of the test resources in your team.
There are many other reasons why you would want to invest in test automation but the above reasons are, in essence, the primary reasons you should invest in it.
Subscribe to:
Posts (Atom)