Software testing helps protect code from incoming bugs and improves general quality of the functionalities exposed to the users. When you look at it from the developer’s standpoint the first thing that comes to mind is unit testing. However it turns out tests come in many flavors. I have already shared in the recap from Advanced TDD workshop with Uncle Bob what kinds of tests a professional team should use to ensure that the application remains intact. The following items create a hierarchy:
- Unit tests (coverage nearly 100%, done by developers) – part of CI.
- Component tests (~50%, business analysts & QA) – part of CI.
- Integration tests (~20%, architects) – they should care only about a couple of layers at the time, executed once a night in dev environment.
- System tests (~10%, Business analysts & architects) – run in staging, at that level you can test 3rd parties.
- Manual tests (~5%, exploratory, people) – you don’t follow a handbook.
All of this might feel confusing and overwhelming even for seasoned developers. That’s why I find the following short talk by Kent C. Dodds from Ignite Fluent 2016 marvelous. He uses a car metaphor to make it easier to distinguish some of the most popular types of testing.
Comments
One response to “Different types of software testing”
System integration testing exercises a software system’s coexistence with others. It demonstrates modules that interact in a correct, stable and proper manner as defined by the functional specifications provided by the client. As a part of functional testing services, basic reporting functionalities and key interfaces of an application-under-test work well.