Automated Testing Software Testing

Make sure your end-to-end tests align with your company’s strategy

I recently embarked on writing some new automated end-to-end tests for an existing product that has been around for some time but has never had e2e automated tests written for it.

There’s two ways to use that existing product: there’s the most commonly used and comprehensive user interface for that product, and a less common but new user interface that isn’t yet as fully featured.

I decided to automate the older user interface as it was more comprehensive and has lots more users, so it has to be better right? Wrong. What I didn’t take into account was our company’s strategy of getting everyone onto the new user interface, even though it’s not fully comprehensive yet.

End-to-end automated tests are a long term investment and investing against something the company is actively moving away from is a mistake.

Fortunately I was able to see my mistake early enough to ‘correct course’ and start using the new user interface. The development of the automated end-to-end tests against the new user interface has the added benefit of identifying the gaps in functionality so that we can make sure these are known and addressed.

Have you ever been in a similar situation and what did you do?

9 replies on “Make sure your end-to-end tests align with your company’s strategy”

Hi Scott, Thanks for sharing all the valuable info and I learned a lot from your blogs. A question that bothered me a long time ago that how to automate e2e testing to test the integration for product A and product B, especially when the product B is requiring to visit another server to get the information for product A’s request.

Sounds like this new company kind of threw the ball to you and left for greener pastures. I would think this kind of misunderstanding would be avoided by carefully discussing such matters during the planning phase, especially in an agile environment! I just got hired by a fairly well known eCommerce brand (thanks to your blog!!) to write tests using WebdriverJS – and after I made a quick demo of what webdriver can do the CTO basically said “Sold! Here’s the website – good luck”. My next client will have to sign a contract requiring an hour-long sit-down planning session.

Does this mean you’re less involved with WordPress atm?

Thanks for your comment.

What would you do differently next time and how would you fit that into your testing strategy?

I think I’d just take a little bit more time at the start to ask questions and plan a bit more than just diving into writing the tests to show immediate results.

Leave a Reply

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