Why Most Software Teams' Regression Testing Are Not Real? *

Lack skills in end-to-end (E2E) UI test automation and continuous testing.

This article is not intended to offend the majority of software testers who may not be conducting regression testing effectively, which is not their fault:

• Universities don't offer test automation courses.

• Companies seldom invest in professional training or coaching.

• Software testing is often treated as a secondary priority.

• …

“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”.
- this interview from Microsoft Test Guru Alan Page (2015), author of “How we test software at Microsoft”

However, if you are a motivated software professional working to build a startup or side hustle, you have the responsibility to take regression testing seriously, and objectively as an engineer.

Regression Testing in software means “re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change” (Wikipedia).

I highlighted “a change”, why? This means a software team need to conduct regression testing often.

Regression Testing Clarified

Now, ask yourself, “How long does regression testing take in my current (& past) projects? Were they effective?” Pause for a moment, then reflect on whether the following attributes apply to your current/past regression testing experience.

• Frequent

• Automated

• End-to-End (UI)

• Coverage

• Quick

• Teams’ Confidence

Now, let me elaborate.

1. Regression Testing is Not Real If Not Fully Automated.