42 Reasons to Use Software Automation

Software Automation is Better than Manual Testing


  1. I hate manual testing.  I would rather the computer do the testing for me (as long as I tell it how to do so through automation).  It increases my job satisfaction.
  2. Manual testing takes a lot more time than an automated test (assuming both are doing the same test, and I can do other things while stuff gets tested).
  3. It is much easier to run an automated test than a manual test – others are more likely to use it.
  4. Continuous integration servers can be used to verify the tests pass after every commit.
  5. Automated tests are repeatable.
  6. Automated tests can be improved upon (since they are repeatable).
  7. Using automation for testing probably involves me writing more code (something I like) versus waiting for things to launch and pushing buttons (something I don’t like)Code
  8. Generally even small code changes should be ran through testing.  Automated testing prevents skipping testing because “it’s a simple change.”  This is because it takes no extra time or effort on the part of the developer (if the testing is done through CI).

    Software Automation Raises Software Quality

  9. The feedback loop between the time your code is finished to the time you know it worked can be drastically reduced (from hours/days/weeks/months even to seconds/hours/days).  When you see the bug, you still have that specific feature in mind (you haven’t forgotten many details about it).
  10. Tests get run more often.
  11. Code coverage can be used to verify all parts of your code have been tested.
  12. Static analysis code checkers can point out bugs/coding standards that are present in the code.
  13. Some static analysis checkers even have a “score” that can make you feel like crap when your code is not good.  This makes you want to improve code quality.  A coworker the other day told me on a 10-point scale, the Pylint checker rated his code with a negative number.  We both had a good laugh about it (knowing that it needs to be refactored in the future).
  14. Automatic emails (if a CI server is used) can notify developers on code commits if something is wrong… with no testing at all done on the part of the developer.
  15. Features may be able to be broken apart into smaller pieces since it can be tested more at a unit test level than at a system level.Puzzle Pieces
  16. A good set of tests encourages refactoring more often.  This is in contrast to code that grows uglier and uglier over time due to no one wanting to touch it or own it (only add the bare minimum needed for a feature, no matter how much you have to hack it in).
  17. Developers are forced to think more about testing.  This generally makes code more testable, which leads to better quality.

    Software Automation Gives Good Reporting Metrics (Continuous Integration Servers)

  18. Continuous integration servers can show status pages of whether a project builds or doesn’t build.  This could include testing and packaging code… a quick view for management to see if a project is ready or not.
    Project Management
  19. Moreover, if enough work is put into perhaps a scrumboard or other project-tracking methods, a CI build could automatically report status on whether tasks are done.  If every step in a project is tied to a test or build on a build server, the reporting of tasks getting done could be completely automated (if the upfront work during planning is done… linking tasks to a job or test on a build server).
  20. Code coverage shows if all of a project has been tested (not if the tests are of good quality… but at least it is possible to hit all the lines of code).
  21. Code coverage can be used for both project management or customers to help prove the quality of testing on a project (again, it doesn’t guarantee the tests are valid, but just that code has been executed).
  22. Build times in a CI server shows how long building/testing/packaging code takes on average.
  23. The results of a build can be seen through Jenkin’s console output.  Without building or testing the code on my own computer, I can see the results.
  24. I can see the history of a project.  Has it historically built successfully a lot over time, or has it had problems remaining stable?
  25. If a build fails on the CI server, I can immediately see what changes affected that build (so I greatly narrow down the scope of potential code I need to look through).
  26. If I don’t know how to build or test a project, I can copy the steps on the CI server on my own machine to get the same results (assuming I can duplicate the environment).
  27. I can see code coverage over the life of the project.  Does it trend up or down?Graph

    Software Automation Makes us More Efficient

  28. In the beginning, writing automated tests may seem to take more time.  However, the integration time at the end is usually much lower.
  29. Automation mitigates some of the risks in a project.  Rather than wait until the end to test (waterfall), you can test even as every line of code is written (using TDD).
  30. Sometimes we can test things even without having hardware if we can use mocks successfully.
  31. If hardware is mocked out, those same tests can be run without the hardware even when the hardware is no longer available after the unit is shipped.  This means that same code can be used for future projects, and it is already in a known good state.
  32. Testing infrastructure can be reused in multiple projects, which builds up common code to make future projects more easily testable.
  33. Unit testing can be used to replicate a bug.  If a bug can be duplicated in a software unit test, it can most likely be fixed much more quickly than finding and replicating the bug on the target platform.
  34. Companies that use automated testing are more likely to have the ability to be faster to market than those floating in technical debt.
  35. When developed by others (such as test scripts), not everyone on the team needs to know every detail of that script.  Others only need to know how to run it.  This can, to some degree, make others more efficient by building off the effort of other’s on the team without having to know all the details of how it works.  (Side-note: I do this all the time with Docker, leveraging the efforts of others on the Internet to provide a testing or development environment for myself or others.)
  36. Deploying software (especially when something changes that is deployed on hundreds or thousands of nodes) can be much, much, much quicker using something like Puppet or Ansible.

    Software Automation Serves as ‘Living’ Documentation

  37. This documentation doesn’t go out of date if the tests are continually run every time code is committed (as it should be on a CI server).  If the tests pass, the ‘documentation’ (as in, the test code) is still up-to-date.
  38. I can look at unit tests or system tests that are automated in order to know how the system is tested.
  39. Unit tests show me how to correctly use an object.
  40. Testing/development/production environments can be documented through Dockerfiles and docker-compose files.
  41. Server software can be documented through Puppet or Ansible configuration files.
  42. In addition, we can go the other way – Doxygen and other comments from code can use automation be published into webpages.


These are only some of the advantages that software automation brings to the table.  I’m sure you or others can think of several more.

How does automation help in your work environment?

Leave a Reply

Your email address will not be published. Required fields are marked *