What are the prime factors which bring automation into play? When does a test manager / lead determine the need to automate an application? What factors influence Automation feasibility?
- What is the timeframe ?
- What is the cost of failure ?
- How fast are development cycles ?
- What current testing is highly repetitive ?
- How quickly do we need to get feedback ?
- How complex is the process being tested ?
- Who is available with the necessary skills ?
- How much do automation developers cost ?
- What is the desired shape of our test pyramid ?
- How deterministic is testing, are results defined ?
- How many devices and versions are tested manually ?
- What coverage do we have for Unit, and Integrated tests ?
- How much time is available (automation takes longer in the short term) ?
For the items regarding cost:
Cost is always a factor. If revenue is $100,000 per hour then the cost of failure is relatively high and it makes sense to pay a lot of manual testers or automation engineers. If the current revenue is $10 per hour then it may make less sense to spend money on testing, either manually or through automation. Similarly if the revenue over 6 months is $12,000 it (may) not make sense to pay an automation engineer $60k ($120,000 / 2) and it may make more sense to do manual testing.
What are the prime factors which bring automation into play?
How fast do you want to release? and how often? The faster, the more automation you need. Typically in products that practise continuous delivery, you bring in automation from the start.
When does a test manager / lead determine the need to automate an application?
Test automation is more important for developers. As a developer I want to refactor my application with confidence in very short cycles, so I cover behaviours that I build with test-automation. Therefor I practise TDD and start with a failing automated end-to-end test. This book (TDD with Python, free online read) shows how that could work in practise, going from a single broken Selenium test to a fully automated deployed application.
Also I like to start each new product with an automated ten-minute build script:
Build, test, and deploy your entire product at any time with the push of a button.
Your build should be comprehensive but not complex. Make it compile source code, run tests, configure registry settings, initialize database schemas, set up web servers, launch processes, build installers, and deploy. Your IDE won't do all this, so learn to use a dedicated build tool. Make sure your build works when disconnected from the network, too.
Builds should be fast. If not, look at your tests. End-to-end integration tests are the typical culprit. Replace them with faster, more maintainable unit tests.
Also I think developers should follow the programmers oath:
- I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
I have no clue how I should do that without automation of the proof.