Value and Risks of Automated Testing

What if I told you that adding an automated testing program to your testing process could not only make your team more productive and efficient, but also improve the quality of your product? While fully automating the testing process isn’t feasible or possible yet, adding it to your portfolio can free up employees who would usually conduct tests that can be automated to conduct tests that must be done manually.

The Value of Automated Testing

Automated testing is valuable because if it is done right, it doesn’t require any further investment in time or resources; it just continues to do its job day after day. You could run it 100 times and it’s not going to complain, it’s not going to ask for time off and it’s not going to say, “Hey, I’ve done that 10 times now. Can I just quit doing that?”

A big advantage of having a robust automated test suite is that once you design a good test, you’ll never skip or skimp on the kinds of regression testing that you know you ought to do whenever a new build comes out. This is an advantage both to the testers and the users, because it allows more aspects of a program to be tested, since time constraints would restrict the amount of testing if the programmer had to do it manually.

Risks Associated with Automated Testing

Most of the risks associated with automated testing have to do with the humans who write the tests, not with the testing program itself. One of the risks is that people will design tests that don’t test real functionality or are in no real danger of breaking. It’s possible to write dozens of tests that don’t really add any value to understanding the big picture of what’s happening with your code base. You have to make sure that the test that you write is worth writing in the first place, and that the information you get back is worthwhile.

You also need to make sure that you’re not inserting the assumptions of the code itself into your tests. In other words, if you designed “perfect” test cases where all the data was perfectly lined up such that you have nothing but straightforward “happy paths”, then you may artificially inflate your test case number. In both of these cases, it’s important to make sure that you’re writing test cases that are meaningful.

Key Questions to Help You Choose an Automated Testing Program 

The process of choosing an automated testing program will vary for every company, because it really depends on what types of testing you want to address, what kind of technology is involved, and ultimately the capabilities and skill set of the target team. However, there are some key questions that you can ask to determine what program will be best for your company:

  1. Are the testing needs extremely complex and the skill level of the testing team or QA team not very deep (most of them have not done much programming or development)? Then, they may need to have something that is already packaged for them like a commercial product that has full support. If the team has a little more technical savvy, they may favor openness and expandability of an Open Source framework over having commercial support.
  2. Another thing to consider is what are the reporting tools involved? Can you generate documentation from it? Robot Framework is a good program for some companies because it allows display of the types of testing being done to nontechnical stakeholders in a company.

Find out more in our ebook on automated testing.

Follow Us