License To Crack - SDLC - Coding and Testing Phases

Coding Phase

The LLD document contains all the details for a programmer to convert it into a working program. Designed in the right way, the job of the developer is to convert the pseudo code into a programming language in the specified platform. The developer will be given specific guidelines that tell how to code. This guideline includes the naming convention of procedures, variables, commenting methods etc. As per the guidelines, the developer codes and at the end of the coding, he/she compiles the program unit.

By compiling and correcting the errors, all syntax error and removed. Syntax errors are the easy ones to rectify. The logical errors in the programs are the difficult ones to identify and then rectify. By logical error, we mean, the program behaves in a way, that it is not expected to behave. The role of testers is to identify the logical errors at various stages.

Testing

*This section provides only a shorter version of the testing techniques.

Testing is the process of evaluating a system or application, to check whether the application meets all requirements of the client and to detect the errors.

Generally testing can be classified into static testing and dynamic testing.

Again Dynamic Testing is classified into two types: Structural Testing (or) white box , Functional Testing (or) Black Box testing.

Static Testing

Verification activities fall into the category of Static Testing. Static testing refers to testing something that's not running. It is examining and reviewing it. i.e., to check whether the work done meets the standards of the organization. Reviews, Inspections and Walk-throughs are static testing methodologies.

Example: The specification is a document and not an executing program. When we read it to find out the issues, it is considered as static testing.

Dynamic Testing

Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies. Techniques used are determined by type of testing that must be conducted.

-- Functional ("black box") testing.
-- Structural (usually called "white box") testing.

Black box testing involves looking at the specifications and does not require examining the code of a program. Tests that examine the observable behavior of software as evidenced by its outputs without referencing to internal functions is black box testing. It is not based on any knowledge of internal design or code and tests are based on requirements and functionality. Nowadays there are automatic code generation tools and code re-use becomes more prevalent, analysis of source code itself becomes less important and functional tests become more important.

Black box testing is easy as it is based on system's response for a given user's input. If we know the business functionality of the product, we can do black box testing. On the other hand, white box testing requires programming knowledge to know the internals of the code. Also it is time consuming. So only a developer can become a white box tester.

Unit Testing

Soon after the program is corrected for syntax errors, the program has to be checked for logical errors, at the unit level. Programs may have simple user inputs or outputs thru screens or reports. The inputs must be validated for their format, data type, boundary conditions etc. Also, the elementary functionality of the program must be verified. In most of the cases, the programmers themselves will do this unit testing. Many inputs will be verified in this way and the program unit will be checked for the basic functionality in this phase.

If there are any problems while doing this testing, the programmers will debug the program and the bugs will be fixed and will be tested again for the bug fix. While doing the unit testing, that particular unit need not wait for another unit to be completed. It can be tested independently. Unit testing is also termed as component testing. For example, if we need to test a java class and method, even without any screen, the programmer can test the same. Thus any piece of code, that can be independently executed, can be independently tested as well. This is termed as unit testing.

Integration Testing

When all the individual program units are tested in the unit testing phase and all units are clear of any known bugs, the interfaces between those modules will be tested, to establish that they communicate to each other property via the specified APIs and thus they can be integrated into an application. The integration test may be performed by the independent testers or by the development team members.

System Testing

After all the interfaces are tested between multiple modules, the whole set of software is tested to establish that all modules work together correctly as an application or system or package. This is again performed by independent testes. The testers will have to do the system testing as though they are the end users of the application. Systems testing includes special testing methods like performance testing, interoperability testing, stability testing etc.

Acceptance Testing

After the software product is tested by the SDU in 3 different stages (unit, integration and system), the client will test it, in their place, in a near-real-time or simulated environment. This establishes that the software meets the requirements of the end user. This testing is carried out as though they are using the system in their real office, to mimic the real time scenarios.