The tester’s daily dilemma: my automated tests fail because of the test environment. What can i do?

Automated tests. They are there, and they need to be run. On a test environment. By you. You wrote them in a way that they should be reliable, when the features under test work as designed.

But each day you run the same tests on the same test environment, and they fail. Not because the feature under test is not working properly. No. Because of external factors, and by external i mean: hardware issues, network issues, other services that are underlying to your own but are not in your control. And to make it an even more awesome experience, each day you the run the tests, they fail when performing a different step than the one they were performing the day before when they failed.

Sounds familiar?

What can you do about it? – possible scenarios
  1. Nothing. You don’t care. You enjoy getting frustrated every day by random environment issues. You start getting pleasure from them. Sure, rerunning the same tests one hundred times, hoping they pass is a fun activity. Succeeding to run one test successfully per day is very rewarding. The headaches you get from this activity are already something you don’t notice. WRONG. Skip to point 2.
  2. Start complaining about the issues to people who cannot help you out with this, or who have nothing to do with the issue at hand. Start complaining to the same people that nobody is taking care of the issue. Don’t tell the actual people who can help out onthe issue. WRONG. Skip to point 3.
  3. Start presenting the issues to someone who can actually help out. Begin with your bosses. Either the issues lie in your own team, and they can prioritize the work for fixing them, or they can let other teams know of the issues and ask them to fix everything. So, now you let someone who can help you realize the issue you are facing. What next?
What will your bosses tell you to do about it?
  1. It’s just your imagination. Nobody complained about this before. There is no issue. YOU: I will prove it. I will show you. I will give you as many demos as you need in order to convince you.
  2. We cannot allocate resources to fix it. The issues are there, but it is a test environment, and we cannot spend tons of money and man hours to fix a test environment. We can only focus on fixing production. YOU: What about the time i spend trying to write workarounds for the tests, endlessly rerunning the same tests,  getting frustrated about the whole process? And doing this periodically, since the issue does not appear only during one test run? How about spending the time that it takes to rerun tests due to environment issues doing something that really brings value?
  3. It is not an issue we are taking care of, it is another team’s ownership. We will let them know about the issue and they will fix it. YOU: A few weeks later, nothing has changed. The information got lost in layers of bureaucracy and never reached the people who can help. I am still experiencing the same thing.
What will you insist on doing about it?
  1. Push it. Push it real good. Keep on bringing up the subject to the relevant people until they either get so annoyed by you that they fix it, just for you not to tell them about the issue ever again, or they willingly and kindly fix it.
  2. When explaining what is happening, present the issues as clear and concise as possible. Provide clear steps to reproduce (as in – let them know what you are trying to accomplish when the issue occurs).
  3. Let people know what the impact on your daily work is. How much it takes for you to do repetitive and useless work (rerunning tests, rechecking test results, rechecking the environment to see what exactly happened when the test failed). Give them numbers. Hours/sprint, hours/release cycle, days/month are quite suggestive as metrics to present.
  4. Also, if you know the people who are able to work on the problem, get in touch with them directly. Sometimes, they might just be willing to help you out if they know what is going on and if the fix doesn’t require too much time. It’s worth a try.
  5. Do not write workaround code, just so the test passes. HAVE THE ENVIRONMENT FIXED.

Fixing a broken test environment sounds very difficult to do, but it is not impossible. All you need to do is present the issues you are facing to the people who can actually help you, in a concise manner, and keep in touch with them until the issues have been fixed.

2 thoughts on “The tester’s daily dilemma: my automated tests fail because of the test environment. What can i do?”

  1. The other thing to point out to your bosses if they will not fix the environment is this:

    “Because my tests fail because of the environment, I’m spending time fixing that rather than finding issues in the code itself. The product is essentially being shipped untested. How comfortable are you with that?”

    (And depending on what the product is actually going to be used for:

    “If the product is shipped untested, what’s the worst that can happen? How much money could our clients lose that they could sue us for? How much reputational damage could we suffer? How many people could die?”)

    (Choose the most potentially impactful question from the list above, or think up your own.)

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s