Test Results

Online Survey App

Test Results

COP 4331, Fall, 2014

Team Name: Group # 2

Team Members:

Modification history:

Version	Date	Who	Comment
v0.0	9/11/2014	Damla Turgut	Template
v0.1	10/5/2014	Adam Hollifield	Rough Draft of Test Results
v0.2	11/19/2014	Adam Hollifield	Added new content to copy of original Test Plan
v0.3	11/20/2014	Adam Hollifield	Added pass/fail test results to testing tables
v1.0	11/25/2014	Adam Hollifield	Final Test Results for submission

Contents of this Document

Introduction:

Overall Objective for Software Test Activity
Reference Documents

Description of Test Environment
Overall Stopping Criteria
Description of Individual Test Cases

SECTION 1: Introduction

Overall Objective for Software Test Activity:
The software test effort confirmed that all aspects included in the Software Requirements Specification document were met in the application. This software testing effort also investigated all possible failure points in the application, looking for any software bugs. Lastly, this software test effort looked for any usability or performance improvements that could be made before final release of the application.

Reference Documents:

SECTION 2: Description of Test Environment

The testing environment used was a combination of Android emulation tools within the Android Studio IDE as well as importing and executing the application on physical Android devices. Several physical Android devices, with various recent versions of Android installed on the devices, were used to conduct this testing. The application was tested both on Android phones and well as tablets. This ensured the application scales and runs properly across a wide range of devices and Android versions.

The testers of the application were the developers. The developers were the testing group for both the Android simulator tests as well as the physical Android device testing. A focus group was not used to test the application on a physical Android device.

Testing on physical Android devices, the test environment was the same environment in which the software will operate. When testing basic functionality within the Android simulators, this testing environment was different than the one in which the software will operate. From a usability perspective, this environment is the same since it emulated a touch screen and a keyboard. From a functional software perspective, this simulated environment may have executed code differently than a physical device. However, there were no observed errors or application behavior anomalies when testing on the Android emulator. Only debug errors and other erroneous logs were present when testing on the Android emulator that were not present when testing on physical Android devices.

SECTION 3: Stopping Criteria

This section describes how the testers determined when to stop testing the software and either deliver it or send it "back" to development.

Response to errors found during testing: Testing continued, recording all errors relevant to that particular portion of the application before continuing development. If a fatal error occurs that does not allow immediate progression of testing, the testers attempted to find any possible workarounds. This allowed a clearer picture for development to fix the issue as well as offer a possible solution to the issue. Testing was grouped into phases based on feature and module. Regular group meetings were held, as well as communication over WhatsApp, to discuss and fix whatever issues arose as part of the specific module(s) testing.
Response to no errors are found during testing: Each reasonably possible test case was run before declaring the software to be "good enough to deliver". A reasonably possible test case was defined as a case that is possible to occur in real world use or possible input errors from a user.
The application was be defined as "good enough to deliver" once it passed all functional testing parameters using all reasonably possible test cases. This did not require that there be no known errors as long as they are properly documented with a workaround, are not possible in real world use, or functionality that is not required to be implemented based on the project specification. Cosmetic errors were another error that were not considered in defining the application to be “good enough to deliver”; as long as these cosmetic errors do not cause any usability or detrimental display issues with the application.

SECTION 4: Description of Individual Test Cases

Test Case #	1
Test Objective	Create User Account
Test Description	Test that user’s phone number is properly applied to the user’s unique ID. Test that user’s phone number is hashed when stored. Data included in this test is the Android device’s phone number.
Test Conditions	This test can be performed in the Android simulator or on a physical Android device if the phone number is manually entered through a text box by the user. If the phone number will be pulled directly from the device, the test must be performed on a physical Android phone so that a phone number is present.
Expected Results	The test succeeds if the user can successfully create and login to a user account using their phone number. The phone number should be properly hashed and the hashed value stored in the database.
Testing User	Adam Hollifield
Date	November 5, 2014
Environment	Android Emulator
Result	PASS

Test Case #	2
Test Objective	Populate User Profile
Test Description	Test that user can properly personalize their user profile. Data used will be the user’s age, gender, and education level. Age will be tested with an integer value entered into a text box. Gender and education level will be tested with a drop down menu.
Test Conditions	This test can be performed once the user is logged into the application. For more information see Test Environment.
Expected Results	The test succeeds if the user can successfully enter all of the data mentioned above. The user must also be able to view their personalized profile. The database should store the user’s age, gender, and education level tied to the user’s ID (phone number)
Testing User	Adam Hollifield
Date	November 5, 2014
Environment	Android Emulator
Result	PASS

