Upcoming Webinar: Jump Start Your Automated Testing Efforts With Record & Play Save Your Seat

Blog We love to talk!

Sep Wed

Why So Many Fail to Automate Web Testing

  •  9-9-2015

In most scenarios, automated testing is the best solution for finding bugs and quickly getting the information back to the developers. Some examples where automated testing would be useful include: tests that are repetitive and run for multiple builds, tests requiring multiple data sets or run on multiple hardware/software platforms, and when testing functionality is frequently used and may produce high-risk conditions.

Yet due to problems developers may have previously encountered, automated testing sometimes takes a backseat to manual. Manual testing relies completely on humans, making errors more probable and taking much more time and effort to perform. Add to that list the occasions when the test required is impossible to perform manually, which is a common occurrence, and you can see this is clearly not the best choice.

Instead, place the focus on avoiding the problems that often hinder the creation of automated tests. Let’s take a look at some of the common headaches that prevent testers from going automated.

Misconception 1: Automated Testing Costs More.

This is not quite the truth. Yes, there is software involved with automated testing and, of course, there are the man-hours behind the tests creation. That part is correct. But the benefit of rapid, accurate feedback will make up the price. Testing should be done often and just as importantly, they should be done early.

Misconception 2: Automated Testing Is High Maintenance

A common fear of automated testing is the higher cost of maintenance. The return-on-investment of automated testing is pretty good, considering that a reliable test can run on repeat and get bugs fixed more efficiently. To put it simply, there is a reduction in time when executing the tests and they can run 24/7. Additional benefits of automated testing beyond finding bugs include a better-supported development team, establishing tractability compliance goals and establishing scripts to keep the software from changing.

The human involvement is still there – someone will be manually entering in the code, but with proper planning, the chances of effective, efficient testing is excellent. Extensive thought should be given ahead of time by the project team on how the tests will be maintained. If this is not done, then time is going to be wasted, and that is money down the drain. Optimizing the automated testing will help save on maintenance costs and time commitment.

Misconception 3: Automated Testing Leads To Unreliable Test Results

The fear of unreliable automated testing results is a reasonable one and worth reviewing. Once an engineer has experienced unreliable results, the chances that they will significantly lose confidence in using automated testing in the future rises exponentially. False positive or false negative results do happen. Keep in mind, manual testing also rears unreliable results due to human error. Depending upon the complexity of the code being tested, it can be daunting to trust the results of automated testing. This is why using best practices when implementing automated testing is imperative.

Automated Testing Can Save Money

Unit testing can be started as early as the first day of a project, and any developer worth their salary will agree that the earlier bugs are detected, the easier they are to fix. Even more essential when thinking of the bottom line, the faster a bug is found the less it will cost to fix versus bugs found later in a project.

Convincing Testers To Make the Change

Any project manager working in change management will tell you that getting employees on board with the implementation of something that differs from the usual routine can be a challenge. We have already discussed the vast benefits of automated testing but if your team just isn’t interested in using it, it is doing you no good.

Old Manual Habits Die Hard

Testers may have the attitude, “If it ain’t broke, don’t fix it,” when it comes to going automated from manual. Just because manual testing has worked in the past, however, hardly means it couldn’t use a little “fixin.” Especially when the fix includes getting results faster and improving the project outcome.  Introduce automated testing options before the project has even started. This allows for implementation from day 1. A good service will offer extensive customer support and be “tester friendly” to encourage tester participation and adoption along the way.

If any team members have prior automated experience, allow them the opportunity to showcase the successes they’ve had and to assist with any resistance.

Best Practices To Incorporate

Avoid Problematic Environments

If tests are failing or brittle, then the first agenda item needs to be fixing the testing to eliminate the false positives. Here are just a few environments to avoid:

  • Situations where technologies will restrict the resources that the automated test requires to run properly, such as deployment issues that restrict ports or technologies using file locks.
  • Development based off of a single shared database. This can create a hard-to-control data setup.

Strategies To Ensure Reliable Testing

Automated tests should be run often, so they need to be repeatable and reliable. Engineers need to trust that the results are accurate. Ensure that your tests are more reliable by making sure the following suggestions are happening:

  • Have complete control over the system state setup or build automation chosen to run the testing.
  • Keep infrastructures isolated. Shared databases can have additional processes running which can alter the state of the system and throw false positives.
  • Default first to white box testing instead of black box testing if you are finding false results. White box tests focus in more closely, particularly when performing functional testing. They are easier to write, setup, and test, and execute faster than black box tests.
  • When working with external databases or services during functionality testing, swap out the dependencies with stub services. This will replace the hard to manage infrastructure and put the control back in the tester’s hands.

Automated testing works and it works well. Manual testing takes longer and succumbs to human error. That doesn’t mean that automated testing shouldn’t be well thought out. Team members need to trust that the results are reliable, and to do this, first they need to be comfortable transitioning over to automated testing if they automatically default to manual. To get the best return-on-investment with automated testing, adhere to best practices and avoid the most common pitfalls.

No Comments

Leave a Reply

Your email address will not be published.