Many of us might have come across buzzwords like Keyword-driven, Data-driven, Capture-Replay and these days Model-driven Automation methodologies. Let us try to understand these buzzwords in a more systematic manner through the generations of Software Test Automation.
To Err Is Human
Software developers are Humans and they make mistakes. But is that a good excuse. Definitely not. This lead to inception of Quality Assurance(QA).
But QA Engineers are also humans. They do make mistakes. Also humans are not meant for repetitive tasks as they can get bored, tired or they can skip things. This is what exactly happens during testing of an application. Also due to lack of time few test cases will be skipped. This showed the purpose of automating execution of test cases.
Software Test Automation is not a Substitute for Manual Testing
Investment (ROI). Trying to automate test cases related to new features or features in development is not a good idea and it does more bad than good.
First Generation in Software Test Automation(Agreement)
At this stage every one agreed that Automation is required and started automating test cases.Scripting languages like Shell Scripting, Windows Scripting, Perl, Ruby, Python are used to automate tasks which will make testing easy and increasing reliability by reducing human errors. Also used rudimentary tools to record and replay test case execution.
Maintaining loose scripts became a major problem here. Also in record and play the flexibility part is missing. Example change of some steps in Test Case due to change in application is not possible and it needs re-recording of whole test case.
Second Generation in Software Test Automation(Framework)
To fight with the pain points in first generation, Frameworks have been evolved which binds loose scripts lying here and there and also provides utilities like reporting, logging along with Test runner. Also they decouple activities like reading configuration parameters and passing information from one test case to other. Also Object Oriented Principles (OOP) is strictly followed while writing scripts eliminate duplication of code and to reap fruits of OOP concepts. Also tools provided a feature to allow edit of recorded test cases.
Maintaining test cases using scripts became difficult as the Person should be Good at QA with deep understanding of Product as well as he should be good at Coding. This is the Generation which started demanding huge coding skill set from QA. But in reality percentage of Engineers who are good at both QA and Coding is very very less as there is an attitude difference in QA(Breaking) and Coding(Making).
Third Generation in Software Test Automation(Approach)
Extreme Engineering is in place by this time. People realized that Test Design is more important that automation Technology. Keyword-Driven approach got introduced which facilitates one to separate Coding from Test Case logic. This helps a person who is expert in Coding to Code and QA with good Domain knowledge to write test cases. Along with this one can use Data-Driven Approach where data is separated (not hard coded) from Test cases so that a test case can be executed across different test data sets. Also Integrated Development Environment(IDE) are developed to write test cases. More about keyword-driven approach will be discussed in my next Post.
But Software Test Automation is not just meant for execution of Test Cases as this alone will not guarantee the quality of an application.
Fourth Generation in Software Test Automation(Big Picture)
Capturing test cases from requirements is a huge task and should be done with perfection. Otherwise some of the test cases will not get captured and can result in defective product. In the process of Evolution Model -Based Testing came into existence. According to Wikipedia Model-based testing is the application of Model based design for designing and executing the necessary artifacts to perform software testing
Very well written Yagna.I agree with you on the categorization of different generation of Test Automation. Keep blogging more on this.
ReplyDelete