Ideal Test Plan. Unit testing:

Transcription

1 Ideal Test Plan Unit testing: Frontend: Our frontend unit tests will ensure that the logic behind the user interface functions as expected. We will use Mocha to run unit tests on the frontend (javascript) of our web application and we will use JUnit to run unit tests on the frontend of our mobile (Android) application. Backend: Our backend unit tests will ensure that the RESTful API requests are correctly routed and correctly query and update the data stored in Firebase. We will use Mocha to run unit tests on our Node.js backend. Integration and system testing: We will be using a usage based model for our Integration and system testing. The below figure shows the state transitions of our web page at the highest level. The below figure only shows the UI transitions, but each of these events triggers other events on the backend and database that were left out of the model for simplicity purposes. Over time we will be using this model to determine the frequencies of each possible transition. Once we determine these frequencies, we will be able to appropriately partition our test cases among the events in our application. The frequencies will also allow us to define a user-like workload for our test cases that is realistic.

2 Tools used: Mocha: An easy to install and use module for testing JavaScript applications. Producing tests in mocha is as easy as writing an assertion. Mocha will make it easy to build and run tests for both our Node.js backend and our frontend JavaScript code. By writing tests for our Node.js functions, we can ensure that RESTful API requests result in our data stored in Firebase being queried and updated properly. Chai : A powerful assertion library that must be used in conjunction with another test framework, such as Mocha. Using Chai with Mocha will allow us to test all elements of our code, both on the backend and the frontend, from variable types to expected values to results of expressions. JUnit : A powerful testing framework that will be used to test our Android application. By using this framework, we can easily integrate our tests into Android Studio, making the process of writing and performing tests painless. Types of end users Attendees : these users attend events but do not create events. In order to ensure a great user experience for these users, we must thoroughly test our frontend and backend code responsible for sending and receiving events nearby events, sorting events, commenting on events, and rating events. Creators : these users frequently create and host small, spontaneous events. In order to provide a great user experience, we must thoroughly test our frontend code to ensure the process of creating a new event is fast, easy, and functional. We must also test our ORM to ensure that POST requests from these users result in a new record being added to the Firebase database. Clubs and businesses : these users frequently create and host medium to large events, often events that repeat. These users, if they decide to pay for the premium version of Beacon, will be interacting with our event creation dashboard that will allow for them to easily create, schedule, and manage all of their events, as well as view how effective their events were and feedback from people who attended the event. In order to provide a great experience for these users, we must thoroughly test the usability of the frontend to ensure that the interface is functional, free of bugs, and easy to use. We must also test the backend code responsible for creating and scheduling recurring events.

3 Performance, reliability, etc. testing: Ideally we would use a tool such as LoadStorm to simulate heavy loads on the app, such as many users being logged on and creating events at the same time. For android we would also do fuzz testing using Monkey, which would generate unexpected user interactions for the app, and reports crashes and other poor behaviors. Acceptance testing: For the acceptance testing stage, we would ideally release the beta version of the app into the app store and set up a feedback option in order to receive comments from the people who downloaded the app. We would also do testing by randomly approaching students on campus, our intended users, and present them with the app on our phones. We would then watch them interact with the app and take notes as they attempt to traverse through the application. We would then make all the necessary changes to the app, fix all the bugs, and finally release the full application

4 Realistic Test Plan Unit testing: Integration and system testing: We will be using a usage based model for our Integration and system testing. The below figure shows the state transitions of our web page at the highest level. The below figure only shows the UI transitions, but each of these events triggers other events on the backend and database that were left out of the model for simplicity purposes. Over time we will be using this model to determine the frequencies of each possible transition. Once we determine these frequencies, we will be able to appropriately partition our test cases among the events in our application. The frequencies will also allow us to define a user-like workload for our test cases that is realistic. Tools used: Mocha: An easy to install and use module for testing JavaScript applications. Producing tests in mocha is as easy as writing an assertion. Mocha will make it easy

5 to build and run tests for both our Node.js backend and our frontend JavaScript code. By writing tests for our Node.js functions, we can ensure that RESTful API requests result in our data stored in Firebase being queried and updated properly. Chai : A powerful assertion library that must be used in conjunction with another test framework, such as Mocha. Using Chai with Mocha will allow us to test all elements of our code, both on the backend and the frontend, from variable types to expected values to results of expressions. JUnit : A powerful testing framework that will be used to test our Android application. By using this framework, we can easily integrate our tests into Android Studio, making the process of writing and performing tests painless. Types of end users Attendees : these users attend events but do not create events. In order to ensure a great user experience for these users, we must thoroughly test our frontend and backend code responsible for sending and receiving events nearby events, sorting events, commenting on events, and rating events. Creators : these users frequently create and host small, spontaneous events. In order to provide a great user experience, we must thoroughly test our frontend code to ensure the process of creating a new event is fast, easy, and functional. We must also test our ORM to ensure that POST requests from these users result in a new record being added to the Firebase database. Clubs and businesses : these users frequently create and host medium to large events, often events that repeat. These users, if they decide to pay for the premium version of Beacon, will be interacting with our event creation dashboard that will allow for them to easily create, schedule, and manage all of their events, as well as view how effective their events were and feedback from people who attended the event. In order to provide a great experience for these users, we must thoroughly test the backend code responsible for creating and scheduling recurring events. Performance, reliability, etc. testing: Realistically, we are not going to do very much stress/load testing on our application. If we have time, we will use a tool called Monkey for android, which generates a random assortment of user events and then reports the applications behavior. However, we should be able to perform simple automated tests in order to show that events can be created and queried in under a certain amount of time.

6 Acceptance testing: Realistically our group of beta testers is going to be smaller than we d like due to the time constraint. The fastest way to collect feedback on the app is having people we already know try it out, friends, family, etc. This way we can receive very direct pertinent information about the app in a very short period of time. We still may be able to do some random testing from students, but our best and fastest resources will be people we already know.