Purpose & Overview
This document is going to write about the actions that we take to test about Blue Bus App.
Blue Bus is a car sharing app on Android platform. Users can search for ride between ATOS offices on the app. To book a
ride or offer a ride, users need to log in with username and password. Our app consists of several modules, registration and
login, searching for a ride, offering a ride and my ride history.
in the Scope
In the scope of each module, we carry out functional test to make sure each class works as expected.
The functions of UI components like navigation bar is easy to test, but tests on input fields are more complicated. For example,
we need to do tests on the input field of the number of seats that a user wants to book. If we input letters, it makes user to
try again as expected. When we input a number, it enables us to book a ride, even if the number of seats we enter is greater
than available seats. The number is called invalid input. It indicates the method of validation check of the field needs improvement.
After correcting it, we continue with boundary testing. It accepts the most number of available seats, so now we can roughly say the
validation check of this input field is thorough. It means no unexpected input will be processed and no error will be invoked by it.After the functionality tests are accomplished, we know each class functions as expected. And we can move on to do tests out of scope.
out of Scope
For tests out of scope, we focus on performance testing and integration testing. Performance testing tells the
average response time and stability of the application. In our case, the app will not meet with large amount of input. The most amount
of data that the app deals with is the result of searching a ride, which is limited to 20 records at most. This takes the app 0.8
seconds to send the query to the database, fetch the data from the database and load 20 records in the listview. Hence the respond
speed of our application is excellent. Also, we carry out integration testing by simulating an actual user to use the app. We go
through all the pages a user may turn to to test whether there are errors in connection of different components of the system and
whether the application meets our final requirements.
We also invite five students in our course to carry out user acceptance tests. Their feelings are what we care about. We prepare the
following questions as script to interview them after they try our app. The result is that most people did like our app, but there is still for improvement.
Q: Do you like our Blue Bus logo?
Q: How do you feel about our design of interface?
Q: Do you think it is convenient to find your destination on Search or Add page?
Q: Do you think our app is easy to use?
Q: How do you feel about the response time of our app?
Q: What aspect do you think our app needs to improve?
Evaluation
There are four use cases that we wrote when we designed the product. We also go through these use cases.
Fortunately, the result is what we expected and wrote in the documentation. In the end, our application meets all the must-have
requirements and most of should-have requirements. During testing, we also discovered some problems that we had never thought of.
For example, it will be good to set a ‘clear‘ button to make input more convenient. Due to the limit of time, we cannot perfect
the application, but we can write them in the documents so programmers can refine them in further development.