How to Wreck Your UI Test Automation Project - A Cheat Sheet | Inflectra

How to Wreck Your UI Test Automation Project - A Cheat Sheet

September 4th, 2018 by inflectra

A while back we wrote about how to make a UI test automation project a nightmare, well in the second part of this blog series, we explore some ways you can wreck and derail an automation project. Hopefully, you will do the opposite and become a test automation hero!

You are probably asking yourself - why listen to this guy if nothing is as easy as derailing a UI test automation project, it's a skill no one has to learn, it is intrinsic! I answer that if you are going to do anything, do it with awareness and style.

At a high level, you have two options - either destroy a project at the very beginning or set a time bomb that will explode later!

The first scenario is the easy way out because the investment of time and money will be relatively small at the time of failure. The second - will be a heroic way to ensure the project's demise.

Make the Environment as Dirty as Possible

I start with several quick, yet effective measures. Carefully choose the operating environment. Here is a list of choices, you can combine many of them together for extra effect:

  • An old system with lots of installed programs. It should behave weird even when operated by a human. Slow boot time and unwillingly starting applications are a perfect sign.
  • An anti-virus program with real-time protection. Hopefully, it will consider your test automation tool a virus and block it.
  • Every browser should have all possible extensions installed. Addons have inscrutable ways of impacting tests.
  • The system user account should have minimal rights on the machine, preventing it from installing software, forbidding it to write to specific folders. Security issues are usually silent, so it will be hard to guess why something does not work.
  • Software updates should be turned on. Frequently you'll be waking up at a new place and waiting for lost luggage delivery from an airport.

If an automation tool still works in your environment don't despair, an approach to wreaking havoc on the test recording and creation is still within your hands:

  • Record test steps using a single long session. As every real-life test needs polishing and tweaking after recording you'll end up with something that does not work for a long time.
  • Always try to emulate real user behavior during test recording. Do things fast, move the mouse chaotically, you'll be amazed how inaccurately recorded the steps can be.

Set the Bomb Timer..... and wait!

If for some reason, you have a well-prepared environment where test automation tools work well and you have adopted techniques of creating tests that work, then you can play in the major league and set a project to have a delayed and stunning failure down the road.

This will definitely happen if you'll deliberately neglect a few things.

  • An application under test may change. Ignore this fact and when a new version will be presented by developers - most of the tests will stop working.
  • Test data may change. Hard code all values into tests and update tests every time you need to login as a different user or create a different record in a system under test.
  • There is a well-known test pyramid. Turn it upside down. Implement UI tests for every feature and you will build a huge test coverage with a significant number of flaky tests.

I've seen many projects successfully failed by following the rules I have sketched out. The rivalry goes on. I am hoping I don't see you in the test automation wreckers hall of fame... prove me wrong!

UI testing test automation humor software development logs UI layout VM Dynamic UI Rapise