swe © solomon seifu 2010 1 construction. swe © solomon seifu 2010 2 lesson 13-2 testing

SWE © Solomon Seifu 2010 1

CONSTRUCTION


Lesson 13-2Testing

SWE © Solomon Seifu 2010

SWE: Construction - Testing

Classical software life-cycle models all too frequently included a separate testing phase, after integration and before post-delivery maintenance

Nothing could be more dangerous from the viewpoint of trying to achieve high-quality software

Testing is an integral component of the software process and an activity that must be carried out throughout the life cycle

3


SWE: Construction - Testing (Cont.)

During the requirements workflow, the requirements must be checked

During the analysis workflow, the specifications must be checked, and the software production management plan must undergo similar scrutiny

4


SWE: Construction - Testing (Cont.)

The design workflow requires meticulous checking at every stage

During implementation workflow, each code artifact certainly must be tested and the product as a whole needs testing when it has been fully integrated

After passing the acceptance test, the product is installed and post-delivery maintenance begins and hand in hand with maintenance goes repeated checking of modified versions of the product

5


SWE: Construction - Testing (The Big Picture)

Function

Module

Module combination

Include use cases

3. System Test

2. Integration Test

1. Unit Tests

Methods

Combinations of

methods in class

Packages of classes


SWE: Construction - Testing (Test Workflow in Unified Process Model)

Testing takes place in all phases Primarily when each build is integration and

system tested Elaboration when building baseline

architecture Construction, particularly latter part

Integration tests for every build within an iteration System tests at end of an iteration


SWE: Construction – Testing (The Lifecycle)

PlanTest

Execute Test

Defect Tracking

ImplementTest

DesignTest

Build Build

ImplementationAnalysis &Design

RequirementsCapture

Development Lifecycle

ProjectPlanning

Test Lifecycle

Evaluate Test


SWE: Construction – Testing (Iterations)

Iteration n

Iteration n + 1

PlanTest

Execute Test

Defect Tracking

ImplementTest

DesignTest

Build Build

ImplementationAnalysis &Design

RequirementsCapture

Development Lifecycle

ProjectPlanning

Test Lifecycle

Evaluate Test

Iteration n+2


SWE: Construction – Testing (Iterations)

(Cont.)

Tests evolve in iterationsIteration # n

Tests in iteration

Iteration # n + 1

Iteration # n + 2


SWE: Construction – Testing (Test Stages)

Unit testingEarliest stage of testingFocused on smallest testable componentsPerformed by Implementer

Integration testingSoftware units combined and tested -- but not

all external components are included at this stage

Performed by Tester


SWE: Construction - Testing

(Test Stages) (Cont.) System testing

Application is functioning as a whole, integrated with all external components

Performed by Tester Acceptance testing

Users determine fitness for deploymentPerformed by users


SWE: Construction - Testing (Types of Tests)

Security Business function/rules User interface Performance: response time Configuration: different hardware/software Installation Documentation


SWE: Construction - Testing (Types of Tests [Security Testing])

Web-based systems necessitate high security because of their vulnerabilityAccess to applicationProtecting information stored or

displayedTransfer of files Intrusion detection


SWE: Construction - Testing (Types of Tests [User Interface Test])

Verifies the look and operation of UI Includes:

Look and feel Navigation Consistency Compliance to standards

Derived from: Supplementary specifications UI standards and guidelines


SWE: Construction - Testing (Types of Tests [Performance Test])

Verifies the response and processing time Includes:

End-to-end and/or specific subsystemsVarying system components to optimize response timeUse of a limited number of available application’s functions

Derived from supplementary specifications Examples:

Retrieve an existing customer’s account in less than x seconds.

Enter or process y transactions per z seconds


Test case is a written document developed for a specific test requirement that consists of:Test inputsExecution conditions -- state of application at

time of testExpected resultsVerification points (how to verify expected

results)

SWE: Construction - Testing (Creating Test Cases)


SWE: Construction – Testing (Functional Test Cases)

Use case scenarios, positive, alternate and negative

Business rules Sequencing of events or actions Special requirements

Minimum/maximum performanceMinimum/maximum loads or data volumes


Normal flow/condition – valid input

Alternative flow – other valid input (including warnings)

Exception flow – invalid input (unacceptable or unrecognizable)

SWE: Construction - Testing (Use Case Scenarios)


SWE: Construction - Testing (Types of Tests [Business Functions and Rules Testing])

Verifies that the software provides the expected services

Includes: Valid or positive conditions Invalid or negative conditions Business rules and workflow

Derived from: Use cases Supplementary specifications Activity diagrams


SWE: Construction – Testing (Business Rules [Example])

