The rationale behind the automation driver is to lower cost in the automation process.
We all know that good things seldom happens without some decent work. This also applies to automation, however, why not try to lessen the pain points while doing it.
The figure shows a highlevel view of how the driver, scripts, and plugins work together in some environment. Red and Orange are possible objects of interest. Green is input modes and finally blue, is the core driver and its extensibility through the plugin concept.
The following design rationales are all deeply integrated into the driver.
Automation often follows a pattern where there are multiple layers. Each layer assumes that input can be used for generating automation scripts and the output is used to enrich the total collected information used as input for the next layer.
Therefore automation can be broken down into 3 steps:
- Initialization, where automation scripts are produced
- Excecution, where the automation is carried out
- Finalization, where the results are processed
There should be no limit to the size of the automation suite.
This is a very important aspect when trying to reduce the cost of automation. The driver supports multiple ways in which this can be acheived.
Being robust refers to doing as designed even though the automation suite is really really huge, or some scripting mistakes are encountered. Reporting must be precise and the driver should be able to run day after day.
The true test for being a framework within a designated domain, i.e. automation, is when the framework can be applied in different contexts not even thought off when originally designed.
A framework also needs to be extensible and should be excellent at doing what it is designed for.
Being flexible is about being a true framework. But it is also about being able to reach goals in multiple ways. In its essence it is about being free within a minimum set of rules and asumptions.
There are a wide varyity of software projects depending on graphical userinterfaces and to some extend with means to execute from commandline. But this doesn't lower cost other than the cost of execution. This is unfortunately not where the real cost lies. The largest effort lies in initialization, defining the automation and in finalization, using the results.
The autodriver recognizes the need for being able to generate automation scripts from other sources, also known as being datadriven. However, there is more to it. Scripts can easily be generated from other input sources by transformation and in these two properties lies the true power in being scriptable.
Autodrive is thereby just a minor, but important piece in a bigger puzzle, which could be called governance or configuration management.