now that we have identified the fact that automation is required let’s have a look at the approaches already available.
- Code driven testing
- Graphical interface testing (GUI)
The code driven testing involves testing the classes, modules and/or libraries.
The graphical interface testing involves the emulation of keyboard and mouse actions. The output is visible on the screen.
How to chose between one and the other?
This question arises because the GUI projects are composed of code but not all the applications have a GUI.
If the project’s code exposure through visual feedback for both the configuration data (Admin) , manipulation feedback (Frontend) and it’s scope is to facilitate the actions of the visitors, the GUI only approach is enough.
If the configuration data is updated through a file (.tsv/.csv etc), some code driven testing is necessary for the input scenarios.
If all the project is an API, for instance, or its scope is to connect two systems, code driven testing is sufficient.
Based on this article we know for sure which way we should head with our automation process.
the purpose of this series is to come up with a definition of what a “testing framework” is based on today’s needs and standards. The project in scope is a big custom Magento implementation.
The release methodology is Agile, the project is split in two teams. One team handles the issues and the client’s needs. The other the new functionalities. The release cycle lasts about 2 weeks. Rarely more, rarely less. If special events occur there are hotfixes in between. Generally they are avoided by both the team and the client.
The QA (Quality Assurance)’s role is to inspect the requirements and provide feedback, write acceptance criteria, write test cases, conduct UAT (User Acceptance Testing), performance testing, report issues and maintain a healthy build. All this, if possible, should be done by yesterday’s evening.
So far so good, pretty much a standard situation in most of the teams that feel the need for automation.
The challenge is to deliver the same amount of work as before in a shorter period of time in order to accommodate the new features if possible without cutting corners.
- One solution would be to get more QA resources, but this does not fix or improve the process, this just enables a wider bandwidth at the expense of money.
- Another solution would be to increase a bit the release time or lower the number of tickets. This has some monetary impact on the client and unless the quality is a problem it is very less likely to be accepted.
- A third option is to implement an automation framework which absorbs some of the tasks allowing the tester and the team to focus on delivering.
The automation framework is the extra kick needed by the team, as soon as possible, in order to deliver better quality in the same amount of time for a long period of time with marginal cost increase while providing adequate documentation.