Unit testing is also termed as Component testing. Unit testing ensures that reliable program unit meets their requirements. Unit testing is normally conducted by programmer under the supervision of the project lead or the team Lead. Main objective of this testing is to test each unit in isolation and individually. This is done by knowing what the inputs to the unit are and what the expected outputs for the same. Unit testing is a white box activity. Unit test normally comes in the implementation phase of the project.

For instance in the below figure we are trying to do unit testing on the customer class. So we create the object of Customer class assign “CustomerCode” and “Age” property and check for the response. For instance, in this condition, we tried to pass a non-numeric value to the “Age” property and the class threw an error saying, “Age should be numeric”. So here the basic unit testing entity is your class.



However, unit testing is not limited to a component, object, or function. Therefore, definition of a unit testing will depend on the approach. Below are some examples of unit testing:-

Checkpoints in UI like tab orders, error messages, look and feel etc.

Class, object, component level testing as said previously.

In case of functional programming can be a simple method or function.

Logic testing for algorithms. Some projects can have some critical algorithm for instance some kind of custom sorting, security implementation etc. Therefore, that logic can be tested independently.

However, the general thumb rule of what is Unit in Unit testing is that the module self-contained and by itself.

Assembly testing goes one-step ahead than unit testing. It demonstrates that can the modules interact in a correct, stable, and proper manner as defined by the functional specifications provided by the client. Assembly testing is Black box testing style and also called as Integration testing. For instance in the above unit test of the “Customer” class, testing was done in isolation.

But in actually the “Customer” class is not going to be stand alone rather it will be used more in conjunction with the “Product” class and also will have UI to do the same. So in short, the “Customer” class will work with two more entity one is the “UI” and the other is the “Product” class. So normally, assembly testing is done through UI but not necessarily.



The above figure defines a simple scenario for integration testing. The same “Customer” class is now tested with the “UI” and “Product” to see if the interaction between them matches according to functional specifications.

Regression testing ensures that application function properly even if there are changes or enhancements to system. For instance you change the “Product” class still you will run all the test cases for “Product” , “Customer” and “UI” just to make sure that any changes in “Product” class does not affect interaction with other entities. So you will see when testers do a regression testing they run all the scripts to ensure that nothing has been affected.

V model maps the type of test to the stage of development in a project. V model stressed the point that every phase in project should have a test phase also.



Unit Testing
Starting from the bottom the first test level is "Unit Testing". It involves checking that each feature specified in the "Component Design" has been implemented in the component.

In theory, an independent tester should do this, but in practice, the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts of the system, which may not have been built yet. To overcome this, the developer either builds, or uses special software to trick the component into believe it is working in a fully functional system. This test maps with the implementation phase and normally developers do the unit testing for the project.

Integration Testing
As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests independently, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers.

Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components. The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system. Integration test cases are written when design documents are written.

System Testing
Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it.

In essence, System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact, it is one giant component.

System testing can involve a number of specialist types of test to see if all the functional and nonfunctional requirements have been met. In addition to functional requirements, these may include the following types of testing for the non-functional requirements:

Performance - Are the performance criteria met?

Volume - Can large volumes of information be handled?

Stress - Can peak volumes of information be handled?

Documentation - Is the documentation usable for the system?

Robustness - Does the system remain stable under adverse circumstances?

There are many others, the need for which is dictated by how the system is supposed to perform.System test plans are written when the specification of the project is going on.

Acceptance Testing
Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus:

Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested.

The customer should always do acceptance testing and not the developer. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It is like getting a green flag from the customer that the software is up to the expectation and ready to be used. Acceptance test plans are written during the requirement phase of the project. In real scenario these test plans should be given by the end customer.

It is a collection of instructions an organization can follow with the purpose to gain better control over its software development process.

There are five levels of the CMM. According to the SEI,

Level 1 – Initial

Level 2 – Repeatable

Level 3 – Defined

Level 4 – Managed

Level 5 – Optimizing

Sigma means deviation in Greek language. Deviation means how much variations exist in a set of data. For instance let’s say in a software maintenance project out of 100 defects 68 defects are rectified to the mark and remaining bounce back that means your bug fixing process is on “2 Sigma” level. I had described only from bug fixing perspective. But this can be applicable to any process organization.



Therefore, I should only have 3.4 defects in a million defects then I can say I am six sigma.