TEST AUTOMATION PROJECTS — WHY DO THEY FAIL?

Ali Haydar
Sep 3, 2018 · 3 min read

Generally, Software companies tend to avoid recruiting Quality Assurance engineers, or testers, in order to cut out expenses. This is fair in case of startups, where anyone can be the first QA member in the company (the startup initiator, a developer, a friend — mainly the person having the proper mindset and skills to tell the rest of the team that they haven’t specified the project adequately). Sometimes, if done incorrectly, this could lead to delivering an unstable product. At this point, the testing activity starts getting more attention, and some experienced individuals might be hired, or even a QA team might be formed.

The team, with the support of management, starts putting all the effort possible in order to stabilize the product. However, due to tight schedules, the manual testing won’t cover all product features. In addition, the regression cost would be high at this stage. This would push the team to think of alternative solutions to speed up the testing process — AUTOMATION.

Due to time limitation, the team selects/implements the easiest automation solution possible — In such situation a series of unfortunate events might happen, here are some examples:

  • Tools evaluation will be skipped and the automation framework will be selected without performing an accurate study of the pros and cons
  • The “Linear Scripting Technique” will be used, where the testers record/play their test scenarios, without measuring the maintenance costs
  • The focus will be targeted towards automating or scripting as much scenarios as possible without paying attention to the optimization of the automation framework, so that it handles generic methods, which would allow to automate more test cases with a minimal effort
  • Business testing and validation will be limited to the GUI automation that uses the “Linear Scripting Technique”. Integration testing might be skipped
  • The test cases won’t be structured in a good manner; they might be too dependent, which might force running all of the test cases to test a small functionality, or might be too independent, which might cause lots of repetition in the automated test scripts
  • The automation environment won’t be planned properly, which might slow down the execution of the tests, and even create problems related to setting up the data and cleaning it up

Such a structure might get the team to stabilize their products. However, once the version tested is released, more features and functionality will be requested. This will cause more problems as the old automation scripts are hardly maintainable. However, this could still be manageable. In a few iterations, would the automation project fail?

Other causes for the Automation projects failures:

  • Lack of technical skills in the QA team
  • Lack of communication between DEV and QA; the communication between DEV and QA is essential in order to identify the type of component under test and how they are implemented
  • Lack of understanding on the management level of the importance of automation, and quality assurance in general
  • etc.

This post was written more than 5 years ago, and now I am moving it to Medium.

Some of this post’s content might no longer be valid with new development practices , and with the technical evolution that happened on the testing and automation. However, it will always be true that tests development and engineering would require a similar amount of attention and effort as features development in order to keep the end users satisfied.

Ali Haydar

Written by

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade