1. SPRAE A Framework for Teaching Software Testing Edward L. Jones Florida A&M University

2. 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

3. Outline Problem: Testing in the curriculum. Past FAMU Approaches FAMU Software TestLab Initiative The SPRAE Framework & Example On-Going Work Conclusion

4. 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!

5. The Problem In the University: Where’s the Beef? Building Testing 0 50 100 0 50 100 UNIVERSITY

6. 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!!

7. Why Change? Testing integrates software skill sets Analysis … Logic … Writing Design … Programming Experimentation Testers make better software engineers

8. 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

9. TestLab: Big Picture Marketing Proposals Support ($$) Curriculum Students Software TestLab Research Publications Corporate Sponsors

10. SPRAE Principles S S pecification – no spec, no test P P remeditation – follow a process R R epeatability – write down actions A A ccountability – record results E E conomy – save labor, don’t skip steps

11. SPRAE Test Life Cycle Design Implementation Execution Evaluation Analysis Testing uses software development skills.

12. 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 Pay Compute Pay

13. 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

14. Example - Pay Test Case Design: Decision Table. Columns identify behaviors to test.

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

16. Principle A Accountability: 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?

17. Example - Pay Repeatability/Accountability:

18. Principle E Economy: Test activities must not require excessive time or effort. Automation Test drivers (classical tool) Simplified processes for Test case generation Data collection

19. 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.

20. On-Going Work Modules for Fall 2000 courses Software Engineering Data Structures Train students TestLab infrastructure website: www.cis.famu.edu/~testlab

21. 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.