Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Case Study On Software Testing

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 13

CASE STUDY ON SOFTWARE

TESTING
The Evolving Profession of Software Engineering
•The development process is well understood;
• projects are planned;
• Life cycle models are defined and adhered to;
• Standards are in place for product and process;
• Measurements are employed to evaluate product and
process quality;
• Components are reused;

The Role of Process in Software Quality Process


In the software engineering domain, is the set of methods,
practices, standards, documents, activities, policies, and
procedures that software engineers use to develop and
maintain a software system and its associated artifacts, such as
project and test plans, design documents, code, and manuals.
Testing Fundamentals
Error & Faults (Defects)
• An error is a mistake, misconception, or misunderstanding on
the part of a software developer.
• A fault (defect) is introduced into the software as the result of
an error. It is an anomaly in the software that may cause it to
behave incorrectly, and not according to its specification.
Test Cases
• A test case in a practical sense is a test-related item which
contains the following information:
• A set of test inputs. These are data items received from an
external source by the code under test. The external source can
be hardware, software, or human.
Test
A test is a group of related test cases, or a group of related test
cases and test procedures
Software Quality
• Quality relates to the degree to which a system, system
component, or process meets specified requirements.
• Quality relates to the degree to which a system, system
component, or process meets customer or user needs, or
expectations.
•Software Quality Assurance Group
• The software quality assurance (SQA) group is a team of people
with the necessary training and skills to ensure that all necessary
actions are taken during the development process so hat the
resulting software conforms to established technical
requirements.
Using the Black Box Approach to Test Case Design

• black box test strategy where we are considering only inputs


and outputs as a basis for designing test cases
• how do we choose a suitable set of inputs from the set of all
possible valid and invalid inputs
Equivalence Class Partitioning
• A good approach to selecting test inputs is to use a method
called equivalence class partitioning.
– It guides a tester in selecting a subset of test inputs with a high
probability of detecting a defect.
– It allows a tester to cover a larger domain of inputs/outputs
with a smaller subset selected from an equivalence class.
Using the White Box Approach to Test Case Design

• A test data set is statement, or branch, adequate if a test set T


for program P causes all the statements, or branches, to be
executed respectively.
Coverage and Control Flow Graphs
• program statements
• decisions/branches (these influence the program flow of
control) • conditions (expressions that evaluate to true/false, and
do not contain any other true/false-valued expressions)
• combinations of decisions and conditions
• paths (node sequences in flow graphs)
Unit Test:

Functions, Procedures, Classes, and Methods as Units


• A unit is the smallest possible testable software
component. It can be characterized in several ways. For
example, a unit in a typical
• procedure-oriented software system:
• performs a single cohesive function;
• can be compiled separately;
• is a task in a work breakdown structure (from the
manager’s point of view); • contains code that can fit on a
single page or screen.
System Test:
There are several types of system test.
The types are as follows:
• Functional testing
• Performance testing
• Stress testing
• Configuration testing
• Security testing
• Recovery testing
Test Planning
The Test Procedure
– a container document The Test Plan
– defines the scope of the work to be performed
that holds all of the individual tests (test scripts) that are to be
executed
The Test Report – documents what occurred when the test
scripts were run
Test Estimation

Number of test cases required is based on:


• Testing all functions and features in the SRS
• Including an appropriate number of ALAC (Act Like A
Customer) tests including:
• Do it wrong
• Use wrong or illegal combination of inputs
• Don’t do enough
• Do nothing
• Do too much
• Achieving some test coverage goal
• Achieving a software reliability goal
Test Procedure
•Collection of test scripts
•An integral part of each test script is the expected results
•The Test Procedure document should contain an unexecuted,
clean copy of every test so that the tests may be more easily
reused
Test Report
•Completed copy of each test script with evidence that it was
executed (i.e., dated with the signature of the person who ran
the test)
•Copy of each SPR showing resolution
•List of open or unresolved SPRs
•Identification of SPRs found in each baseline along with total
number of SPRs in each baseline
•Regression tests executed for each software baseline
Validation Test Plan
1. Overview
a. Organization
b. Tasks and Schedules
c. Responsibilities
d. Tools, Techniques, Methods
2. Processes
a. Management
b. Acquisition
c. Supply
d. Development
e. Operation
f. Maintenance

You might also like