Cash Doctor 3.0 Mobile Application Team 12 Transition Readiness Review

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

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

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

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

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

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

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

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)

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

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

Regression Tests For change in Share Capability rerun Test Cases: TC-01-01-01, TC-13-01-01, TC-07-01-01, TC-07-01-02, TC-13-03, TC-13-02-01 through TC-13-02-03, TC-13-03-01 through TC-13-03-03 For change in Profile Capability rerun Test Cases: TC-15-01 through TC-15-13 For change in Search Capability rerun Test Cases TC-04-01-01 through TC-04-01-08

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

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

Ekasit Jarussinvichai Metrics Ekasit Jarussinvichai

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

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

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

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

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

Effort Statistic

Support Plan 22

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.

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.

Transition Plan 22

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

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.

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.

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

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

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

Transition Schedule

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