I'm currently tasked with automating a 10+ year old, and rather large application.

There are no exposed APIs, it's built as a monolith. There are no unit tests, nor promise of unit tests to come. The entire application cannot be run locally, and testing has to cover Internet Explorer as the primary platform.

Management think it would be acceptable to have 5000+ selenium tests to cover this. I know this is unworkable and impossible to maintain, especially in an 'Agile' methodology given how flaky both GUI tests in general, and the UI of the system are.

What might be a good strategy to approach this project, other than running far away?

  • >Management think it would be acceptable to have 5000+ selenium tests to cover this. What is their reasoning behind this?
    – Prome
    Jul 13, 2021 at 9:47
  • they are unfamiliar with test automation and think test coverage is the most important metric, and have somehow sold themselves on browserstack + parallel execution making this fine.
    – Spuck
    Jul 13, 2021 at 10:33
  • And do you have proof or experience that it won't work in this context? What's the history of using this approach for this application? Jul 13, 2021 at 12:49
  • 1
    Yes, several attempts have been made by previous automation engineers to simply build GUI tests over this. There are going to be at most 2 people working on this and maintaining that many selenium tests with that headcount has been in my experience, a road to nowhere, more time would be spent fixing tests as they fall over than getting actual feedback from the tests
    – Spuck
    Jul 13, 2021 at 13:55
  • 2
    They contradict themselves - Unit test coverage is 0%, yet they want automated E2E FE tests? I'd go with this approach and show one of the testing pyramids where unit tests are at the base (=foundation) of automated testing.
    – Prome
    Jul 14, 2021 at 7:15

2 Answers 2


I think the problem is how the organization or team thinks about testing. It's not an activity that should be done only by a specific role we call a Tester.

You said you work in an agile environment, yet all the testing is unloaded onto Testers. Why don't developers write tests for their own code? Why the team doesn't get together to figure out how to best test the app in your context? How can you change this approach so that testing is a teamwork? I think these are the questions what should be answered in the first place.

I don't know if 5000+ GUI tests is too much for this context, but it does look like it, especially when there're only 2 people and previous attempts failed (as mentioned in the comment section). Why repeat the same approach again? It will likely bring same results, that is one of a failure.

However, I'd suggest some middle-ground solution for now. You'll likely have some GUI checks anyway, perhaps you can create just a few of them that bring the most value and information to the team.


What would be the return on investment of creating 5000 tests? Lets assume that each test takes half a day to create from scratch (assuming that there is a documented business process flow or manual test case to follow). This is 2500 days effort, which equates to around 9.5 years of effort, based on normal working days. Perhaps 9 of you could complete this in a year! Although MS support of IE ends in 2022 for a lot of platforms so you may end up using the automation pack for cross-browser testing as you migrate to Edge, which would be a lot less flaky to automate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.