In systematic approach through application development, testing takes an important place in SDLC (System Development Life Cycle) that is after the implementation. The goal of software testing is to ensure that every function of the application runs well and meets its requirement.
In fact, there are plenty explanation about software testing based on its ideal type that you can always find in many sites. But, not every ideal type of testing flow suitable to every system development due to many factors such as time consuming. Picture 1 is one example of testing flow type. As seen in the figure 1, based on the subject, testing flow can be split into 2 parts: those which are tested by the programmer and those which are tested by the tester.
There are two types of testing object: functional and non functional. Application feature is example of functional testing object. Figure 1 shows only functional testings those I’m going to explain about. Performance and reliability are example of non functional testing object, tested in Stress Test.
Unit Testing performed by the programmer with a module or an unit program as the object. The purpose of Unit Testing is object isolation and making sure it can perform well by looking for its contradiction with the specification, in other word, looking for error.
Each unit program might perform well in its own environment but might not in other environment. Integration Testing performed on modules that have been integrated into one group. Output parameter is function of those modules as one group.
System Integration Testing
(or “SIT”) performed by the tester without involving external user when a system has been built but hasn’t implemented on production environment yet. SIT doesn’t always need client involvement to be done. The testing itself is checking all sub systems those have been built and integrated one to another in one whole system. For example, a financial system consist of sub systems such as debit and credit. These credit and debit systems those work properly in each own environment must also perform well when they have been integrated into one financial system.
User Acceptance Testing
Since the User Acceptance Testing (or “UAT”) aim is to ensure the entire system functions in accordance with the client need, the client themselves need to be involved in the test. UAT is performed on the system which is implemented in development environment. Bugs and issues which are collected from UAT must have been resolved before the system is taken to the final stage of testing.
Production Acceptance Testing
After bugs and issues collected from UAT have been resolved, the system is implemented in production environment so that Production Acceptance Testing (or “PAT”) ready to be performed. When all parties have agreed the system to be launched to live, development and testing process is done.
In performing SIT, UAT, and PAT, a tester need scenario testing as his checklist guide in compliance of complex system testing. Ideal scenario testing must cover all system functions those are going to be tested including positive and negative testcase. Both programmer and tester can easily evaluate the system based on testing outcome which are written systematically on the scenario.
There is no other testing after the system has been officially launched to live. The developer need to do is doing maintenance activity including system monitoring and evaluate system security. If there is any change or new feature requested by the client, it can be written on CR (Change Request) document to initiate the next step.