Test automation exists for quite a while, but it isn’t practiced consistently. In the years that I am in software testing, I’ve heard a lot of arguments on why testers do not automate their tests. The ones I hear the most are:
- Test automation will take away my job.
- I don’t know where to start.
- I cannot write code.
Test automation will take away my job
You as a tester think that you will lose your job when we automate testing? In short: No, it won’t! Testing is an intellectual process. Before you can automate anything, you need to think of what you want to automate. The test automation can only check situations that you defined. Remember, the test automation cannot think for itself and additional manual testing is always needed.
I don’t know where to start
Well, at the beginning of course! Start with investigating on test automation, what can it do, what has worked before and might also work in your situation? Since automating test is an investment, you need to find out which parts are important enough to automate. Product risk analysis (a good practice of structured testing) will definitely help you to define the risk-full and important parts of the software. Often repeated manual test cases are also a very likely candidate for test automation. Watch out not to start too complex. Work on some simple test automation to prove your business case on test automation and then expand.
I cannot write code
This is no reason not to automate tests! Who said you have to do it yourself… You – as a tester – can help decide which test scripts need to be automated. If you do want to do it yourself, you need to invest. At least know some basics in programming. Most frameworks that can help you do test automation don’t require in depth programming skills, but the basics will help you enough to do some valuable automation.