MELJUN CORTES JEDI Slides-6.4 Testing the System

7/29/2019 MELJUN CORTES JEDI Slides-6.4 Testing the System

1/13

Software Engineering 1

Software Testing

Testing theSystem

TOPIC FOUR


2/13


System Testing

After integration testing, the software is tested as a whole forfunctionality and fitness of use. This may include:

Performance Testing. It is designed to test the run-time

performance of the software. It is often coupled withstress testing to determine how computing resources areutilized.

Stress Testing. It is designed to execute software in amanner that uses resources in abnormal quantity,

frequency or volume.


3/13


System Testing

Security Testing. It is designed to test the protectionmechanism of the software so that improper use andpenetration are avoided.

Recovery Testing. It is designed to test the recoverymechanism of the software when it fails. When recoveryof the software is automatic, the test is performed on re-initialization of the system and data recovery. If therecovery requires human intervention, the mean-time-to-repair is evaluated


4/13


Steps in Generating System

Test Cases1. Using the RTM, prioritize use cases.2. For each use case, create use case scenarios.

3. For each scenario, take at least one test case and identify

the conditions that will make it execute.4. For each test case, determine the data values.


5/13


STEP 1: Prioritize use cases.

The importance of the use case may be gauged based onthe frequency it is used. As an example, the RTM that willbe used is shown below. Each of the requirement uses theMoSCow Technique to determine the prioritization.

RTM ID Requirement Notes Requestor Date Priority

Use Case

1.0

The system should be able to

maintain an athlete's

personal information.

RJCS 06/12/05Should

Have

Use Case

2.0


allow the coach to change

the status of an athlete.

RJCS 06/12/05Should

Have

Use Case

3.0


view the athlete's personal

information.

RJCS 06/12/05Should

Have

Use Case

1.1


add an athlete's record.RJCS 06/13/05

Should

Have

Use Case

1.2


edit an athlete's record.RJCS 06/13/05

Should

Have


6/13


STEP 2: For each use case,

create use case scenarios. The list of scenarios should include the basic flow and at

least one alternative flow. However, more alternative flow isrecommended. The following is the scenario set for addingan athlete record.

Scenario ID Scenario Name

SCN-01 Adding an Athlete Data Successfully

SCN-02 Athlete Data is Incomplete

SCN-03 Athlete Data is Invalid

SCN-04 Duplicate EntrySCN-05 System Unavailable

SCN-06 System Crashes during Input


7/13


STEP 3: For each scenario,identify the conditions that

will make it execute. Identify the input variables and constraints that bring the

system to a specific state. The following is an example TestCase Matrix for adding an athlete record.

Test Case

IDScenario

Athlete

Data

Not Already in the

Athlete DatabaseExpected Result

TC-01Adding an Athlete Data

SuccessfullyV V

Display message

athlete record added.

TC-02Athlete Data is

IncompleteI V

Error message:

Incomplete Athlete

Data.

TC-03 Athlete Data is Invalid I VError message:

Invalid data

TC-04 Duplicate Entry V I

Error message:

Athlete record already

exists.

TC-05 S stem Unavailable V IError Message: System


8/13


STEP 4: Determine the data

values. Test data is needed to test the functionality of the system.For each test case, identify the test data. The matrix belowis an example of test data for adding an athlete record.

Test Case

IDScenario Athlete Data

Not Already in

the Athlete

Database

Expected Result

TC-01Adding an Athlete

Data Successfully

Johnny De la Cruz

Lot 24 block 18 St.

Andrewsfield, Quezon City

24/9/1998

Male

Status

Guardian:

Johnny De la Cruz, Sr.

-same address-

555-9895

V

Display message

athlete record

added.

TC-02Athlete Data is

IncompleteNo guardian V

Error message:

Incomplete

Athlete Data.


9/13


Validation Testing

It starts at the culmination of system testing.

It consists of a series of black-box test cases thatdemonstrate conformity with the requirements.


10/13


Validation Criteria

It is a document that contains all user-visible attributes of thesoftware.

If the software exhibits these visible attributes, then, thesoftware complies with the requirements.

It is derived from work products produced during therequirements engineering phase.


11/13


Alpha & Beta Testing

It is a series of acceptance tests that enables customers andend-uses to validate all requirements.

Alpha-testing is conducted at the developer's site.

Beta-testing is conducted at the customer's site.


12/13


Regression Testing

It is a re-execution of some subset of tests to ensure thatchanges have not produced unintended side effects.


13/13


Summary

Software Testing Steps in Generating System Test Cases

Validation Testing and Validation Criteria

Alpha & Beta Testing

Documents

MELJUN CORTES JEDI Slides-6.4 Testing the System