EXPERIENCE OF TESTING GUI APPLICATIONS IN A RAD ENVIRONMENT

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

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

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

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

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

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

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

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

9. Ownership • Devolved through empowerment • The builder becomes the owner • Leads to fiefdoms • Hampers change

10. Change Control RAD TRAD • Difficult to administer & control change • Devolved ownership leads to a matrix approach

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

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

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

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

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

16. Testing Methodology RAD Structured • RAD projects end at the bottom of the structured testing V because testing is incorporated within the build iterations

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

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

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