What is the catch for defining and developing a new framework? somebody might tell the cost for development should low. High productivity. Easy maintenance might be another aspect. But we never consider the time factor for running the scripts. After all, this is computer-assisted testing. Who cares about the timing? As long as it is an unmanned execution, nobody cares for execution. This article talks about a brief idea about how to speed up an automation execution time.
Every script is based on some framework. Maybe a record playback or a serious framework. So if you can configure your framework effectively, run time or execution time will go low.
I have jotted down a few improvement areas
- Object-Oriented Approach
- File structure
- Object Repository file size
- Object Repository less coding
- Database Management
- Scripting structure
- Reusability factor
We need to design our automation in such a way that we can swap to different tools when needed. We need to preserve the tool’s independence. Apart from these test engineers should take advantages of some of the downtime or judiciously takes time away from regular tasks that have a due date pretty format, a lot can be accomplished.
How to Speed up the Automation Framework?
The object-oriented design allowed us to play into test harness in a standard way and reuse existing components to test new features, minimizing the code(power of reusability).
Speeding up automation does not mean a good architecture or a well-defined framework. Even though with a lot of investment if we create a good architecture for extendable automation framework and script design. It may still fail even though if found high-quality bugs. Initial success is no guarantee of long term success. Technical aspects are not the only factors that influence a project.
Before going into details of speeding up automation, we must consider 2 aspects of architecture.
- Technical architecture(Software engineering/experience)
- Business architecture (Goal of business, bug test case automation)
How to Speed up the Automation Framework?
- Testers
- Core automation engineers
The responsibilities are:
- Defines the testing scope, define what is to be tested.
- Defines the test plan that contains a testing quote.
- Create manual test scripts, entry and exit criteria(outline of the test).
- Create a report as proof after executing the test case manually
- Supply test data as when it is required
How to Speed up the Automation Framework?
Core Automation Engineers: They are the one who translates the manual scripts into automation test cases. They may be far from business goals more close to technical aspects nearer to developers. They should have a piece of great programming knowledge.The responsibilities are:- Prepare a road map/test plan for each system to be tested.
- Prepare automation test script to cover or apply each test quote
- Write reliable scripts to collect outcome(It should contain reports, bugs, logs, etc) suitable for manual test engineers.
- Become an expert in execution who can understand the script, API.
The separation between testers and automation engineers is necessary as testing and emulation of the user input should not be clubbed and cross-contaminated. Automation engineers need to have test cases to automate. The testers group is the one who provides them.
To bring up speed, testers need to have a constant flow of manual scripts towards automation. Many automation projects either fail or become slow if they don’t perform this activity seriously. Converting manual test engineers to automaton test engineer gives a poor result or the strategy may fail.
How to Speed up the Automation Framework?
But this way of creating a testing team could be an issue in hiring as the testing team grows high. A recent trend is to hire developer vs tester ratio becomes 1:2 from 1:3 to 1:4. So funding could be an issue.
The test automation architect is a key player who is responsible for developing and maintaining the test framework. Architect defines and deploys best practice and coding standards to be used in the implementation of the tests and train test engineers to do minor changes in the abstraction layer.
So when your test set is a little mature, hiring a test architecture will end up the scripting and further process.
Abstraction Layer: your abstraction layer should be a balanced one. If the abstraction layer is too thin(too many fields are set in a specific test script), it could lead to cumbersome maintenance activity. (Also if any of these filed gets updated, hundreds of field needs to be maintained).If your abstraction layer is too thick(too large or too advanced), the complexity will be too huge for this layerThen If we are advancing towards an upgraded framework, test engineers need to learn new technologies, new techniques. It means we need more upgraded classroom training or offline training.
So hiring experts or creating an expert group who can train and step in when needed, is a good idea. But that may significantly hit the ROI.
But we can not overlook the cost of learning and upgrading yourself.
When your testing process is matured and wants to do more speedy testing. Daily Build Engineers come into play. The person in charge of daily builds ensures that the test batch is executed, makes the first analysis of the result and passes the work needed to analyze the test result to the automation test engineers or QA.
A good CI(Continuous Integration) process is a must. Hudson or Jenkins or cruise control etc will make the automation process more speedy.
Speed up automation testing
There are several approaches in the market to generate your script and the framework implementation. But we need to think of a manner where script development time, script maintenance time becomes less. Most importantly we need to find an approach where the execution time also becomes less.
What is the importance of downing the execution time? Well, I am inspired by a philosophy that automation test engineers should not lose time by executing the test script. All the test script should be configured once and should be able to run an unmanned manner. Moreover these scripts will run in a computer-assisted environment. A computer is not that intelligent as we are. If you insert enough intelligence into the script it might slow down the process and on the other side intelligence is less..there is a chance that script will error out. So what are the best approach to automate your script that will serve long without issue is a question.
Speed up automation testing
Object-oriented programming approach gives a script longer life than the normal coding standard. This approach is having very minimal maintenance costs. Encapsulation creates a layer between the application and the main function. If behavior-based files can be created, that model or framework or script becomes more reliable and flexible. I have seen the re-usability also becomes high with this approach. The scalability also becomes high.
So the approach is creating a business logic based file which will different functions.
Say I have a file called Customer_related
inside this I have defined functions …- Create_Customer
- Define_Role
The calling will be very simple
Create Obj_customer=new Customer_related- Obj_customer.Create_Customer(parameters)
- Obj_customer.Define_Role(Parameters)
So if something goes wrong in Create_Customer function we need to modify only that function. We don’t need to touch other functions.
Again when initialized at first everything of the file goes to primary memory and calling of different function become extremely fast.How file size can affect execution time?
There are several approaches in the market to generate your script and the framework implementation. But we need to think of a manner where script development time, script maintenance time becomes less. Most importantly we need to find an approach where the execution time also becomes less.
What is the importance of downing the execution time? Well, I am inspired by a philosophy that automation test engineers should not lose time by executing test script. All the test script should be configured once and should be able to run an unmanned manner. Moreover these scripts will run in a computer-assisted environment. The computer is not that intelligent as we are. If you insert enough intelligence into the script it might slow down the process and on the other side intelligence is less..there is a chance that script will error out. So what are the best approach to automate your script that will serve long without issue is a question.
Once you finalized your approaches the next important aspect is component development. Yes, the most important component of any framework is File.
Now whatever framework we develop, the structure always resides inside the Hard disk. Even if we came up with high-speed data bus, high-speed data transfer mechanism, during execution it is seen the number of files, structure and file size slow down the process.- if the file size is very less that means we need to incorporate a lot of files….. the seek and latency time goes high
- if the file size is high which means we are including everything inside one library and seek time becomes high.
The guideline for file design is written below:
try to write the same functions into a file but do not club all the functions into a single file.
- A number of files that will be loaded first (like-common functions –common to the entire flow..needs to be called almost every step, path library) should be less 2/3.
- library specific to a module will be loaded dynamically and will be released after use.
- The garbage collector should be called after dropping one file. it depends on the scenario to scenario.
- Moreover any point of time the files are handled can not exceed 3/4.
- Try using lightweight HTML reporting instead of Excel Reporting. (excel-2000 and above takes heavy space in RAM….it It is always greater than 2 MB.
- Using CSV as an input file is the best approach. One more best approach is to use XML.
