1. Software Testing Science EXPERIENCE OF TESTING GUI APPLICATIONS IN A RAD ENVIRONMENT Graham Thomas Software Testing Science

2. CONTENTS l Background l What is RAD? l Experience of RAD ! l What is the impact of RAD? l Recommendations

3. Software Testing Science BACKGROUND l Large RAD project l Project Office l Incident & Problem Management l Change Control l Configuration Management l GUI Testing Automation

4. Software Testing Science WHAT IS RAD ? l Iterative development l Prototyped deliverables l Hands-off trust l Minimum documentation l Interactive on-line decision making l User participation l Time boxing

5. Software Testing Science RAD is Not ! l A QAD (Quick And Dirty) approach l A thorough or detailed methodology l A cook-book approach

6. Software Testing Science EXPERIENCE OF RAD l Documentation l Standards l Ownership l Change Control l Hand-over Acceptance Criteria l Problem/Incident Management l Configuration Management

7. Software Testing Science Documentation l Little documentation is produced l It is never early l Often in draft form l Has a high degree of redundancy l Implicit documentation is produced l Sometimes incomplete

8. Software Testing Science Standards l Few and far between l Not adhered to l Not enforced l Slow down the RAD process l Tendency towards guidelines within ground rules

9. Software Testing Science Ownership l Devolved through empowerment l The builder becomes the owner l Leads to fiefdoms l Hampers change

10. Software Testing Science Change Control l Difficult to administer & control change l Devolved ownership leads to a matrix approach RADTRAD

11. Software Testing Science Hand-over Acceptance Criteria l Hand-over only happens once in RAD, at the end of the iterative build cycle l RAD acceptance criteria l Will the system realize the proposed benefits l Has RAD cut costs l Has RAD reduced development time

12. Software Testing Science Problem/Incident Management l The requirement for an Incident/Problem Management System was driven by Testing l The RAD approach is not geared to fixing faults found during testing

13. Software Testing Science Configuration Management l Addressed too late l Uncertain what the system will contain until the build is complete l The iterative nature of RAD makes it difficult to decide when to baseline l Traceability through the lifecycle is not a key element of RAD l Code version control is a must

14. Software Testing Science WHAT IS THE IMPACT OF RAD? l The foundations that we have traditionally based structured testing upon no longer hold true l Baselined Requirements, Analysis & Design l Measurement of completeness l Validation of the conversion process l Producing error free software

15. Software Testing Science Timescales l Structured Testing looks out of place in a RAD lifecycle l Testing is targeted as a high cost & critical activity 40%+ RAD 25% WATERFALL Testing

16. Software Testing Science Testing Methodology l RAD projects end at the bottom of the structured testing V because testing is incorporated within the build iterations RADStructured

17. Software Testing Science RECOMMENDATIONS l Incorporate all levels of testing within the build cycle l Requirements l Functionality l Task level l Develop a release philosophy l Establish a candidate l Regress changes which don't work

18. Software Testing Science Recommendations l Realize the benefits of automation l Plan to build an automated regression test pack l Use the inherent resilience qualities of today's automated test tools to minimize the impact of change l Test all changes with the full regression test pack l Provide direct testing feedback

19. Software Testing Science SUMMARY l A Structured testing approach will not work in a RAD environment l Change your testing process and expectations l Test more of the product more often l Be prepared for change l Don't forget to Monitor your results