The Testing Pyramid
The Testing Pyramid is a common way of explaining the three main areas of testing.
The Bad way
“Bad” is perhaps a bit harsh as the way testing was originally implemented depends on what practices were common at the time the codebase was developed and other factors.
![](../__attachments/1508639132/tut-pyramid-bad.webp?inst-v=5e1cb58c-56f0-4e45-b834-ef0000ddaa47)
However, the fact remains that from the a best practices standpoint, this approach is far from ideal and is likely to have some or all of the following issues.
Running all your tests will take much longer and cost much more as it involves QA Engineers.
Your codebase will cost significantly more to maintain.
Finding and fixing bugs will take much longer, often 5 - 10 times, and even longer if in production code.
Quality is going to be worse than the “Good” way, (see below).
The code is likely to be fragile.
Car analogy - Part 1
A common analogy is to consider testing a fully assembled car that is made up of thousands of components have not been thoroughly tested.
Testing involves driving the car and seeing if it works, falls to pieces or just crashes.
Depending on which components fails, resultant failures could be expensive and even lead to death!
Good way
This is how one should ideally build software to maximise quality.
![](../__attachments/1508639132/tut-pyramid-good.webp?inst-v=5e1cb58c-56f0-4e45-b834-ef0000ddaa47)
End to End, System and GUI testing is a very time consuming to configure and very slow to run. By relying properly on unit and integration tests, the amount of End to End testing, whether manual or automated, is much reduced.
Integration Tests are a very important part of the the testing process. They are more complex and slower to run than unit tests as they depend on APIs, databases and other system components being available. However, they do a great job of testing that components work together properly. They are therefore more “real world” than unit tests and don’t have to be run as often.
Unit Tests - the cause of fear and loathing with some developers, who feel that writing unit tests means more work with nothing concrete to show for it. Yet with the right process and tools, they provide a perfect way to validate and protect their functional code, reduce the time spent writing unnecessary functional code, which then also has to be (unnecessarily) debugged. Unit tests are the mainstay of a quality product.
Car analogy - Part 2
In the car industry, quality underpins everything and each supplier has to meet stringent quality standards.
Each supplier might have its own suppliers as well. The responsibility for quality is passed down the chain and expected to be maintained. A software engineer, backed up by the QA, Product Owners and Domain Experts, can reasonably be expected to do the same for each piece of functionality.
An engine would need to be tested before being shipped to the assembly line. The engine would be properly tested in a test bay before being delivered. This can be thought of as a form of integration testing.
Of course, in the car industry, each component is fully and independently tested before assembly. This has some major advantages, all of which apply to building software.
The likelihood of failure of the final product is significantly reduced.
The cost of the actual incident, or more likely incidents, is dramatically reduced.
Due to quality of process, finding the cause of any potential incident is far easier and therefore cheaper.
The perception of quality by customers is much improved.
Management and product teams are significantly less stressed.
Conclusion
The reason we built DevMate was to not only to provide a way of implementing “The Good Way” through a tool, but to also give Developers, PMs, POs and QA Engineers the ability to participate directly in the requirements definition and overall testing process.
By doing this, DevMate helps the developer share the responsibility with others, write less test code and more functional code and drive up quality in a non-disruptive way.