Ch 5 Software Testing Techniques

8/3/2019 Ch 5 Software Testing Techniques

1/32

Ch 5 Software Testing Techniques

Introduction to testing

Test plan

Introduction to manual testing

Automation testing tools


2/32


What is testing?

Testing is the process of demonstrating that errors are not

present. The purpose of testing is to show that a program perform its

intended functions correctly

Process of establishing confidence that a program doeswhat it is suppose to do.

Objective is to find out all possible bugs in a work product.

Testing should intentionally attempt to make things gowrong to determine if things happen when they shouldnt orthings dont happen when they should.

It is a process of trying to discover every conceivable fault ina work product


3/32


It is a process of executing program with the intent of findingan error

A good test is one that has high probability of finding as yetundiscovered error.

A successful test is one that uncovers as an yetundiscovered errors

Mature view of software testing is to see it as a process of

reducing th

e risk of software failure in th

e field to anacceptable level.

Two strategies of testing

Black box testing

White box testing


4/32

Black box testing

We cant look inside the box to see how it operate.

If we type certain input, we get certain output.

Black Box Testing is testing without knowledge of the internal

workings of the item being tested.

For example, when black box testing is applied to software

engineering, the tester would only know the "legal" inputs and

what the expected outputs should be, but not how the program

actually arrives at those outputs.


5/32

Black box testing

Advantages ofBlack Box Testing

more effective on larger units of code th

an glass box testing tester needs no knowledge of implementation, including

specific programming languages

tester and programmer are independent of each other

tests are done from a user's point of view

will help to expose any ambiguities or inconsistencies in thespecifications

test cases can be designed as soon as the specifications

are complete


6/32

Black box testing

Static Black Box Testing the specification

The specification is the document not the executingprogram

Dynamic Black box testing Testing software without having an insight into details of

underlying code is dynamic

Its a dynamic because the program is running

Its a black box bcoz you are testing it without knowingexactly how it works

Just entering inputs, receiving outputs & checking theresults.


7/32

White box testing

White-box test design allows one to peek inside the "box", andit focuses specifically on using internal knowledge of the

software to guide th

e selection of test data In this testerhas access to the programs code & examine it.

White box testing is a test case design method that uses thecontrol structure of the procedural design to derive test cases.Test cases can be derived that. guarantee that all independent paths within a module have been

exercised at least once,

exercise all logical decisions on their true and false sides,

execute all loops at their boundaries and within their operationalbounds, and

exercise internal data structures to ensure their validity.


8/32

White box testing

White Box methods

Statement coverage

Decision coverage

Condition coverage

Static white Box:

the process of carefully and methodically reviewing the

software design, architecture, or code without executing it. Dynamic white box

Executing the system to see the system is performing as

per the requirement.


9/32

Different testing types

Different types of testing Unit testing

Integration Testing (Incremental Approach Top-down &Bottom-up)

Functional testing

System testing Performance testing

Load, Stress testing

Security testing Recoverability testing

User Acceptance testing Alpha & beta testing


10/32

Unit testing

testing of individual component in the program.

The purpose is to discover the discrepanciesbetween the modules interface specification & its

actual behavior

Typically used to verify the control flow & data

flow

Generally performed by developers


11/32

Integration testing

It is a process of testing multiple component together (multiple

text boxes, forms etc.)

To assure that the S/W units/components operate properly

when they combined together

Performed against group of modules

It is doing by tester


12/32

Integration testing

Two approaches of Incremental testing:

Bottom-up

In this testerhave to write own modules called test

drivers, that test the modules. Drivers sends test case

data to the modules under test & read back the result

A

B C


13/32

Integration testing

Top-Down

Rather than test the particular module which depends on

some other value, it could better to write a small piece of

code called stub that just like act as a interface module

which takes values from file directly to display the

module

A

B C


14/32

System testing

As the units are tested and the low-level bugs are found andfixed, they are integrated and integration testing is performed

against group of modules, this process of incremental testingcontinues putting together more and more pieces of softwareuntil the entire product or at least a major portion of it is nottested at once in a process is called system testing.


15/32

System testing

Different types of system testing

Load testing

Execution of a system in ideal condition

Subjecting a system to represent staticallyrepresentative load

E.g. no. of users apply for system is supposed to 50.

Stress testing

Running the software under less than ideal condition. E.g. Low memory, low disk space, increase no. of users.


16/32

System testing

Performance testing

To check the performance of a software it we apply load

and while stress the system.

Security testing

It attempts to verify that protection mechanism built into

a system will protect system from improper penetration.

Recovery testing

To determine whether the system or program meet its

requirements for recovery after failure.


17/32

Acceptance testing

