Pt2520 Unit 3 Assignment

Assignment Description:

Develop a test strategy for testing the entire application chosen in unit 3 for analysis and design. Keep in mind that testing that involves users should minimize their time commitment while obtaining essential information from their involvement. Specifically define roles, responsibilities, timing, and test strategy for each level of testing.

Chosen Application and Testing Plan:

I chose the Dr. Patel’s Dental Practice System application for my assignments (Conger, 2008, p795). The system requirements include the ability for a financial transaction system, an appointment scheduling system, and management of patient information and medical records. The testing plan will be looking at different test levels; Unit, Subsystem,

Integration, System Tests, and Quality Assurance and Acceptance testing. Conger’s (2008) example and explanations of different test level testing strategies combine the last two levels of testing into one, system testing with Q/A and Acceptance testing, so I have done the same here. For each level I will discuss the roles involved with the testing being performed, what they will be responsible for during that level of testing, when that level of testing is occurring and anticipated time investment, and what combination of testing strategies will be applied at that level. There will be five main subsystems in the application for the requirements I have previously outlined from other assignments; financial, appointments, patient records, reminder system, and claim generation. At each level of testing, it would be expected that regression testing is performed when changes are made due to identified errors. The testing will be bottom-up testing with each level’s testing building upon the prior as development progresses with it. After going through the test levels, I will then give my thoughts on the overall testing process and anticipated strengths and weaknesses that may be present.

Test Levels
Unit Testing:
Roles:
The members of the development teams for each unit would be responsible for performing the unit testing upon whatever section of the application they are developing.
Responsibilities:
Assuming the application was being developed from an object-oriented design, which would be my recommendation, individual units being tested would be the objects and processes determined during the object-oriented analysis. Individual sections of code, such as a process for adding patient information or the appropriate function of a payment transaction would be tested here.
Timing:
Unit testing would be occurring progressively throughout the development of the application as each section is created. Once the unit is determined to meet the requirements further testing of it as a part of its greater subsystem will be performed at the next level.
In terms of length of time performing this testing, the individual units should be relatively short, but given that they are the baseline for the code that will be built upon them the quantity will be higher.

Experience will give a better gauge of the actual time investment needed given the scope of the application and the requested functionality.

Test Strategy:

Some of the testing at the unit level would be White Box testing. Making sure that different parts of processes or objects were executing properly during state transitions. It would look at the accuracy of logical operations for financial transactions and functions such as keeping double booking of appointment times from occurring.

Depending on the function of the unit, Black Box testing would also be performed at this stage. For certain units, equivalence partitioning and boundary values would be tested. This would be included for units such as those associated with financial transactions, the calendar systems for appointment units, and limitations on patient records such as allowable characters for information fields (no letters in the phone numbers field), ranges of birth dates, or any other portion of patient records that were not free form.

Subsystem Testing:

Roles:
Subsystem testing would still fall under the development teams for each system. Users may be involved to a lesser extent to help guide development of subsystem human interfaces for ease of use and understandability during the development and testing process.
Responsibilities:
At this level, the responsibility of testing is to make sure that each of the individual subsystems are functioning without issue before they are integrated with one another.

While unit testing will have hopefully identified many of the errors that might have plagued the subsystem it is best to test them here before integrating them as a whole.

Timing:

This testing level will also occur during the early development of the application but not until each of one of the subsystem’s unit functions have been fully tested and are ready to be implemented. While all three subsystems, financial, appointments, and patient records may not be tested in tandem each should be able to have basic testing performed with the use of test cases for input. Once they have completed testing, we could then use the same or similar test cases for the integration level testing of all subsystems.

With the combination of units into the various subsystems the length of time needed for testing may be more extensive. If there were issues following state-transition guidelines or other pre-planned factors this portion of testing could be even more extensive.

Test Strategy:

At this stage, Black Box testing would be the primary form of

testing.
Within the financial subsystem this would take the form of equivalence partitioning and boundary testing to assess its ability to handle different transaction types such as cash, credit card, check, credits to accounts, patient, insurance transactions and for a variety of ranges.
Patient records could be tested with Black Box testing as well looking at the addition and alteration of records through cause and effect graphing. The other subsystems, appointments, claim generation and reminders could have this same approach applied using test cases developed for each subsystem.