Test Plan and Cases (TPC) Template Version 1.3 Version no x.xx
Test Plan and Cases (TPC)
Construction Meeting Minutes App
Team 6
Pradeep Muruganandam - Prototyper and Quality Focal Point
Dennis Evans - System Architect, Project Manager
Pavan Lingambudhi Seshadri Vasan - Requirements Engineer
Sideok You - Feasibility Analyst
Shengyi Chen - Operational Concept Engineer
Nguyen Tran - IIV & V
Qichen Gu – Life Cycle Planner
12/6/2015
Version History
Date / Author / Version / Changes made / Rationale /11/28/15 / NT / 1.0 / · Initial commitment to create TPC document
· Provided testing strategy and test cases / · Finalize all testing procedures and test cases
11/30/15 / NT / 1.1 / · Added some new test cases
· Edited a few existing test cases / · Better explanation and links between test cases
12/1/2015 / NT / 1.2 / · Added 1 more test case / · Finalize test cases
12/6/2015 / NT / 1.3 / · Edited test schedule / · Feedback from DCR ARB presentation
Table of Contents
Test Plan and Cases (TPC) i
Version History ii
Table of Contents iii
1. Introduction 4
Test Strategy and Preparation 4
1.1 Hardware preparation 4
1.2 Software preparation 4
1.3 Other pre-test preparations 5
1.4 Requirements Traceability 5
2. Test Identification 6
2.1 Test Identifier – TC1 6
2.2 Test Identifier – TC2 8
2.3 Test Identifier – TC3 13
2.4 Test Identifier – TC4 16
2.5 Test Identifier – TC5 19
2.6 Test Identifier – TC6 22
2.7 Test Identifier – TC7 24
2.8 Test Identifier – TC8 26
2.9 Test Identifier – TC9 28
3. Resources and schedule 30
3.1 Resources 30
3.2 Staffing and Training Needs 30
3.3 Schedule 31
29
TPC_DCP_F15a_T06_V1.3.doc Version Date: 12/6/15
Test Plan and Cases (TPC) Template Version 1.3
1. Introduction
The purpose of testing within our project is to ensure that all functionalities in the app work as expected in production and in all circumstances (sunny and rainy days). We hope to find those corner cases through testing so that user does not experience those bad incidents in our app.
The scope of our testing is spanning from specific functions in our app to a whole integrated system. We mainly focus on software that is used to build Android app and Google App Engine integration. We want to test every single function in our app to ensure that there is no crash or no syncing issue between servers. We plan to perform unit testing on specific functions, integration testing on GAE, and system testing. We also plan to implement load testing and performance testing within our app in the future in order to ensure that our app can handle well all requests made to the server by multiple users (please note that number of users will be limited since the app is used only in-house, so this is not high priority comparing to app functionalities)
Test Strategy and Preparation
We will be working on developing a set of unit test cases, component tests and system test. This allows us to focus more on the functionality test cases part to have extensive testing to see if the features match needed requirements.
GitHub for the code repository.
Jenkins for Continuous Integration
· Value-based test prioritization: Have test cases covering the Minimum Marketable Features on top of the priority list of cases to be checked. Then we go for all the non-essential features to be tested.
1.1 Hardware preparation
Laptops for triggering the tests using corresponding software and testing frameworks. - Macbook Air, Lenovo G50 - Testing from the Dev environments.
Android Mobile Phones for testing the App during development. - Android Nexus 5
1.2 Software preparation
We mostly used emulator in Android Studio (version 6.0) for all testing. We simulate different phone screen resolutions, phone CPU types, phone memory capacities, etc. in order to cover most of common use cases from our users and client. The purpose of using the emulator is to allow us the ability to generate different phone specification without needing to acquire an actual phone. It helps save money as our client does not provide any budget.
General procedure:
· Compile and build Java code for our app in Android Studio
· Select emulator properties to be generated
· Hit “Play” button in Android Studio to run app on the chosen emulator
Other tools that we use:
Selendroid - The Test automation framework for native or hybrid Android apps and the mobile web. (v 0. 16.0)
Just like how Selenium works for Web Applications, Selendroid is made for Android apps. We need to record the webpages in a record and playback way for the page ordering for a good number of iterations.
Appium v1.5 - Open Source Mobile Automation framework.
For testing the functionality of the mobile application - testing methods and functionalities using Android API’s and controls.
jUnit API part of the Android SDK for testing basic Java methods that don’t call Android API’s or controls.
Apica - Load and Performance testing tool for Mobile Applications
1.3 Other pre-test preparations
Run our general unit test suite for the individual java methods before we start to do full-fledged Mobile App testing and Load Testing
1.4 Requirements Traceability
Table 1: Requirements Traceability Matrix
Requirement ID / Verification Type / Test Case ID (if applicable)PR-1 Zero Monetary budget / Demonstration
CR-7 Backend GAE functionalities / Testing / TC-06
CR-1 Create new project / Testing / TC-07
CR-2 Create new meeting / Testing / TC-01
CR-3 View/Edit meeting / Testing / TC-02
CR-4 Generate report & email / Testing / TC-03
CR-5 Generate and edit task list / Testing / TC-04
CR-6 Task comment / Testing / TC-05
CR-8 Signup/Edit contractor information / Testing / TC-08
CR-9 Login functionality / Testing / TC-09
2. Test Identification
2.1 Test Identifier – TC1
TC-01: Create meetings
2.1.1 Test Level
Software item level
2.1.2 Test Class
Functionality test
2.1.3 Test Completion Criteria
The test case for creating a meeting will be completed when:
-A privileged user is able to locally create a meeting on a new project
-A privileged user creates a meeting locally on a continuation project and the system successfully rolls in pending tasks and default project attendees.
-The system prevents a non-privileged user from creating a meeting.
-The system prevents the meeting from being published and viewable to all users upon creation.
2.1.4 Test Cases
Table 2: TC-01-01 Create new meeting for new project
Test Case Number / TC-01-01 Create new meeting for new project.Test Item / This test case verifies that a privileged user can create a new meeting for a new project.
Test Priority / M
Pre-conditions / Manager has logged into the system as a privileged user.
Manager has created a new project for which to add the new meeting to.
Post-conditions / A new meeting is created for the project with the correct category, date, meeting attendees, and task list.
Input Specifications / 1. From the project specific dashboard a manager selects new meeting.
2. Manager selects type of meeting.
3. Enter date, meeting attendees, and populate task list.
4. Select create
Expected Output Specifications / A meeting for the project is created with the correct information while returning the user to the project dashboard.
Pass/Fail Criteria / Pass Criteria:
-A new meeting is created that is viewable on only the manager’s device until it is published.
-The new meeting contains the correct inputted information.
Fail Criteria:
-Other than pass criteria.
Assumptions and Constraints / -A new project has been created.
-The user has a privileged account.
Dependencies / Create Project (TC-07-01)
Traceability / WC_3513
Table 3: TC-01-02 Create new meeting for continued project
Test Case Number / TC-01-02 Create new meeting for continued project.Test Item / This test case verifies that project default attendees and pending tasks will be rolled in when a new meeting is created on a continuing project.
Test Priority / M
Pre-conditions / Manager has logged into the system as a privileged user.
Existing project contains a meeting of the same type that the manager is about to create.
Post-conditions / A new meeting is created for the project with correct pending tasks being rolled in from previous meeting and default attendee list from project information.
Input Specifications / 1. From the project specific dashboard a manager selects new meeting.
2. Manager selects type of meeting.
3. Enter date, meeting attendees in addition to the default attendees, and add new tasks.
4. Select create
Expected Output Specifications / After selecting the type of meeting, the create meeting page is shown with attendee list already populated from the project’s default attendee list. Task list is also automatically populated with pending tasks from the previous meeting. A meeting for the project is created with the correct information that was added or automatically rolled in.
Pass/Fail Criteria / Pass Criteria:
-A new meeting is created that is viewable on only the manager’s device until it is published.
-The new meeting contains the correct inputted information along with the default attendees and pending tasks from the previous meeting of the same type.
Fail Criteria:
-Other than pass criteria.
Assumptions and Constraints / -A project contains a default attendee list.
-There already exists a meeting of the same type for the current project with tasks that are still pending.
-The user has a privileged account.
Dependencies / TC-01-01
Traceability / WC_3513
Table 4: TC-01-03 Attempt to create new meeting as unprivileged user
Test Case Number / TC-01-03 Attempt to create new meeting as unprivileged user.Test Item / This test case verifies that a non-privileged user cannot create a meeting.
Test Priority / M
Pre-conditions / User has logged into the system as a non-privileged user.
Post-conditions / Project dashboard is displayed without the option to create a new meeting.
Input Specifications / 1. After logging on, the user selects a project.
Expected Output Specifications / The non-privileged user is taken to the project dashboard and privileged options such as create new meeting are not shown or accessible.
Pass/Fail Criteria / Pass Criteria:
-Project dashboard page is shown without the new meeting functionality.
Fail Criteria:
-Non-privileged user has option to create a meeting.
Assumptions and Constraints / -A project has been created.
Dependencies / Create Project (TC-07-01)
Traceability / WC_3513
2.2 Test Identifier – TC2
TC - 02 - View / Edit Meeting
2.2.1 Test Level
Software Item Level
2.2.2 Test Class
Functionality Test
2.2.3 Test Completion Criteria
Edit (and View) Meeting scenarios will be complete when:
· Required meeting details are fetched and be able to view by user.
· Able to select a meeting for editing and enter details to edit.
· Able to store the edited information in the server once editing is done.
· View the edited meeting information by selecting the same meeting name.
2.2.4 Test Cases
Table 5: TC-02-01 View Right Meeting Information
Test Case Number / TC-02-01 - Viewing Right Meeting InformationTest Item / Tests whether the user with admin privileges is able to view the meeting details of the meeting selected.
Test Priority / M - Must Have
Since this feature is needed for the manager to view meeting details of what have been added to system and make changes later if necessary. So, it becomes a Must Have feature.
Pre-conditions / Manager is logged in to the App.
Before we test the view meeting scenario, we must make sure that the Create Project and the Create meeting test case scenario has been executed so that we have meetings in the cloud server for the project.
Post-conditions / The meeting data is not affected by this test case since it is only a read operation.
Input Specifications / The View Meeting option needs to be selected in the Dashboard page and the meeting name desired needs to be selected in the Meeting Name drop down list box.
Expected Output Specifications / The meeting information corresponding to the meeting name selected is displayed by filling the necessary fields on the page. It is available for viewing or editing based on the user privileges.
Pass/Fail Criteria / Pass Criteria : ( All needs to pass to be deemed a success)
• On selecting the view meeting option, goes to view meeting page.
• Displays correct list of meetings held for the corresponding project chosen at present.
• On selecting a name, should display the correct details of the meeting like Data, Attendees List, List of Minutes ,etc.
Fail Criteria :
• Failure in 1 or more of mentioned pass criteria or any sort of unexpected behavior of the app.
Assumptions and Constraints / Assumptions: A project and meeting must have been created in the system before we exercise the test case.
Constraints: Normal account users will not see all the meeting details but only their relevant details. So, user needs to be logged in to Administrator privilege account (Manager) to get desired output of test case.
Dependencies / Create Meeting - TC - 01. Create Project - TC - 07
Traceability / WC_3699.
Table 6: TC-02-02 Edit Meeting Information
Test Case Number / TC-02-02 - Edit Meeting InformationTest Item / Tests whether the user with admin privileges is able to edit the meeting details of the meeting being viewed in the view meeting page.
Test Priority / M - Must Have
This feature is mandatorily needed for the manager to edit meeting details like tasks, publish details, type of meeting, etc . So, it becomes a Must Have feature.
Pre-conditions / Manager (Privileged user) is logged in to the App.
Before we test the edit meeting scenario, we must make sure that the Create Project and the Create meeting test case scenario has been executed with expected results and also we are rightly fetching the meeting details via the view Meeting scenario.
Post-conditions / The meeting which is edited will now have the new set of information as keyed in during the operation. The cloud server now has the new meeting details object and it is retrieved to check.
Input Specifications / Open the View Meeting page, select a meeting. Once we have the meeting open, choose to edit. Change the name, type, location or choose to edit the minutes or attendees. Once done, click update button.
Expected Output Specifications / The meeting information changed will be update to the Google Cloud Storage and when we try to view the meeting details of the same meeting again, we can see that the meeting now carries the changed data which was inputted during the test case.
Pass/Fail Criteria / Pass Criteria : ( All needs to pass to be deemed a success)
• View meeting on select meeting name properly.
• Allow to enter new details for needed fields.
• Save changed data to cloud storage database.
• Viewing data should have changes reflecting in them.
Fail Criteria :
• Failure in 1 or more of mentioned pass criteria or any sort of unexpected behavior of the app.
Assumptions and Constraints / Assumptions: A project and meeting must have been created in the system before we exercise this test case.
Constraints: Normal account users will not see all the meeting details but only their relevant details. So, user needs to be logged in to Administrator privilege account (Manager) to get desired output of test case.
Dependencies / Create Meeting - TC - 01, Create Project - TC - 07, View Right Meeting Information - TC-02-01.
Traceability / WC_3777
Table 7: TC-02-03 Editing an earlier meeting in a category which has already had follow-up meetings