SOFTWARE TESTING SPECIFICATION

LIFE LINE

Submitted By Sujithra P.S.,Teena Jacob,Vincy K.V. V B MCA

1.0 Introduction Software testing can be stated as the process of validating and verifying that a software program/application/product meets the requirements that guided its design and development,works as expected and can be implemented with the same characteristics.

1.1 Goals and objectives Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Testing can never completely identify all the defects within software.Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oraclesprinciples or mechanisms by which someone might recognize a problem. These oracles may include specifications, contracts, comparable products, past versions of the same product, inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

1.2

Statement of scope A primary purpose of testing is to detect software failures so that defects may be discovered and corrected. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.

2.0 Test Plan The Software Test Plan (STS) describes plans for qualification testing of Software LIFE LINE Configuration Items and software systems. It identifies the software test environment to be used for the testing. Tests to be performed provides schedule for test activities. The primary goal of test plan is to define testing procedures that will ensure that the software is functionally correct from a document perspective and will verify application scalability limits. Its also proves that reliability and fail over aspects of the system can indeed survive instances of system failure. It describes and identifies the tests to be performed, and provides schedules for test activities.

2.1 Testing Strategy The overall strategy for testing LIFE LINE is described as follows. We will use four different methods to test our software. 2.1.1 Unit Testing In unit testing, the analyst tests the programs making up a system. This is also called as program testing. The software units that make up the system are the modules and the routines which are assembled and integrated to perform a large system. This enables the tester to detect errors in coding and logic that are contained within that module alone. Those resulting from the interaction between modules are initially avoided. Unit test comprises the set of testes performed prior to integration of the unit into the entire project.

Function Test: The code is exercised with nominal input values for which the expected results are shown, as well as boundary values and special values such as logically related inputs.

Performance Test: Performance test is done to determine the amount of execution time spent in various parts of the unit, program throughput and response time and devise utilization by the program unit.

Stress Test: Test has been done to intentionally break the unit. This helps in learning about the strength and limitations about the strength and limitations of the program by examining a manner in which a program unit breaks.

Structure Test: Structure test is done to test the internal logic of the program and traversing particular execution paths. The major activity involved in structure test is to decide which paths to exercise, deriving test data to exercise those paths, determining the test coverage.

2.1.2 Integration Testing Integration testing is used to develop an incremental strategy that will limit the complexity of interactions among components as they are added to the LIFE LINE system, developing an integration system schedule that will make the modules available when needed. In this

test, groups of the program modules are tested together to determine they interface properly. Two types of integration testing are:

Top down Integration: This method is an incremental approach to the construction of the program structure. Modules are integrated by moving downwards through the control hierarchy, beginning with the main program module. The module subordinates to the main program module are incorporated into the structure incorporated into the structure in either the depth first or breathe first manner.

Bottom-up Integration: This method begins the construction and testing the modules at the lowest level in the program structure. Since the modules from the bottom up, processing requires for modules subordinate to a given level is always available and the need for the stubs is eliminated.

2.1.3 Validation Testing Validation testing is a process of obtaining the right amount of processing capability of the software LIFE LINE. Here we make sure that the software is providing the exact result which it is assigned for. Here we will perform black box testing where the software is completed and the test for all software components is done together. We will have several input data or test data that we will derive results for. Here we will compare the results from the software with the results that are derived. This will check for the validation of the software. In case there are problems with the software we will create a deficiency list and will record all problems there.

2.1.4 System Testing The implementation of a computer based system requires that test data to be prepared and that the system and its elements be tested in a planned structured manner. The computer program component is a major sub-system of the computer-based information system and particular attention should be given to the testing of this system element as it is developed. In a software development project, errors can be injected at any stage during development. Each we have discussed different techniques for detecting and eliminating errors that originate in that phase. In software the use of testing is not limited to the testing phase.

System testing includes verification and validation, which can be classified as static and dynamic. In static method the behavior of the system is not observed by executing the system. In dynamic method the behavior of the system is observed by executing the system. We have tested all the modules in our project separately and run successfully. 3.0 Test Procedure This section describes as detailed test procedure including test tactics and test cases for the software LIFE LINE. 3.1 Testing Procedure In this section all software specification is described. We will describe the methods for all the different tests to be performed and will also declare the expected outputs. 3.1.1 Unit Test Cases In this method of testing we will test the smallest unit of software called modules. We will be testing all the important paths to find any errors within the boundary of module. So here white box test is applied. We will be testing the parts of the software rather than the entire software. The modules are as follows. 3.1.1.1 Test Case for Creating It ensures the user enters valid data for time limit, score, and number of question. It also checks whether user gives the same name for more than one round. 3.1.1.2 Purpose of test case creation of the LIFE LINE To test whether the creation is proper. 3.1.1.3 Expected results for Creation of the LIFE LINE The expected result is that the donor details,recipient details,and hospital details are stored correctly. 3.1.2.1 Test case to run LIFE LINE

