Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Scribd
Upload
62 views

Introduction ToTesting

This document provides an introduction to software testing. It defines testing as executing software in a controlled manner to determine if it complies with specifications. It discusses different types of testing like white box, black box, alpha, beta, system integration, and user acceptance testing. It also describes the testing lifecycle and strategies for test preparation, automation, and performance. Defect management is defined as tracking anomalies found during testing to evaluate software quality.

Uploaded by

Satish Puthran
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
62 views

Introduction ToTesting

This document provides an introduction to software testing. It defines testing as executing software in a controlled manner to determine if it complies with specifications. It discusses different types of testing like white box, black box, alpha, beta, system integration, and user acceptance testing. It also describes the testing lifecycle and strategies for test preparation, automation, and performance. Defect management is defined as tracking anomalies found during testing to evaluate software quality.

Uploaded by

Satish Puthran
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

1

INTRODUCTION TO TESTING

Definition of Testing
Software testing is the process of executing software in a controlled manner, in order to answer the question Does the software comply to specifications.

Contd.
Software testing is often used in association with the terms Verification and Validation. Validation: Are we building the right product? Verification : Are we building the product right?

Contd.
Testing is the process of executing a program with the intent of finding an error. A good test case is one that has a probability of finding an as - yet- undiscovered error. A successful test is one that uncovers as - yet- undiscovered error.

Why Testing?

The development of software systems involves a series of production activities where opportunities for injection of human errors are enormous. Errors may begin to creep in at the very outset of the process where the requirements may have been erroneously or imperfectly specified. Because of imperfection at every level of performance , software development is accompanied by a quality assurance activity.

Economics of Testing
Too little testing is a crime too much is a sin. Most of the problems associated with testing occur from one of the following causes :
1. Failure to define testing objectives. 2. Testing at the wrong phase in the cycle. 3. Use of ineffective test techniques.

Lifecycle of Testing
Requirements
Functional Specification Design Code

Acceptance test
Integration Test Unit Test Code review

Types of Testing
Testing can be broadly classified into : White Box Testing : Aims to establish that the code works as designed. Examines the internal structure and implementation of the program. Target specific path through the program . Needs accurate knowledge of the design, implementation and code.

Types of Testing contd.


Black Box Testing : Aims to establish that the code meets the requirements Tends to be applied later in the lifecycle Mainly aimed at finding deviations in behaviour from the specification or requirement Causes are inputs, effects are observable outputs.

Types of Testing contd.


Testing at the inception was classified as below : Alpha Testing :A customer conducts Alpha Testing at the developers site. The software is used in a natural setting with the developer recording errors and usage problems.Alpha tests are conducted in the controlled environment by the developer.

Types of Testing contd.


Beta Testing : The Beta testing is conducted at one or more customer sites by the end user( s) of the software.The developer will not be present in the customers place.So, the Beta Test is a live application of the software in an environment that cannot be controlled by a developer. The customer records all the problems ( real or apparent ) that are encountered during the testing and reports to the developer at regular intervals.

Types of Testing contd.


We do three types of testing , using the Black Box approach. System Integration Testing : SIT is a systematic technique for validating the construction of the overall software structure while at the same time conducting tests to uncover errors associated with interfacing. User Acceptance Testing : UAT is performed by users or on behalf of users to ensure that the software functions in accordance with the Business Requirement Document.UAT focusses on the following aspects:

Types of Testing contd.


All functional requirements are satisfied. All performance requirements are achieved. Other requirements like transportability , compatibility,error recovery etc are satisfied. Acceptance criteria specified by the user is met.

Types of Testing contd.


Difference between SIT and UAT Particulars SIT UAT Baseline Document Functional Specification Business Requirement Data Simulated Live Environment Controlled Simulated Live

Types of Testing contd.


Difference between SIT and UAT Particulars SIT Perspective Functionality Location Off site Tester Composition Tester Company
Purpose Validation & Verification

UAT User Style On site Test Company & Real Users User Needs

Types of Testing contd.


Performance Testing : Performance testing is designed to test run time performance of software within the context of of an integrated system.It is not until all system elements are fully integrated and certified as free of defects the true performance of a system can be ascertained. Performance tests are often coupled with Stress Testing and often require both hardware and software infrastructure. That is, it is necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor intervals, log events.In this way the tester can uncover situations that lead to degradations and possible system failure.

Process of Test Preparation.


Baseline Documents: Development of an application and testing are done on the basis of certain documents.These documents are in in sequence , each of it derived from the the previous document. 1.Business Requirement Document : This document describes users needs for the application. UAT test preparation is based on this document. UAT Test team should break this document into modules depending on how the user will use the application.

Process of Test Preparation contd.


2.Functional Specification Document : This document describes the functional needs , design of the flow and user maintained parameters. These are derived from BRD which specifies clients business needs.The proposed Application should adhere to the specifications specified in this document. In order to achieve synchronisation between the software construction and testing process , Functional Specification serves as the base document. The testing process begins by first understanding the functional specifications.

Test Strategy
The testing process may take the form of an End-to-End approach or individual segment testing using various values.
End-to-End : The test path uses the entire flow provided in the application for completion of a specified task. Within this process various test conditions and values are covered and results analysed.There may be a possibility of reporting several defects relating to the segments while covering the test path.The advantage of using this approach is to minimise permutation and combination of conditions values and ensure coverage and integration. Individual Segment Testing : Several conditions & Values are identified for testing at the unit level for testing.These are tested as separate cases.

Test Strategy contd.


Automation Strategy : Automation of testing process is done to reduce the effort during regression testing. In some cases automating the entire testing process may not be possible due to technical and time constraints.The possible automation strategies that could be adopted depending on the type of the projects are ( I) selective and (ii) complete.In cases of selective , only critical and complex test cases are automated. Time consuming test cases are also automated, as it would take less time for regression testing.

Test Strategy contd.


Performance Strategy :
The client specifies the standards for the performance testing. It generally contains (I)response time and (ii) number of virtual users. Using the above information , a Usage Pattern of the application is derived and documented in the trategy.Issues discussed in the performance strategy document are (I) resources and ( ii) infrastructure. Personnel trained in Performance testing tool identified and date wise utilization of resources is laid down. Adequate infrastructure in the form of huge amount of RAM for setting up virtual users is also to be made available.

Test Strategy contd.

Effort estimation :
The function points in the Functional Specifications will be used as the basis for the purpose of estimating the effort needed for the project.The average of the different estimates from the peers in the test team will be taken as the basis for calculation of the effort required. There could be some variation in the planned to actual effort. An effort estimation review will be done to identify gaps, if any. In case of UAT , function points are taken from the Business Requirement document.

Defect Management
What is a defect? A defect is a product anomaly or flaw.Defects include such things as omissions and imperfections found during testing phases.Symptoms ( flaws) of faults contained in software that is slated for production will be considered as defects.Deviation from expectation that is to be tracked and resolved is also termed a defect. An evaluation of defects discovered during testing provides the best indication of software quality.Quality is the indication of how well the system meets the requirements. In this context defects are any failure to meet the system requirements.

You might also like