1
Quality Assurance Plan
CMPT 275
Arsh Bhullar, Brian Hanley, Jake Turner,
Derek Wu, Jason Wu, George Xie
2
Revision History
Version Revision Date Changes
By
1.0
Oct. 14, 2011
Document created,
individual parts compiled
1.1
Oct. 14, 2001
Edited, finalized,
submitted
2.0
November 5, 2011
3.0
November 16, 2011
Revised for the first
deliverable presentation
Revised for submission
Arsh Bhullar, Brian Hanley,
Jake Turner, Derek Wu,
Jason Wu, George Xie
Arsh Bhullar, Brian Hanley,
Jake Turner, Derek Wu,
Jason Wu, George Xie
Jason Wu
Jake Turner, Jason Wu
3
Table of Contents
Title Page – p.1
Revision History – p.2
Table of Contents – p.3
Unit Testing – p.4
Logic Testing – p.4
Application Testing – p.5
Internal Deadlines – p.5
User Acceptance Testing – p.5
Integration Testing – p.6
Metrics Measurement – p.7
4
Unit Testing
Unit testing can help ensure development of bug free code by making sure that all edge cases are
accounted for. It helps the long term maintenance of code by securing new additions of
code work as expected and does not break other features.
We will use the Xcode unit-testing environment that is provided by Apple for iOS development
(See:
http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_wor
kflow/135Unit_Testing_Applications/unit_testing_applications.html#//apple_ref/doc/uid/TP40007959CH20-SW3. This framework provides capabilities for logic and application testing, which we
will use.
Logic testing
Logic testing tests the underlying functions of the application without user interaction. It can also
test parts of a function before the function as a whole is implemented. We will use logic tests to
test functions, data structures, saving and reading, and network communications.
Example Code:
#import “MyTests.h”
@implementation MyTests
- (void)setUp
{
[super setUp];
//Set up code here.
}
- (void)tearDown
{
//Tear down code here.
[super tearDown];
}
- (void)testAdd
{
//example test
int a = add(1,1);
if( a != 2) STFail(@”add 1 and 1 failed”);
}
5
Application Testing
Test the user interface and functionality of the application as an integrated system from the point
of view of the user. We will create a test for each of the Tutorials in the user manual following
the steps as described in the Requirements Document.
Internal Deadlines
We will implement the basic features in our Version 1. We decided that 4 or 5 days should be
enough to complete the testing of Version 1. In Version 2, we will try to implement as many
features as we can and try to test if they work. If the group is able to run the app without any
complications then we will move to final version. Thus, Version 2 will require the longest testing
duration. In our final version i.e. Version 3, we are planning to polish our Version 2 and add one
or two more features if we have time. Thus, we will use 5 days of testing for our final version to
make sure that everything runs.
Testing Version Testing Start Date Testing End Date Testing Duration Type of Test
Version 1
23 Oct, 2011
27 Oct, 2011
4 days
2 days Unit
2 days Integration
Version 2
10 Nov, 2011
16 Nov, 2011
7 Days
4 days Unit
3 days Integration
Version 3
24 Nov, 2011
28 Nov, 2011
4 Days
2 days Unit
2 days Integration
User Acceptance Testing
Date: November 24th , 2011
Time: 3:00 pm
Location: ASB
Testers will be met in the ASB and brought into CSIL. Each user will be a supplied an iPhone
with the application “A Little Reminder” installed on it.
Each tester will then be led through a tutorial in which they are taught how to add a reminder to
the system.
The reminder will be to “Dance!” at 3:30 November 24th, 2011. Users will be asked to record a
voice clip telling themselves to dance and enter the text reminder “Dance!”
6
This should be started about 10 minutes before 3:30.
Users in the meantime will be taught to check if the reminder had been correctly entered into the
calendar via menu buttons.
Afterwards, testers will be taught how to add an emergency contact. At the end of this tutorial,
testers will be asked to program the number of one of the leaders of the testing as the emergency
contact. They will then test the panic button one at a time, taking turns in clockwise function
from an arbitrary person of the tester’s choice.
The users will then be given the website of where you can remotely set reminders, and will be
asked to set a reminder for November 28th, 2011. The event will be at 5:30pm and the title is
“CMPT 275 Presentation”. Afterwards, Users will check if the event had synchronized onto their
app.
And that will conclude testing.
Integration testing
Integration testing happens after unit testing. To fit the functions tested by unit testing together,
we will use a top-down approach. At first, the user interface (UI) will call stub functions that
return default data to be displayed. This will show that the UI work flow is working. Then the
underlining functions are replaced to integrate the system. These functions are added one at a
time to ensure ease of debugging should any abnormalities show up in the inter-module
communication.
7
Metrics Measurement
Rainbow Hammer will utilize Clang in order to measure our software’s metrics, and keep track
of project files. Clang is already integrated into XCode as of version 3.2, and is compatible with
many industry standards. Clang boasts compatibility with the GCC compiler, as well as low
memory.