3.1.2.2 Purpose of test case LIFE LINE To test the running is proper.

3.1.2.3 Expected results for LIFE LINE The expected result of this system is that the recipients get donors details and also the smooth and easy running of the system. 3.2.2 Integration Testing In this method of testing, we will implement the software LIFE LINE at the actual site and will run it. So we will be testing the product on actual site network. Here Top-Down model is used to test. We will start the test with home page, after the home page we will be testing each and every sub component or functions of software. 3.2.2.1 Testing procedure for integration We will be using stubs to perform the test. Stubs are dummy function that we will use to test the separate modules. Each of the modules to be tested will have its own distinct stub and the stub will be created depending on the functions of each software component. As part of testing, we will be looking for any signs of collision between our software components and those of other components in the actual one. We must make sure that there is no confusion among the application on the network when they are running simultaneously. 3.2.2.2 Test case and their purpose Each of the software items will be the test case for the integration testing. So each form as a whole will be a test case. We will be testing each and every form for all the errors that logically can occur in it. We will install the software at the actual site and will run it. We will have several different other applications open as well. This applications will be the once that have to interact with our software on normal bases. We will make sure that there all data is saved correctly and no data has been lost from the system. 3.2.2.3 Expected Results At the end of the test all the results should be positive. All of the e software components should work properly. In case we come across any errors we will record them in the error document and these errors will be fixed later. 3.2.3 Validation Testing This test is performed to validate our LIFE LINE SYSTEM. The test is called black box testing where the entire software will be created and will test all the components of the software together. We will be working with the end users who are going to use and to show them the

software. 3.2.3.1 Testing procedure for validation We perform a black box test where we will have software as whole with us. Here we will compare predicted results with those that software gives us and will determine if the software is valid or not. Every button, link or menus will be tested. We will test the correctness of the database and will make sure that there is no error regarding record store database. 3.2.3.2 Expected Results We should not have any troubles with the software since we have already tested all the parts of the software. Everything here should work fine and we should be able to validate the software. We will be validating only if each and everything work in the software. Any software error will force us to wait for the validation until we have fixed all the errors. 3.2.3.3 Pass/fail criterion for all validation tests The pass/fail criterion for the entire validation test is that the result from the testing should not contain bugs that could affect the working of the system as a whole. The system passes a test only when the outputs produced by its modules are the expected ones. Failure occurs when the results are far off from the expected results.

3.2.4 System Testing System testing of software is testing conducted on a completed, integrated system to evaluate the systems compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the integrated software components that have successfully passed integration testing. The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together. 3.2.4.1 Recovery Testing In software testing, recovery testing is the activity of testing how well the software is able to recover from crashes, hardware failures and other similar problems, Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed. 3.2.4.2 Security Testing

It is a process to determine that an information system protects data and maintains functionality as intended. 3.2.4.3 Stress testing Stress testing means testing of software or hardware for its effectiveness in giving consistence or satisfactory performance under extreme and unfavorable conditions such as heavy network traffic, heavy processes load, under or over clocking of underlying hardware,working under maximum requests for resource utilization of the peripheral or in the system etc. 3.2.4.4 Performance testing This is to determine how fast some aspect of a system performance under a particular workload. It can also serve to validate and verify other quality attribute of the system, such as scalability, reliability and resource usage. 3.2.4.5 Alpha/Beta testing Alpha testing is a type of acceptance testing carried out at our site by uses. In this type of testing the users goes on testing the system and the outcome is observed by us simultaneously. Beta testing is a type of testing done at users site. The users provide their feedback to us for the outcome of testing. This type of testing is also known as field testing. Feedback from users is used to improve our system before it is released to our customers. 3.2.4.6 Pass/fail criterion for all system testing When we test our system, some application will pass and some will fail. When testing is completed for a specific application, we enter the results in our test tracking and reporting system.