ORIENTATION TO TEST DIRECTOR

1. ORIENTATION TOTEST DIRECTOR Presentation for the MOSES Steering Committee January 12, 2006

2. What is Test Director? • Application Management and Defect Tracking Software used by IT for all applications – a Mercury product • Used to manage the application development and change process from inception to implementation by program and cost category • Name given to weekly meetings of IT and MOSES business analysts to review, prioritize and assign work tasks related to the maintenance, updating, or modification of the MOSES family of applications MOSES Steering Committee

3. Some Basic Terms • TD – Short-hand for Test Director • Bug/Defect – A feature or component that is not working properly • Enhancement – A change to or new feature or component that is not essential to the system’s operation or is not required, but may represent an improvement • Build – An updated version of the MOSES desktop staff view or of a web application incorporating specific changes • Patch – A Build distributed to correct a fatal error MOSES Steering Committee

4. How Do Items Get Into Test Director? • Local users call or email the Help Desk alerting us to bugs in the system or to suggest improvements • Help Desk staff identify bugs or recommend changes • Analysts, programmers and trainers identify bugs or recommend improvements • Program or administrative staff identify bugs or required changes (e.g., federal reporting, policy, DWD/state initiative e.g. re-branding, changes in EAS contract) or suggest improvements • Items also are logged into TD that require or result in staff assignments or work completed by MOSES IT or Sys. Dev. personnel outside the TD meeting structure (e.g., off hour calls related to production issues, work on web servers, urgent WTF item that arise between TD meetings) MOSES Steering Committee

5. Who Meets Regularly to Review Test Director Items? • Marilyn Boyle – Lead Sys. Dev. • Tom Keefe – Lead IT for MOSES • Joan Boucher – Business Analyst • Les Abramowitz – Business Analyst • Eddie Zhang – Business Analyst • Maryann Carroll – Business Analyst • Peggy Colligan – Testing, Training, Help Desk • Terri Bruce – NEG, Former CC Staff • Peg Ryan – (Central Operations Programs) • Others As Needed (e.g., TD meeting devoted Trade) • Local Representatives – Pending MOSES Steering Committee

6. What Is Considered to Determine Appropriate Action on a TD Item? • Are we dealing with a fatal flaw in the system? • Are we dealing with a bug or required change? If yes, does it need an immediate build (6-8 weeks), or can it wait for the next scheduled build (could be several months in the future)? • Is this really an enhancement that can be put on hold? • Has it been fixed but not closed in TD? • Should this be done at all – if not, then close? • Do we have enough information to evaluate item? MOSES Steering Committee

7. What is the Process for Reviewing Test Director Items? • Review New and Pending Items • Move Item to Appropriate Status • Hold • Need More Information – Assigned to Analyst • Assigned to Developer – Assign Build # • Future Enhancement • Dropped or Duplicate • Fixed • Request Time/Cost Estimate • Test Status (Ready for Testing, Tested OK, Tested Failed) • Closed • Review Open Items (Need More Info, Items Designated for Next Build, etc.) as Time Permits MOSES Steering Committee

8. How Many Items Are in Test Director? • TD Items Since 2000 = 6179 • FY 06 TD Items To Date = 367 • Current TD Items = 507 MOSES Steering Committee

9. Test Director Items Since 2000 MOSES Steering Committee

10. FY 06 Test Director Items MOSES Steering Committee

11. Current Test Director Items MOSES Steering Committee

12. What is the Change Process? • Proposed Change identified • Draft Business Rules Developed by Analyst • TD Items Created • Draft Business / System Rules Provided to IT for Review/Acceptance • Final Business / System Rules Accepted • Development / Unit Testing • Test Build(s) Created • Testing  - Individual Build Items • Testing, Correcting, Retesting Completed • Final Test Build Created • Regression Testing of Entire System (2-4 Weeks Prior to Release) • MOSES Notice to Users Prepared • Training Needed – Develop Instructional Materials • IT Lockdown/Production Build • MOSES Notice to Users Sent 2 Weeks Prior to Release           • Release to Field – On Desktop • Training and User Documentation Delivered MOSES Steering Committee

13. When Are Builds Needed? • MOSES staff view/desktop changes require a build distributed to each user’s desktop • Builds for web application changes involving just web features follow a different build deployment (e.g., WTF) • Since all applications use the same data base and sometimes have parallel or common features (e.g., registration by CC staff and registration by job seekers on MJQ, TAARRNEG) changes may be needed in both the staff view and web portions • Changes that can be handled “behind the scenes” (e.g., data base changes or batching data for federal reports) do not require a build MOSES Steering Committee

14. Why Do We Need Local Representatives at TD Meetings? • To help evaluate the relative priority of TD items • To insure a local perspective related to CC business processes and use of MOSES • To advise on the nature of changes – what will work best • To advise on training or instruction needed by CC management and staff MOSES Steering Committee

15. What Characteristics Would Make a Good Local Representative? • Familiar with MOSES • Familiar with office processes • Familiar with workforce programs • Detailed oriented, logical thinking • The ability to understand and willingness to participate in the entire change process (not just an interest in their own CC needs) MOSES Steering Committee