1. Cash Doctor 3.0 Mobile Application
Team 12
Transition Readiness Review

2. TRR Outline Introduction Demo QA Transition & support plan Test result
Traceability
Definition of done (transition objective)
Metrics
Technical debt
Transition & support plan

3. Operational Concept Overview
Mobile Application that provides
Doctor information to people who are looking for medical services
Allow users to rate and review healthcare providers
Allow provider to post and update their service information

4. Danny Lee, Kenneth Anguka, Shreya Sharma
Test Plan and Cases
Danny Lee, Kenneth Anguka, Shreya Sharma

5. Detailed Test Cases and Plans
Continued writing detailed, low-level test cases and plans
At last ARB had coverage for:
Login, Share, Search
Now have coverage for:
All modules (networking, add provider, provider profile)
Have been used to thoroughly test the high-level test cases

6. Automation Testing
Continued use of Selenium as our automated test framework
Pros: Easy way to run sanity each time after any changes goes in.
Cons: after CCD, unstable code requires constant updating of automated test code.
Allows rapid testing of multiple features

7. Test Procedures Unit testing performed by all developers
Functional testing performed by dedicated testers
Automation testing via Automation Engineer using Selenium
Acceptance testing performed by client at CCD

8. Test Cases Use Case Test Case
UC1/10: Register/Login as consumer/provider
TC-05, TC-08
UC3/12: Edit profile
TC-15
UC4: Share Prices
TC-01, TC-07
UC5: Search providers
TC-04
UC6: Follow providers
TC-21
UC7: Rate/Review Provider
TC-12, TC-09
UC9: Add new provider
TC-09

9. Test Results Main functionality is working
Share, Search, Follow Provider (Networking)
UX and validation needs polish
UI still being optimized
User survey with sanitized product shows users are enjoying the current design with an average of 4.03 rating on a 1-5 scale (with 5 being highest)

10. Regression Test Criteria
Highest Priority Win Conditions
Repeatable Tests
Broad Functionality Range

11. Types of Regression Tests
Bug Testing
Functionality Testing
Configuration Testing
Localization Testing
Smoke Testing

12. Regression Tests For change in Share Capability rerun Test Cases:
TC , TC , TC , TC , TC-13-03, TC through TC , TC through TC
For change in Profile Capability rerun Test Cases:
TC through TC-15-13
For change in Search Capability rerun Test Cases
TC through TC

13. Regression Tests For change in Networking Capability rerun Test Cases:
TC-19-01, TC-19-02, TC-11-01, TC-11-02,
TC through TC
For change in Consumer Registration Capability rerun Test Cases:
TC through TC-08-06
For change in Password Update Capability rerun Test Cases
TC through TC

14. Regression Test Status
Each release build will be tested against this set of regression tests
Currently passing the majority (15/18 tests) with 1 partial pass, 1 not yet tested, and 1 that cannot be tested due to back end constraints

15. Ekasit Jarussinvichai
Metrics
Ekasit Jarussinvichai

16. Traceability Matrix Capability Goals Win-conditions Use Cases
Test Case
OC-1 Manual Information Search
WC_3084
UC5 Search healthcare info.
TC-04 Keyword search
OC-2 Geo-Location Search
WC_3084 WC_3094
TC-10 Geo-location search
TC-14 Geo-location accuracy
OC-3 User Registration
WC_3085
WC_3086
UC1 Create/Login consumer account UC11 Create/Login provider account
TC-05 User login
TC-08 User registration
OC-4 Price Sharing
WC_3082
WC_3083
UC4 Share prices
UC10 Add new provider
TC-01 Share invoice image
TC-13 Share prices
OC-5 Provider Rating
WC_3089 WC_3091
UC8 Rate/review a provider
TC-09 Review provider
TC-12 Rate provider
OC-6 Networking
WC_3087
WC_3088
UC2 View dashboard
UC6 Follow/unfollow a provider
TC-21 Follow/remove provider
OC-7 Profile Management
WC_3186
UC3 Edit consumer profile
UC13 Edit provider profile
TC-15 Edit profile

