QA Document

Revision History

Revision Description Date Author
1.0 Original draft created June 07, 2011. Peyton, Steven, Brian, Hank, Ivan
2.0 Added description for internal deadlines, software tools
to measure size and complexity, additional quality assurance steps.
June 08, 2011. Brian, Peyton, Ivan, Steven.
3.0 Modified integration testing,
improved software tools to measure size and complexity
June 08, 2011. Brian, Hank, Ivan,

1.0 Testing Guidelines

  • The software tools we are using for unit testing are Xcode and OCUnit framework including SenTestingKit, a framework that assists in writing test cases. We will begin our unit testing from the lowest level, for instance, when a method, class and function is created or modified, it will be repeatedly tested to ensure they are working as expected and will compile successfully without any errors.
  • Moreover, it is also necessary to check whether each function meets the functional and non-functional requirement. Error handling will also be tested through all the generated test cases from OCUnit, this process is to ensure that the system will be providing correct instructions to the user when an invalid input or data is entered. All the test cases will be generated by OCUnit through the example on developer tutorial website. (http: //
  • After resolving all the problems in Xcode environment, the application will be tested on iPhone/iPad/iTouch simulator with various test cases to ensure that all the functions regarding to user interaction on the interface are working properly. The problem will be solved instantly when an error is detected.

2.0 Internal Deadline for Unit/System Testing

  • Internal deadlines are set for unit and system testing of the code before release. These deadlines are set well enough so that we should have enough time to do the testing and debugging before the actual due date.
  • For Version 1, we estimate that we will be able to finish the implementation in 16 days, on June 25th. We will then allocate four days for unit testing, followed by five days of integration testing.
  • For Version 2, only one week is assigned and therefore time resource is very limited, and hence the tight schedule. We will be adding two features into Version 2, estimated time for implementation will be two days, followed by two days of unit testing and three days of integration testing.
  • For Version 3, seven days are needed for implementation. We will then allot three days of unit testing and five days of final integration testing.
Deadline for implementation Deadline for unit testing Deadline for integration testing
Version1 June 25th, 2011 June 26th – June 29th, 2011 June 30 th – July 3rd, 2011
Version2 July 5th, 2011 July 6th – July 7th, 2011 July 8th – July 10th, 2011
Version3 July 17th, 2011 July 18th – July 20th, 2011 July 20th – July 24th, 2011

3.0 User Acceptance Testing Plan

3.1 Goal

The main goal of acceptance testing is to ensure that the application, DailyHelper, performs in a moderate level. The application should provide both caretakers and people who are taken care of with a convenient and efficient platform to communicate.

3.2 Testing Time/Date

  • User Acceptance Testing will begin on July 22nd (Friday) 12 P.M., during the integration testing.
  • Testing will end on July 24th (Sunday) 4 P.M., one day before submission date.

3.3 Potential Testing Participants

  • As People who are taken care of
  • Seniors
  • Mute people
  • People with cognitive impairment
  • People who are unable to move freely
  • As Caretaker
  • On duty caretakers.

3.4 Location

  • Our group members will visit following locations to demonstrate our application as well as to perform the testing on the designated date. (See section “Testing Time/Date”, dates are subject to change)
  • Richmond Senior House (July, 26-July, 29)
    • 8720 Railway Ave Richmond, BC, V7C 3K3
      Telephone: (604) 277-4116
  • Learning Disabilities Association Vancouver (July, 30-Aug.1)
    • 3292 East Broadway, Vancouver, B.C. V5M 1Z8
      Telephone: (604)873-8139
      http: //

3.5 Testing Requirements

  • Preparation before the testing:
  • Input the default information.
  • Ensure that the message will be sent to the designated phone.
  • Identified participants will be asked to sign the agreement sheet, and will be carefully instructed by one of the team members before the testing.
  • After the testing, identified participants will be invited to complete a survey and the team will be collecting comments from them.

3.6 Testing Activity

The following activities cover basic features of the application. Each participant, as a patient, will be asked to perform each step carefully. Meanwhile, the group member, as a caretaker, will record and check if the application respond with the expected result.
Following tasks cover the basic features of the application:

  • Launch the DailyHelper
  • Launch “Five Basic Needs”; tab one of the basic needs buttons. The verification window will pop up, tab “Yes” to send the message to the caretaker.
  • “Five Basic Needs” mode: randomly tab one of the basic needs buttons. The verification windows will pop up, tab “No” to dismiss the message sending window. (This process is to show the participants that this function can prevent them from mistakenly clicking the button)
  • “Five Basic Needs” mode: go to the feature “customize your own button”, create a new button “Take a walk”. Once the new button is created to the “Five Basic Needs” mode: tab the button, and tab “Yes” at the verification window to send the message to the caretaker.
  • Go back to the main menu, launch “Text To Speech” mode
  • “Text To Speech” mode: input a simple sentence to introduce yourself (for example: “Hi, my name is _. Nice to meet you”), and let the device output the sentence in audio. Perform this task to a nearest person (but not the members of our group).
  • “Text To Speech” mode: save the sentence, that has been input from the last step, into the “history log”.
  • Go back to the main menu, tab “Emergency button”. The verification window will pop up, tab “Yes” to make a direct emergency call to the caretaker.
  • Demonstrate how to edit, delete, and enter a patient’s personal information on an Apple device for all the on duty caretaker’s and ask their feedback.
  • Lastly, show all the on duty caretakers the security system we are using to protect all patients’ information if the device is lost or stolen.
  • Done

3.7 Evaluation

Each participant will be asked to complete a survey and leave some comments about the DailyHelper once the test is finished:
1. Do you own an iPhone or iPod? _
2. Your age is (optional)
3. Your gender is:
a. Male
b. Female
4. The features of this application is easy to learn
(very hard) 1 2 3 4 5 (very easy)
5. The instructions from the team is helpful
(not helpful) 1 2 3 4 5 (very helpful)
6. The “Five Basic Needs” mode is helpful
(not helpful) 1 2 3 4 5 (very helpful)
7. The “Text To Speech” mode is helpful
(not helpful) 1 2 3 4 5 (very helpful)
8. My overall rating for this application is
(poor) 1 2 3 4 5 (amazing!)
9. I would recommend this application to others
Yes Not Sure No
10. Comments and Suggestion:

  • Note:
    Your personal information will under no circumstances be released to a third party, and will be erased at completion of the study.

4.0 Integration Testing

Integration testing is one of the processes in system testing and should be applied after the unit testing is finished. Individual input modules will be combined as a group during the integration testing. Integration testing is an efficient way to ensure each function in the application works as expected. If any problem arises, it is easier for the developer to trace back to the previous test case and examine all the related classes. For example, several tested class or method from the lowest level will be combined and tested as a group. New class and method will be added one by one and tested as a new group until all class and method meets the functional requirements. This process is to assure that the "Big Bang" approach will be avoided, where all the units are combined and tested at once. The entire process will take a multitude of resources and time to finish the entire process.

  • “Bottom-up” approach will be applied during our integration testing. After completing the unit testing, then the lower level components will be combined as higher level components and facilitate the testing.
  • Step 1: Determine and identify which modules should be tested in the integration testing, and design the levels will be combined as. Draw up the testing schedule.
  • Step 2: Based on step 1, the tested components from the lowest level will be combined as a higher level component in a correct order. Tester may develop some test module to test some of these higher level components. For some large components, separate them in several components, and then combine them as a larger component.
  • Step 3: After finishing the higher level components’ testing, each component will be combined as the subsystem and tested to ensure that they work as intended. (Develop some testing modules if necessary.)
  • Step 4: Combine all subsystem as a final version system and test it on a physical device to assure the application meets all the functional requirements and the interaction with the device is appropriate.

Finally, the application will also be tested to ensure some of the main non-functional requirements are met. For example, if the running time for one of the features are unnecessarily slow, the implementation of the function and all related class should be checked and changes should be made if necessary.

As we have 3 versions of the application, we will have various levels of
integration testing for each version.

5.0 Software Tools to Measure the Size and Complexity of Project

SLOC approach will be used to measure the size and complexity of the project and Xcode is used as the tool to measure the size and complexity of this project.

As shown in Figure 1 below, Xcode allows counting the number of lines of code (highlighted in blue box), number of class files (highlighted in red box) and their respective size (highlighted in green box). In addition to providing the raw measurement values, a plot (Figure 2.1 & 2.2) showing the measurement data (i.e. number of class vs number of files vs lines of codes) is provided to show the relationship in between.

  • Figure 1. a screenshot of the interface of Xcode.
  • Figure 2.1. A plot of the estimated number of classes and files for version 1 to 3.
  • Figure 2.2. A plot of the estimated number of lines of code for version 1 to 3.

6.0 Additional Quality Assurance Steps

  • We will create an internal standard checklist for the testing process. Then programmer and tester will use this checklist to ensure the quality of testing. This checklist will set standard for format, consistency, completeness, quality and presentation. By checking against this file, the team will attempt to achieve the highest project quality possible in the given time.
  • The external communication manager will work to facilitate the communication with other stakeholders, including customers, instructors, external expert in this area. By obtaining the feedback from the users after the release of each version, the team can both minimize the gap between what the users want and what the application can provide. By pursuing advice for the external expert, the team can improve the quality that the project can reach.