It is the process of combining the end product to thecurrent needs of its user

It is usually performed by customer or end user aftertesting group satisfactorily completed usability,integration, system testing.

Alpha testing At developer site by customer

Beta testing At one or more customer sites by end user.

Final Candidate testing Testing before final release


18/32

Other testing types

Functional Testing

It is a process of attempting to detect discrepancies

between programs functional specification & its actual

behavior

It include positive & negative scenarios

Regression Testing

It is a re-execution of some or all of the test develop for

each build of the application verify that changes or fixes

have not introduce new problems.

It may perform for each activity


19/32

Test plan

Test

An activity in which system or component is executed under

specified conditions, the result are observed or recorded &

an evaluation is made on some aspect of the software.

A set of one or more test cases

Test Case

Test case is a document that describe an input, action or

event & an expected response to determine if feature of an

application is working correctly.

A set of test inputs, execution conditions & expected result.


20/32

Test plan

Test case component

Test case id

Test case name

Purpose or objective

Steps

Expected result

Actual result

Pass or fail

Prerequisite

Set up / Initial condition

Input data


21/32

Test plan

Test Plan

It is the process of defining a testing project such that it can

be properly measured& controlled The test strategy identifies multiple test levels, which are

going to be performed for the project.

Activities at each level must be planned well in advance andit has to be formally documented.

Based on th

e individual plans only, th

e individual test levelsare carried out.


22/32

Test plan

1. BACKGROUND

This item summarizes the functions of the application

system and the tests to be performed.2. INTRODUCTION

3. ASSUMPTIONS Indicates any anticipated assumptionswhich will be made while testing the application.

4. TEST ITEMS - List each of the items (programs) to be

tested.5. FEATURES TO BE TESTED - List each of the features

(functions or requirements) which will be tested ordemonstrated by the test.

6. FEATURES NOT TO BE TESTED - Explicitly lists eachfeature, function, or requirement which won't be tested and

why not.


23/32

Test plan

7. APPROACH - Describe the data flows and test philosophy.Simulation or Live execution, Etc. This section also mentions allthe approaches which will be followed at the various stages of the

test execution.8. ITEM PASS/FAIL CRITERIA Blanket statement - Itemized list of

expected output and tolerances

9. SUSPENSION/RESUMPTION CRITERIA - Must the test run fromstart to completion?Under what circumstances it may be resumed in the middle?Establish check-points in long tests.

10. TEST DELIVERABLES - What, besides software, will bedelivered?Test reportTest software


24/32

Test plan

11. TESTING TASKSFunctional tasks (e.g., equipment set

up) Administrative tasks

12. ENVIRONMENTAL NEEDSSecurity clearance Office

space & equipment Hardware/software requirements


25/32

Test plan

13. RESPONSIBILITIES

Who does the tasks in Section 10?

What does the user do?

14. STAFFING & TRAINING

15. SCHEDULE

16. RESOURCES

17. RISKS & CONTINGENCIES

18. APPROVALS


26/32

Test plan

1) When desired no. of test cases have been

executed

2) All identified defects have been addressed

3) When cost of testing outweigh (be more

important than) potential cost of not fixing a bug

4) When we are confident that the system works

correctly.

5) Depends on the risk of the system.


27/32

Test plan

Which Test cases to Automate Test that need to be run for every build of the web site

(Sanity, regression etc.) Test that use multiple data values for the same actions

(Data Driven Test)

Identical test that need to be executed using differentbrowsers

Test that require detailed information from applicationinternals

Multi-user scenarios

Stress/load


28/32

Test plan

Which Test cases could not to automate

Usability Testing One time testing

Ad-hoc or random testing

Test without predictable result.


29/32

Test plan

Test Automation is the process where we can

execute test cases using automation tool.

Test cases are executed & instant result of the test

case is displayed.

In test automation tools are used to log the status of

the particular control on screen

It create test script called TSL.

It saves time


30/32

Test plan

Following are benefits of Automation Speed

Repeatability

Coverage

Reliability

Reusability

Programming capabilities

Cost

Batch execution

Overnight run


31/32

Test plan

Testing Tools & Defect Tracking Tools :

Win runner

Test Director Load runner

QTP

Open STA

Silk Test

QA Load

QA Run

Silk Performer

Test Complete

WAST (Web Application Stress Tool)


32/32

Test plan

Following are the fields used in defect report Summary

Priority Severity

Date

System Information

Detailed Description

Status

Assign to Reproducible

Detected in version

Detected by

Screen prints

Date post:	06-Apr-2018
Category:	Documents
Upload:	dhananjay-kumar
View:	227 times
Download:	0 times

Ch 5 Software Testing Techniques

Documents