SPRAEA Framework for

Teaching Software Testing

Edward L. JonesFlorida A&M University

Purpose

• Software testing is neglected in curriculum

• Students miss out on surprising benefits from not learning to test

• An approach to integrating testing into the undergraduate curriculum.

• Approach is based on a few, simple principles

Outline

• Problem: Testing in the curriculum.

• Past FAMU Approaches

• FAMU Software TestLab Initiative

• The SPRAE Framework & Example

• On-Going Work

• Conclusion

The Problem

Building Testing

0

50

100

0

50

100

Building Testing

0

50

100

0

50

100

INDUSTRY

In Industry: Testing is 50% of software cost!

The Problem

In the University: Where’s the Beef?

Building

Testing0

50

100

0

50

100

UNIVERSITY

Why No Testing?• Heredity – teacher not trained

• No room in curriculum

• Attitude

• Digression from the fun part

• A necessary evil

• Not as important as creative part

• TESTING is HARD!!

Why Change?

• Testing integrates software skill sets

• Analysis … Logic … Writing

• Design … Programming

• Experimentation

• Testers make better software engineers

Past Approaches• Testing in senior courses (ad-hoc)

• Elective course offered in 1999

• Goal = integrate into all courses

• TestLab = training/dissemination environment

• SPRAE = essential principles/practices

TestLab: Big Picture

• Marketing • Proposals

Support ($$)

Curriculum

Students

SoftwareTestLab

ResearchPublications

Corporate Sponsors

SPRAE Principles

SSpecification – no spec, no test

PPremeditation – follow a process

RRepeatability – write down actions

AAccountability – record results

EEconomy – save labor, don’t skip steps

SPRAE Test Life Cycle

Design

Implementation

Execution

Evaluation

Analysis

Testing uses software development skills.

Example - Pay (S)

Specification: Compute pay for an employee, given Hours worked and hourly pay Rate; overtime is 1.5 times hourly Rate, for Hours above 40.

Hours

Rate

PayComputePay

Principle P

Premeditation: Use a systematic process to devise test cases based on the specification.

One Technique:• Decision analysis -- identify behaviors• One test case per behavior• Determine expected result

Example - PayTest Case Design: Decision Table. Columns identify behaviors to test.

Decision Table Behaviors

Hours > 40 Y N Conditions

Pay = Hours * Rate X Actions

Pay = 40 * Rate + 1.5 *Rate * (Hours – 40)

X

10 10 Rate

40 50 Hours

400 550 Expected Pay

Test Cases 1 2

Principle R

Repeatability: Processes for test case creation and test execution must yield equivalent results, independently of the tester.

Principle AAccountability: Records must be kept that document the test process and its artifacts.

Documentation answers:• What tests were planned?• Which tests were conducted?• Who did what testing, and when?• What were the results?• How were the results interpreted?

Example - PayRepeatability/Accountability:

Test Script Test Log

User Action: Enter

ExpectedResult Test ID /Outcomes

Step Rate Hours Pay 01 021 10 40 400 P P2 10 50 550 F P

Error/Discrepancy LogTest Step Description

01 2 Result Pay=500. OT not calculated.

Principle EEconomy: Test activities must not require excessive time or effort.

• Automation

• Test drivers (classical tool)

• Simplified processes for

• Test case generation

• Data collection

Why SPRAE?• “SPRAE” is a mnemonic for essentials

• Through one testing experience, students learn the key principles

• These principles transfer to new test experiences

• SPRAE explains the “what and why”

• A framework for life-long learning.

On-Going Work

• Modules for Fall 2000 courses • Software Engineering

• Data Structures

• Train students

• TestLab infrastructure

• website: www.cis.famu.edu/~testlab

Conclusions

• Software testing need not be neglected in curriculum.

• No need for a “big bang” approach.

• Testing can be integrated into the curriculum incrementally.

• Students realize far-reaching benefits from even simple testing experiences.