Once the basic sequence of operations are created and user interface designed, it is time for us to check the flow of these actions. This section deals with the Test Case Design where we run our application and validate the performance as intended.
Testing Documentation
It is very essential to document all the test procedures that we contend. It helps us build a better understanding of our application functionality and simultaneously detect and overcome any abnormalities present. We conducted Testing Documentation with the help of a Requirements Traceability Matrix (RTM) denoted below. This mapped all the different requirements asked by our customer with the test cases that we conducted.
To check the correct performance of our app, we followed the 2 basic methods of testing.
-
Blackbox Testing
-
Whitebox Testing
Blackbox testing
Here the app is executed in such a scenario that the tester needs no prior knowledge of the background coding and working steps. We tested the following sequence of actions using blackbox methodology.
1. Setting up the PIN
These are the different possibilities that were encountered in the test case for PIN Entry.
2. Updating user details
These are the different possibilities that were encountered in the test case for Filling User Details.
3. Adding a new activity
These are the different possibilities that were encountered in the test case for Adding Activities.
4. Selecting activity date and time
These are the different possibilities that were encountered in the test case for Choosing Activity Start and End Time.
5. Reviewing the activities
These are the different possibilities that were encountered in the test case for Reviewing Activities.
Whitebox testing
This method is quite different from the blackbox method. On contrary, the user here has the required coding knowledge and understands the flow of coding conventions. We tested the following sequence of actions using whitebox methodology. The Control Flow Graph (CFG) for each test case is depicted besides its respective code.
1. PIN login
This code was tested such that only when the user enters a predefined type of PIN, the result is accepted.
2. Adding activity details
This code was tested such that only when the user enters all the activity details, the result is accepted.
3. Writing into database
This code was tested with the input being stored into the database.
4. Reading from database
This code was tested with the output being retreived from the database.
5. User defined category
This code was tested with the with the option of user creating his own category, in case the required category does not already exist.
Summary of Changes
We do not have any changes in this phase. Since the requirements are discussed and finalised with the customer, we are confident on working towards our goal and completing the application ‘ActiLog’.
This section would have familiarized you with the testing actions we followed to validate the performance of our application. In the next section, which would be our last, we intend to give a complete overview of our application.