17. Win-condition Delivery
Description
WC_3082
An user can capture an image and code an invoice for sharing.
WC_3083
A consumer can manually enter price information for sharing.
WC_3084
A consumer can search for healthcare pricing, provider by location, price, code, specialty
WC_3085
System shall integrate with the existing database at Cash Doc.
WC_3086
As a consumer, I can register as a user.
WC_3087
As I consumer, I can access my existing account by user ID and password, and can view my existing dashboard.
WC_3088
As a consumer, I can create a private network and join existing networks.
WC_3089
As a consumer, I can create a review of a provider.
WC_3091
As a consumer, I can rate a provider.
WC_3094
As a user, I can find my current location to access relevant providers in and around area (some mile radius).
WC_3186
As a user, I can create a health profile that will attach profile specific offers from providers
91 % of win-condition are covered

18. Test Cases Coverage 91% of test cases are executed Test Case
Description
Status
TC-01
Share invoice image
Tested
TC-04
Keyword search
TC-05
User login
TC-08
User registration
TC-09
Review provider
Not Test
TC-10
Geo-location search
TC-12
Rate provider
TC-13
Share prices
TC-14
Geo-location accuracy
TC-15
Edit profile
TC-21
Follow/remove provider
91% of test cases are executed

19. Defect Current Status 85 bugs found since RDCR ARB
74 bugs are resolved
5 bugs are invalid
6 bugs are in progress to resolve
195.7 estimated hours of work
189.7 actual hours of work

20. Defect Statistical Data
# of Bugs Resolved
Average Days Open / bug
Average Hours / bug
Std Dev Hours
January 1
1 day
6 hours -
February 25
6.7 days
3.1 hours
3.3 hours
March 31
7.3 days
1.7 hours
4.4 hours
April 28
16.3 days
2.6 hours
4.8 hours

21. Effort Statistic

22. Support Plan 22

23. Support Plan
The system has been tested locally by the development team and it is working.
After initial deployment at the end of the semester, the team will not be responsible for new releases.
Deployment and further bug fixes will be the responsibility of the client.
We will provide a user manual to assist in this process.

24. Definition of Done All modules must be implemented and team-reviewed
Negotiated win conditions must be met
All bugs in bugzilla must be resolved
All test cases passed and core features delivered
The product code should be documented to explain functionality and unusual methods, authors of pages, and mapped win conditions
Transition of code documents and accounts from USC team to current Cash Doctor development team should be completed. This means removal of all code from USC team machines, transition of maintainable code to the Cash Doctor team, and deployment on iOS and Android app stores.
All stakeholders satisficed in terms of agreed upon win conditions.

25. Transition Plan 22

26. Transition Concerns There are a few bugs in the backend system.
There are some features that client want are not support by backend system.

27. Transition Objective
Developers is going to deliver the product with full operation with all functions that client had agreed. It didn’t complete all the requirements on the win win negotiations, but client agreed that some of these requirements can be implemented in the futures after backend team improves backend support.

28. Transition Strategy Delivery method depends on clients preference.
All deliverables will be made into physical products and deliver to client on the decided date.
All deliverables will be uploaded on team website and client will be provided with the link to download.
All the source codes will be uploaded to assembla, which is a git management site.

29. Hardware Preparation
Since client has already had server and backend support for website, so no new hardware need to be purchased.
An computer with operating system Ex: Windows, Mac

30. Software Preparation
The packaging of software would be in form of APK/IPA(Android and IOS installation file) and script files
Intel XDK
Android and IOS

31. Site Preparation No specific site preparation is required
A desktop or laptop with the mentioned requirements
No staff required

32. Transition Schedule

33. Lessons Learned
Discover all stakeholders before entering Win-Win negotiations
Initially unaware of third-party
Third-party clearly a stakeholder in this project
Certain win conditions acceptable to front end team and client, but not possible for back end team.
Be more active about renegotiating Win conditions when obstacles arise
Wanted to deliver best possible product to client.
Rather than waiting for new capabilities to be developed, renegotiate early and recommit later if capabilities become available
Test on multiple devices earlier