“If at any time within the statement period the account’s daily

balance drops below $2000.00, a fee of $5.00 will be charged

to the account for that month.”

Use Case: Monthly Statement ProcessesTest Type - Business rules

TC # Desc. Otherinfo.

ExpectedResult

Daily balance > fee balancevalue ($2000.00)

V No fee

Daily balance < fee balancevalue ($2000.00)

V Fee

Daily balance = fee balancevalue ($2000.00)

V No fee


SWE: Construction – Testing (Supplementary Specifications)

User interface Performance

Load Stress Volume

Security/Access Configuration Installation


SWE: Construction – Testing (User Interface Test Cases)

# Description NotesMenus All menus conform to standardsLabels All labels are consistent and

conform to standardsNavigation Buttons All buttons conform to standards

Test Type - User Interface

Object properties Standards/compliance Navigation


SWE: Construction - Testing (Performance Test Cases)

# Description Notes / ResultsInitiate transaction with card Card is read and validated < 2 sec.Communications with bank ATM initiates communication and

and bank responds < 6 sec.Complete transaction Transaction can be

completed in less than 20 sec.

Test Type - Performance

Performance boundaries/focus Performance constraints


SWE: Construction – Testing (Load Test Cases)

Test Type - Load

# Description Notes / ResultsWithdraw - 100 ATMs 100 ATMs interacting with bankWithdraw - 1,000 ATMs 1000 ATMs interacting with bankWithdraw - 10,000 ATMs 10000 ATMs interacting with bank

Load boundaries/focus Load constraints


Test Procedures

SWE: Construction – Testing (Creating Test Procedure)

Test procedures are detailed instructions for the setup, execution, and evaluation of a test case (or set of test cases)


Test procedure contents: Setup conditions/instructions Initial application and/or test procedure state Execution steps or tasks Input values Expected results and values Evaluation method Description of final state (of test procedure or of

application)

SWE: Construction – Testing (Structuring Test Procedures)


Advantages of a test procedure:Eliminates questions about what was

tested and howCan be used by others to execute

tests Can easily bring in additional people

during peak testing times

Can be used to verify that automated test scripts correct

SWE: Construction – Testing (Structuring

Test Procedures) (Cont.)


29

Test Procedure: CCWWNN11xxxx0011 -- nnoorrmmaall ffllooww 11,, sseelleecctt vvaalluuee ffrroomm lliisstt

Test Case(s) CWN1U201 - normal flow 1, selected value $20.00

Step Action Taken

0 Starting condition:

Account 810 3324 is valid PIN 6897 is valid for this account ATM displaying “Welcome … insert card to begin”

window Account has $6,350.92 in available funds No previous withdrawals made within 24 hours

SWE: Construction – Testing (Structuring Test Procedures [Setup condition Example])


Step Action Taken ValuesEntered

Expected Result Verification

Method1 Insert Card into card reader Card is “taken” into

ATM and read

2 Input PIN and push “OK”Button

6897 Account and PINinformation isconfirmed and“SelectTransaction”window displayed

Window

Existence(“SelectTransaction”window)

3 Push “Withdraw” Button “Withdrawtransactions”window isdisplayed

SWE: Construction - Testing (Structuring Test Procedures (Example) [Test Procedure Body])


Step Action Taken ValuesEntered

Expected Result Verification Method

4 Push “Quick Cash” Button “Quick Cash”Window is displayed

5 Push “$ 20.00” Button $20.00 “Transaction isbeing processed”window is displayed

Window Existence(“Transaction is …”window)

6 Take money, receipt, and card “Take money,receipt, and card”reminder window isdisplayed

7 Verify balance (manually) Account balance isnow $6330.92

manual

SWE: Construction – Testing (Structuring Test Procedures (Example) [Test Procedure

Body]) (Cont.)


Step Action Taken

999 End condition:

Account 810 3324 is valid PIN 6897 is valid for this account Account has $6,330.92 in available funds ATM displaying “Welcome … insert card to begin”

window

SWE: Construction – Testing (Ending Condition)


Test Plan Document


Test Cases Sample


SWE: Construction – Testing (Wholeness)

Software testing is the process of determining if a program has any errors

Software that doesn’t work can have a large impact on an organization and can lead to loss of money, loss of time, damage to business reputation and injury or death

Poor requirements, late defect identification, inadequate testing, manual testing etc. lead to common problems in testing

swe © solomon seifu 2010 1 construction. swe © solomon seifu 2010 2 lesson 13-2 testing

Documents

construction swe solomon

construction testing

iterationswe solomon

testingswe solomon seifu

needs testing

life cycle3swe solomon

software process

software lifecycle