What happens if you do not test Software automatically from the start?

Problems implementing automated tests to an existing code base indicates your code is not testable. Not many developers (let alone stakeholders or product owners) realize this, but this will have catastrophic consequences in the long run.

A code base that is not testable will accumulate technical debt much quicker than code that does have automated tests. Even if the code test coverage is not ideal, these few tests can still help where it matters, e.g. to make sure that code that contains complex logic is still working smoothly. Technical debt will eventually kill a whole project if it is not regularly removed from any code base.

Missing automated tests can indicate severe shortcomings in requirements process and quality assurance. To implement automated tests, the application requirements needs to be formulated in a clear and understandable way and also be accessible to every team member. Documentation of each module and sub-module needs to be written, its use, range, scope, error response, edge cases and overall system conditions have to be defined. Only if that clarity is given, developers can to write clean, modular code.

If clarity doesn’t exist right away, clarity can be obtained by continuously evaluating requirements and finding an optimum. Scrum and iterative processes help out with this.

The entire array of agile methods, that automated tests are part of, are designed to foster good habits for both staff creating requirements and staff implementing features. Managers and project lead need to understand that time for thorough testing is worth its gold. Resources for the team to implement automated tests and testing processes need to be planned and assigned in an adequate manner. Ideally, implement tests right from the start of a project.

So what happens if you just… don’t?

Stage 1: Arising Problems

• Small features like displaying a new field in the application can take weeks to complete.
  
• Above phenomenon happens even if the team consists of experienced developers who normally would develop in a much higher speed. Even the perfect developer will have problems implementing features to a terrible code base.
  
• The learning curve for new team members is exponentially steep.
  
• In applications with high complexity, it is increasingly difficult to formulate requirements in a way it makes sense, as developers and product owners alike struggle to keep track of what was implemented. Any code or process efficiency goes down the drain.
  
• Testers will have problems with their manual tests and will waste a lot of time coordinating their tests, as each tests can potentially invoke more confusion, as it is not clear (due to the lack of requirements and overview) what is intended or erroneous behavior in the application.
  
• At this stage, there will be outcries from the team to entirely redo the system either completely or in part. At this stage there is still time to act and save the project. If you are a scrum master, product owner or project lead you should definitely listen and take adequate preparations for a worst-case scenario.

Stage 2: Chaos Ensues

• The team has problems sticking to deadlines as the development time converges to almost zero due to technical debt.
  
• Very urgent changes (e.g. due to changes in law) become increasingly difficult as clients, and stakeholders will get increasingly impatient. In a worst case, the company will be fined for not meeting these deadlines.
  
• Because of the high implementation difficulty in the code base, discontentment will spread among team members and the work atmosphere deteriorates.
  
• There might be a few developers leaving the project (or worse, the company if these problems are systemic) because they already anticipate where the project is going. This causes an additional bottleneck of personal resources. With potential newcomers being hired as a result and the lack of documentation this only exacerbates existing problems and confusion.
  
• In a worst case scenario, important developers with key knowledge will leave the project and that can put both team and project into a precarious position.

Stage 3: Impending Meltdown

• Because development speed is so slow, the technological progress is starting to outrun the application. More and more bugs emerge as new technology within the company is introduced (e.g. via updates, new hardware, operating systems or servers). Soon, parts of the application have to be shut down entirely and at some point the system stops working altogether.
  
• If above has not happened yet, it is management that will pull the plug on the project altogether due to the huge amount of time, money and resources that was already wasted invested into it.
  
• If the team was smart and thinking ahead, it might have initiated a complete makeover of the application a while ago and can present a replacement for it.