team 1 health insurance management system (hims)
TRANSCRIPT
Team 1
Health Insurance Management System (HIMS)
Team Members
Allen Tucker Ashley Plier Tara Chengalvala Ibrahim Elsaeed Venkat Reddy Jakka Sundeep Yama
Agenda
Project Description Project Assessment Development Process Scheduling Team Organization Structure
Agenda (cont.)
Project Resources Test Strategy Example Tests Project Summary Lessons Learned
Project Description
Manage the human resources of a Health Care Maintainers Organization (HMO)
Web based access to health insurance database (emphasis on claims data)
Targeted Actors Members – Individual who has a plan in the system Employers – Employment source of members Providers – Doctors, physician, etc. Operator – Maintenance and management of the system
Project Assessment
The good… Use cases UML Models Design Rational (e.g. why certain aspects un-modeled)
The bad… Requirements management
Well written, but poorly enumerated
The ugly… Traceability – almost none present
Development Process
Begin post Inception phase
Borrow from Agile Test early, test often Continually integrate
Collaborative Behaviors User Account
Management Health Account
Management
Scheduling
Iterative Development Use Case Inception Elaboration Construction Transition
ID Title I1 E1 E2 C1 C2 C3 C4 T1 1 Authenticate ------ X
1.1 InvalidLogin ------ X 1.2 FirstLogin ------ X 2 ChangePassword ------ X
2.1 InvalidPassword ------ X 2.2 PasswordsDon’tMatch ------ X 3 ViewAccountInformation ------ X
3.1 PrivilegeNotGranted ------ X 3.2 InvalidUserID ------ X 4 UpdateAccountInformation ------ X
4.1 InvalidInformation ------ X 5 ViewRecentClaims ------ X
5.1 MemberPrivilegeNotGranted ------ X 5.2 InvalidMemberID ------ X 6 ViewList ------ X 7 SearchForMember ------ X
7.1 InvalidAccount ------ X 7.2 PrivilegeNotGranted ------ X 8 ViewRequestList ------ X 9 ProcessPlanEnrollmentRequest ------ X
9.1 EnrollmentDeny ------ X 10 Enable/DisableAccount ------ X 11 ResetPassword ------ X 12 RegisterMember ------ X
12.1 RequiredFieldMissing ------ X
Three week long iterations with use cases being divided up into behaviors.
Scheduling (cont.)
Weekly Schedule Use Case Elaboration 1 (E1) Elaboration 2 (E2)
ID Title June 8-14 June 15-21 June 22-28 June 29 – July 5 July 6-12 July 13-19 1 Authenticate X
1.1 InvalidLogin X 1.2 FirstLogin X 2 ChangePassword X 3 ViewAccountInformation X
3.1 PrivilegeNotGranted X 3.2 InvalidUserID X 4 UpdateAccountInformation X
Each week in an iteration focuses on a different use case.
Organizational Structure
Validation Team
Integration Team
Component TeamCode
Defects
Binaries
C(x) C(y) Stubs
Exe. DriversC(s)
Ver. 0.01
Organizational Structure
Validation Team
Integration Team
Component TeamCode
Defects
Binaries
C(x) C(y) Stubs
Exe. DriversC(s)
Ver. 0.01
• Unit and Component (package) level development
• Stubs
• “White Box” Testing
Organizational Structure
Validation Team
Integration Team
Component TeamCode
Defects
Binaries
C(x) C(y) Stubs
Exe. DriversC(s)
Ver. 0.01
• Integrating components for collaborative behaviors
• Drivers
• “White Box” Testing
Organizational Structure
Validation Team
Integration Team
Component TeamCode
Defects
Binaries
C(x) C(y) Stubs
Exe. DriversC(s)
Ver. 0.01
• Functional Testing
• Project Documentation
• “Black Box” Testing
Organizational Structure
Validation Team
Integration Team
Component TeamCode
Defects
Binaries
C(x) C(y) Stubs
Exe. DriversC(s)
Ver. 0.01
Project Resources
Development Environment: Netbeans 6.5 Implementation Language: JavaApache ANTEMMAJUNITVersion Control: http://code.google.com/Defect Tracker: http://code.google.com/Documentation: http://code.google.com/
Test Strategy
Use Case Driven Approach (Functional) Dependent on Traceability Data
Design models only
75% statement code coverage
Example Tests
Design Model Inspection
Functional Test Case (System Level Test)
Integration Test Case
Unit Test Case
Design Model InspectionGuided Inspection Model Under Test : Authenticate Sequence Diagram Tester : Ibrahim Elsaeed Evaluation Criteria Yes No N/A Correctness Does the model accurately describe the problem? X Does the model accurately describe the solution? X Does the model conform to the expected results? X Completeness Are all necessary and useful elements included? X Does the model have a well-defined increment scope? X Does the model sufficiently cover inspection of all use cases?
X
Can the results of the executing test cases be adequately represented using the contents of the model?
X
Consistency Are there different representations in the model of the same functionality?
X
Are there any contradictions or conflicts present either internal to a single diagram or between two diagrams?
X
Does the integration process ensure that the new piece does not introduce inconsistencies into the integrated model?
X
Tester Comments
1. The GUI is not sufficiently represented. 2. This model and nor any other subsequent sequence diagrams cover the invalid
login use case.
Functional Test CaseTestCases_V0.08 (10/16)
Test Case ID 1: Authentication Description This test case authenticates the user for logging into the system. Testing Environment/Configuration The user with the username “John” and with the password “password” should be stored in the Database. Initialization 1. The application has been started. Actions Steps Expected Results Pass/
Fail Actual Results
1. The user selects the “Login” menu option from the “File” menu.
A login dialog is shown on the screen.
Pass A login dialog is shown on the screen.
2. Type in “John” in the username text field.
“John” is displayed in the username text field.
Pass “John” is displayed in the username text field.
3. Type in “password” in the password text field.
“••••••••” is displayed in the password text field.
Pass “••••••••” is displayed in the password text field.
4. Select the button to submit the username and password to login to the system.
A dialog is displayed explaining that the login was successful.
Pass A dialog is displayed explaining that the login was successful.
5. Dismiss the success dialog. The success dialog is removed from the screen.
Pass The success dialog is removed from the screen.
Finalization None Tester Comments __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
Integration/Unit Test Organization
HIMS
Integration/Unit Test Organization
HIMS
• Package structure delivered in design
Integration/Unit Test Organization
HIMS
• Contains integration level code (and gui)
Integration/Unit Test Case
Integration/Unit Test Case
•Baseline testing within tester class’s constructor
Integration/Unit Test Case
•Error Guessing Technique
•Expected vs. Actual Comparisons
Project Summary
Natural grouping of features mandated schedule adjustments…(birds of a feather)
Project Summary (cont.)
Design Model Results GUI Design Work
Project Summary (cont.)
0%
20%
40%
60%
80%
100%
120%
14-J
un
15-J
un
16-J
un
17-J
un
18-J
un
19-J
un
20-J
un
21-J
un
22-J
un
23-J
un
24-J
un
25-J
un
26-J
un
27-J
un
28-J
un
29-J
un
30-J
un
1-Ju
l
2-Ju
l
3-Ju
l
4-Ju
l
5-Ju
l
6-Ju
l
7-Ju
l
8-Ju
l
9-Ju
l
10-J
ul
11-J
ul
Cove
rage
(%)
Timeline (Date)
Verification Test Coverage
Goal Coverage
Packages
Classes
Lines of Code (LOC)
Statement coverage inadequate
Moved to boundaries and error predictive methods
Project Summary (cont.)
HIMS_0.01 HIMS_0.02 HIMS_0.03 HIMS_0.04 HIMS_0.05 HIMS_0.06 HIMS_0.07 HIMS_0.08 HIMS_0.09
Total Passed 1 3 5 22 16 18 18 22 13
Test Count 5 5 5 26 16 19 19 32 13
0
5
10
15
20
25
30
35
Syst
em Te
st R
uns
Functional Test Analysis Defects
exists within the system.
Project Summary (cont.)
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Failu
re R
ate
Feature Based Failure Rates
Authentication
Change Password
Invalid Login
Update Account Information
View Account Information
Invalid UserID
Insufficient amount of functional regression testing for certain features.
Project Summary (cont.)
Personnel shifts due to deliverable deadlines
Outstanding Work Items Functionality (use cases not implemented) Defects
Lessons Learned
Guided inspection of models decrease wasted coding effort
White box statement coverage insufficient Adopt new strategy given chance to do complete
rework of project (e.g. boundaries, error guessing)
Flexible Team