Simple! Write UI tests only.

Let me explain. There is an anti-pattern which I still see in a lot of projects.

Focusing on automated UI tests on a test environment only.

Whenever there are quality problems in a project, non-QA people tend to search for a solution and often the first thing they come up with is testing on an integrated test environment, either with tests that run against a UI or tests on APIs. This typically originates from the classic waterfall approach of testing, where testing is its own phase within the software-development-lifecycle (SDLC), right after the implementation.

This is promising at first glance, but comes with a lot of problems:

  • Expensive to implement/maintain
  • Slow feedback loops
  • Brittle and flaky tests
  • Does not scale well

Agile processes rely on frequent feedback, short delivery cycles/releases and frequent changes to requirements. Having UI tests only does not help within this process. While there is some worth of creating automated UI/API tests on an integrated test environment, the majority of your tests should not be on this level, due to the mentioned issues.

Unit- and integration tests can give you a far bigger ‘bang for your buck’ than UI tests can. You might ask why:

  • You can run more tests faster
  • They are less complicated to write
  • Less moving parts, so less flaky and brittle

My suggestion: Aim for a good distribution on different test levels to achieve a good coverage while maintaining high development output at frequent releases. Look at concepts like the test pyramid, the testing trophy or the testing honeycomb if you need some guidance.

Or… hit me up and let me help you! :)

What are the anti-patterns that you learned around automated testing? Let me know!