OK, this one always gets me…what are the various kinds of testing that can be performed? I am referring to software systems testing. To me, it seems that the following are the main kinds:
- Unit testing: This is something a developer should be doing. As part of the software development process, a developer must make sure that the code making up the granular units of the system (functions, methods, objects) work as they are supposed to. For example, if I have a method that converts a given temperature in Celsius to Fahrenheit, then that method must work irrespective of how the method is used by other units of the system. Sometimes, some units are connected to other units (big surprise). For example a service class may be depending on a DAO implementation for saving an object state in a database. So, going by the definition of what a unit test is, how can we unit test the service class? The answer is by using “mock objects”, whereby, the DAO implementation is “mocked” to produce a simulated behavior but without the baggage that a typical DAO comes with.
- Integration testing: This is again something a developer should be doing. However, this may not be part of his/her daily chores. It can be done once the unit tests have passed. This may be regularly done in an automated fashion by a continuous integration server. In this activity, all units must work cohesively in a real-world situation. In other words, the service, the DAO and the database must work in concert to behave in the way the coarse-grained service methods are supposed to.
- Functional testing: Individual units may work perfectly. The units together also behave perfectly. However, it still might not make any semantic sense, or it may not produce the effect desired in the user stories. Functional testing tries to make sure that the code is achieving the correct semantic sense. It should not be performed by developers. It can be performed by someone who is not very involved in the development process but is closer to the product owner. Nowadays, certain tools may allow this activity to be automated, so it might make sense to put this activity of a continuous integration process.
- Performance testing: Hopefully, this one is easy to understand. This activity makes sure that performance metrics are being met.
- Acceptance testing: In many definitions, acceptance testing and functional testing seem to be synonymous. However, I disagree. In my opinion, acceptance testing is based on acceptance criteria: criteria for semantic sense (developed during a backlog development), criteria for security, criteria for performance and so on. If the client (product owner or what have you), accepts the fully built software based on the criteria that have been established, then it can be said that acceptance testing has passed. Obviously, for a software system to be even considered for acceptance testing, all the other testing activities listed before must be successful. Additionally, there may be other non-software criteria that need to be fulfilled.
Although I always tend to approach system issues with my software-glasses on, in this particular case, I am taking a wider “system” look. The above definitions assume a system to be the software, database(s), file(s) etc that make up the solution. I think we can throw hardware and network in it too. All these pieces must work together for a system to be successful.
Hopefully this is a classification that will stand the test of time. Seems consistent with Wikipedia.