Test Case #	3
Test Objective	Take a survey about current issue
Test Description	Test that user can properly complete and submit their answers to a survey about current issues and events. The data used for this test will depend on what type of survey question is asked. For testing purposes, drop down menus and/or radio buttons will be used as data input methods.
Test Conditions	This test should be performed in the survey taking module. For more information, see Test Environment.
Expected Results	The test succeeds if the user can successfully answer and submit their results of the survey. The database should store the user’s answers to the survey for later analysis and reporting. The database should also store that the user completed this particular survey.
Testing User	Cody Showers
Date	November 18, 2014
Environment	Android Emulator
Result	PASS

Test Case #	4
Test Objective	Vote for a candidate
Test Description	Test that user can properly submit their vote for a candidate using a specialized version of the survey module.. The data used for this test will be implemented with radio buttons. The data will be built using two or more names for candidates on which the user can vote for.
Test Conditions	This test should be performed in the survey taking module. For more information, see Test Environment.
Expected Results	The test succeeds if the user can successfully vote for a candidate in the specialized survey. The user should be able to properly select and send their vote for a candidate. The database should store the specific user’s vote as well increment the vote count for the candidate which the user voted for. The database should also store that the user completed this particular survey.
Testing User	Cody Showers
Date	November 18, 2014
Environment	Android Emulator
Result	PASS

Test Case #	5
Test Objective	View the results of an ongoing or completed survey
Test Description	Test that user can properly view bar graphs or pie charts for the results of ongoing and completed surveys. The data used for this test will be the results of past and ongoing surveys submitted through the application.
Test Conditions	This test should be performed in the reporting module. For more information, see Test Environment.
Expected Results	The test succeeds if the user can successfully view graphs related to a particular survey question. The application should properly display the graph in a readable format with proper scaling and axis labeling. The reporting and graph generation tool should take the information from the database and turn it into easy to read graphs.
Testing User	Robert Montalbano
Date	November 17, 2014
Environment	Physical Android Device
Result	PASS

Test Case #	6
Test Objective	Demography reporting
Test Description	Test that user can properly view bar graphs or pie charts for the demographics of the users who have taken the survey and what their respective answers to the survey question were. The data used for this test will be the results of past and ongoing surveys submitted through the application as well as the information present in a specific user’s profile.
Test Conditions	This test should be performed in the reporting module. For more information, see Test Environment.
Expected Results	The test succeeds if the user can successfully view graphs related to the demographics of a particular survey question. The application should properly display the graph in a readable format with proper scaling and axis labeling. The reporting and graph generation tool should take the information from the database and turn it into easy to read graphs.
Testing User	Robert Montalbano
Date	November 18, 2014
Environment	Physical Android Device
Result	PASS

Test Case #	7
Test Objective	Voting count limit
Test Description	Test that user can only complete a specific survey once. The application should read a list of surveys the user has already taken and ensure that the current survey the user is attempting to take has not already been completed by that user.
Test Conditions	See Test Environment.
Expected Results	The test succeeds if a user cannot retake a survey in which they have already taken in the past. This will ensure the results are not skewed by repeat voters. The application should display an error message that the user has already complete this particular survey.
Testing User	Shawn Morrison
Date	November 18, 2014
Environment	Physical Android Device
Result	PASS

Test Case #	8
Test Objective	Add/View Comments
Test Description	Test that user can properly add and view comments about a particular topic, survey, or candidate vote. The user should attempt to add a new comment to a survey post that comment should then be visible by other users.
Test Conditions	See Test Environment.
Expected Results	The test succeeds if a user can successfully post a comment on a particular survey. The user should also be able to view the comment they just made. Additionally, another user within the application should be able to the view the comments made by other users of the application.
Testing User	Cody Showers
Date	November 19, 2014
Environment	Android Emulator
Result	PASS

Test Case #	8
Test Objective	Create a Survey
Test Description	Test that user can properly create and submit a survey for other users of the application to take. The data used for this test will depend on what type of survey questions the creating user enters. For testing purposes, drop down menus and/or radio buttons will be used as data input methods.
Test Conditions	This test should be performed in the survey creation module. For more information, see Test Environment.
Expected Results	The test succeeds if the user can save and view the survey just created. The web server should store the survey and make it available for other users to complete the survey.
Testing User	N/A
Date	11-25-2014
Environment	N/A
Result	N/A [OPTIONAL]