Skip to content

High level Test Plan

Keith edited this page Mar 27, 2017 · 3 revisions

High-level Test Plan

  1. Must include test strategy, functional/component test descriptions (goals, expectations)

The test strategy for our ETES web application will be proactive as well as incremental. Essentially, as we produce a product at the end of each sprint, we will provide tests for our product as well. The end of sprint tests will allow us to revise and resolve our product during the development of the project. We will have a complete product by the end of our time projection by producing functional pieces of the product that satisfy our test cases each sprint. The incremental test plan will follow the schedule of our goals for each sprint which will be monitored and assessed by our backlog.

First, we will focus on the User Interface (UI) of the web development process. In the User Interface sprints, the focus for each phase of development will be our sprint’s goals. The last goal of each sprint will include testing. Therefore, our testing will be occur concurrently with our development process.

Many of our tests scenarios will assess the functionality of our design components in the following ways.

  • Website functionality
  • Website consistency (real time updates)
  • Database collections
  • Event collections
  • Event searches
  • Transactions
  • Exceptions
  • Error messages (invalid parameters, and responses)

  1. Test metrics including success criteria; tools and methodology to be use, … etc.

Our testing metrics will focus on the executions of our use case scenarios as well as the following evaluations.

  • Purchaser tries to buy a ticket but form of payment does not go through
  • (Flooding) Many people are trying to buy or access the same tickets however, users are not able to confirm the purchase of the ticket
  • Purchaser buys a ticket, and wants to cancel (or tries to log out)
  • Purchaser tries to buys a ticket, the destination is more than hour away
  • Purchaser buys a ticket but, the discount is not applied
  • Purchaser buys a ticket pays a discount however seller discount was not applied

Our sets of testing metric will not only include our use cases but also, some test cases will be based on the components of our design even though the internal structure will not be revealed.

The success criteria of our application tests will solely include the execution of our use cases, where we are able to complete an end to end ticket transaction in an easy to use application.

The tools for our testing will include UnitJS, and other software like Angular Protractor (or Karma and Jasmine).

Our testing strategy will be broken down into categories of testing functional and nonfunctional tests. The two categories will allow us to organize the methodologies we will be using during testing.

Clone this wiki locally