Automation in Testing over Test Automation
Summarize With:
Recent trends in the IT industry are quite indicative of the well known fact that test automation is becoming all too ubiquitous and that the skills which made the testing an investigative and unique profession (also associated with manual testing) are on the wane. However, our aim is not to focus on things which make automated testing gain an edge over manual testing. There is a stark differentiation between Automation in testing and test automation. How the two affect the development of a software product, what are the experiences encountered and the like ....this article aims to answer and highlight some of these queries.
The global big shots in the IT business, reason that the reputation of the company is at stake and hence, they have no alternative, than to blindly go for the automation test suites which will completely nullify the probability of product recalls, repairs and the ensuing erosion of market share and user trust. After all, it conveniently ticks the boxes of 100 % coverage and fast scripting of test cases.
The companies also come up with a genuine economic concern for lack of faith in putting automation into testing. They suppose that even if they somehow pool together the right king of skillful manpower to develop an automation suite, then it will more or less become a product in itself, with all its support and maintenance costs. What would then happen to the Return of Investment, they argue..
What the approach should be for Automation in Testing
- When strategizing towards automating a test, there are a whole lot of preconceived notions related to additional costs, that we need to unlearn.
- The whole line of thought process should revolve around questions like "How can i test faster?" How can i extend its reach for better coverage?
- The functionality should be targeted for testing from the lowest possible level
- To come up with a test tool that can combat with irregular tweaks in system, part of the approach should be to overcome the boundaries of development and testing
- Some of the tools/ techniques which can be a friend in our endeavour are: data management, state manipulation, critical bug tracker and log file parsing.
- Documents like old user manuals can also aid us to a large extent.
A jigsaw puzzle Architecture
Just as there are disparate parts to a jigsaw puzzle set, all the aspects towards automating a test case need to be considered as individual parts of the same puzzle. For example, a testing code that manages data, a test code that creates browser, a code for managing user interactions on the page. In the end, a code that will handle reporting of results. Putting together all these test codes and scaling up this approach can build the test tool we need. While we are at it, we need to carefully analyse the hurdles we encounter and go deeper into them. For instance, when we design a testing tool for API testing is taking too long, we need to delve into the causes which are impeding it's quick response time.
Where Test Automation may not be the best fit?
- It doesn't make any sense to automate tests that require a single repetitions or a couple of iterations.
- When the project requirements for an application are very dynamic. Since the design of an automated test suit requires sufficient resources and enormous labour, it goes against sound economic sense to plan one for a platform that requires regular changes and tweaks.
- Unless the automation in testing is not started with close co-operation with the development team at every stage of the development cycle, it becomes difficult to come up with a complete and effective test tool. In that case why get into it in the first place?
- Maintenance costs of these suits are quite significant and can be a dampener while gauging the overall economics of the project.
- It can be time consuming to automate tests and therefore its usage should be limited to high priority ones.