Testing Phase in SDLC

 SDLC -TESTING

Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. In fact, testing is the one step in the software engineering process that could be viewed as destructive rather than constructive. A strategy for software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software. Testing is the set of activities that can be planned in advance and conducted systematically. The underlying motivation of program testing is to affirm software quality with methods that can economically and effectively applied to both strategic to both large and small-scale systems Objective of Testing A good testing case  is one that has high probability of finding as yet undiscovered errors. Testing is a process of executing a program with the intent of finding errors in it .A successful test is one that uncovers an as yet undiscovered error .The aim of testing is to determine that a program works by showing that it has no errors .

7.1 LEVELS OF TESTING

Testing is usually relying on to detect the faults on each phase, in addition to the faults introduced during the coding phase itself. Due to this, different levels of testing are used in the testing process, each level of testing aims to test different aspect of a system.

STRATEGIC APPROACH TO SOFTWARE TESTING

The software engineering process can be viewed as a spiral. Initially, system engineering defines the role of software and leads to software requirement analysis where the information domain, functions, behavior, performance, constraints and validation criteria for software are established. Moving inward along the spiral, we come to design and finally to coding. To develop computer software we spiral in along streamlines that decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit testing begins at the vertex of the spiral and concentrates on each unit of the software as implemented in source code. Testing progresses by moving outward along the spiral to integration testing, where the focus is on the design and construction of the software architecture. Taking another turn on outward on the spiral we encounter validation testing where requirements established as part of software requirements analysis are validated against the software that has been constructed. Finally we arrive at system testing, where the software and other system elements are tested as a whole.

Table Given below outlines the tests that were performed on the system to ensure correctness and unearth errors, which were subsequently debugged.

Testing Phase Objectives:

Unit testing: The various functions within each program and the program blocks are tested for proper working.

Module Testing: A module is composed of various programs related to that module. Module testing is done to check the module functionality and interaction between units within a module Integration

Integration testing: Testing is done to test the functionality and interfacing between the modules.

Acceptance Testing: Acceptance testing is done after implementation to check if the system runs successfully in the customer environment/site.

Ø  Details about Various Testing Phases:

I.       UNIT TESTING:

Unit Testing will be done to test field validations, navigation, functionality of the programs and its blocks. These tests are applied on various functions within each program and other critical program blocks.  

Table given below gives the outline of three-sample test cases for Unit

Table Unit Testing – Test Case 1
Test Case Description: This test case deals with the entering of basic details related with the registered and logged in user. This process takes many inputs. The test case should check for proper inputs and verify whether the function for validating the inputs is called properly or not.

Expected Inputs:

Details Related With The logged in user in a Standard Format

Expected Outputs:

Alert window for erroneous inputs

Confirmation of Successful Completion of Basic Details Entry Process

Actual Test Results

An alert window was shown whenever the user gave some erroneous data.

Confirmation of Completion of Basic Details Entry was displayed on submission, implying that the functions were called properly.

Table Unit Testing – Test Case 2

Test Case Description: This test case deals with the updating of Basic Details related with the users trade by the java function. The test will check if the java function receives the updating details properly and checks if the updating is performed correctly or not.

Expected Inputs:

Updated Basic Details from the web server

Expected Outputs:

The java function should return the correct row count. Row count denotes the number of rows being updated.

Actual Test Results:

The java function received the details to be updated properly.

On updating the correct row count was returned by the function.

II.    MODULE TESTING:

Module testing will be done to test the interaction between the various programs within one module. It checks the functionality of each program with relation to other programs within the same module. It then tests the overall functionality of each module.

III. INTEGRATION TESTING:

Integration testing is done to test the functionality and interfacing between the modules. The system is built up of various modules, which work together to automate the activities of the hotel management system. These modules should work together in a seamless way to achieve the desired results. Integration testing will test for this property of the modules. The modules display a cause and effect relationship, if data in one module is changed, then it affects the data to change in some other module also. Integration testing needs to check if the modifications do not adversely affect some other modules.

IV.  ACCEPTANCE TESTING:

Acceptance testing was done after the implementation of the system. The acceptance testing will check if the system works correctly in the user environment and if the entire user specified functionalities are present. It also tests if the system adheres to the company policies and quality standard.

Ø  VALIDATION CHECKS

I have use following type of checks/ data validations:

I.       Data type:

I have use String type for character, int for numeric, and Date for date type. No numeric field insert in date. Character never inputted in numeric field as phone no never accept character if any person input wrongly give message. When this problem is removed then user performs further operation.

II.    Length:

When we define a max length, then it never accepts more data, for example

If I define numeric length is 5 then it store either equal to length or less than length. If user gives more character than required then display message and stop processing.

III. Constraints:

In this I am defining range of data if data is less than then display error with message. For example code of password is four characters. The field of date must be 8 characters.

IV.  Format:

The pre define format is used not change daily to daily for example format of date: is YYMMDD used in all date type field. If user inserts another format then display message.

V.     Web Design Constraints

The following design constraints were kept in mind while designing the pages for the whole application:

The pages should be consistent and easy to operate. It should be designed in such a way that an average user who does not have much idea about JSP and related technology can still be able to access the information needed.