Beta Prototype
Welcome to our sixth blog, we will introduce our Beta Prototype and discuss the general test process, White-Box testing, Black-Box testing, and the Summary of Changes.
Introduction
Software testing is an organized process within the Software Development Lifecycle (SDLC) in which the software or the application, in our case, is verified and validated that it’s bug-free, the product features behave correctly as expected, and that it generally meets the technical as well as the user-specific requirements as laid down by the customer.
Testing Process
The process of software testing aims not only at finding faults in the existing software but also at finding measures to improve the software in terms of efficiency, accuracy and usability.
Software testing may either be a manual or an automated process. Manual software testing is led by a team or individual who manually operate the software product and ensure it behaves as expected. In contrast, Automation testing, is when the tester writes scripts and uses another software to test the product. Automation Testing is usually used to re-run the test scenarios that were performed manually, quickly, and repeatedly.
So for obvious reasons we chose to go with Manual Testing. We created test cases and took over the role of an end-user and tested the software to identify any unexpected behavior or bugs.
There are different stages for manual testing such as unit testing, integration testing, system testing, and user acceptance testing.
And there are different techniques used at each level, i.e. White-Box or Black-Box Testing.
Before we go deeper into the testing techniques, it’s important to mention here that we documented our testing efforts using Trello, which we have been using for monitoring and managing our work. We logged the bugs we came across, and accordingly tracked and fixed them.
White-Box Testing:
The technique of testing in which the tester is aware of the internal workings of the product, has access to it’s source code and is conducted by making sure that all internal operations are performed according to the specifications. White Box Testing is also called Glass Box testing.
In our case, White-Box Testing was done by our team. We used our prior knowledge of the code to develop test cases that examines the control flow, information flow, data flow, exception and error handling as well as coding practices of the system. We chose the Path Coverage technique because unlike Branch Coverage, Path Coverage ensures that you test all decision outcomes independently of one another. The Path Coverage testing for the following Test Cases was done.
1. LOGIN ACTIVITY: When the App is opened, it prompts the user to Enter PIN if the option is enabled from the Settings. The entered pin is validated against the TRUE_CODE which is the previously set/stored PIN. If the PIN is entered correctly, user is prompted to the homepage, whereas if the entered pin is invalid, an error message is shown and user is prompted to enter the PIN again. If the Enable PIN option is disabled from the Settings, user is prompted directly to the homepage.
Case 1:
| TRUE_CODE | Pin | path(line numbers) |
|---|---|---|
| 123456 | 123456 | 52 to 62 |
Case 2:
| TRUE_CODE | pin | path(line numbers) |
|---|---|---|
| 123456 | 311031 | 52 to 55,63,64,65 |
Case 3:
| pin | path(line numbers) |
|---|---|
| EMPTY | 52,70 |
2. MANAGING CATEGORY: Within the Category Settings, user can delete a previously stored category by swiping LEFT. The user is asked for deletion confirmation using a confirmation dialog. In contrast, if the previously stored category is swiped to the RIGHT, an edit box appears where the user can edit the name of the category and save.
Case 1:
| ItemTouchHelper | path(line numbers) |
|---|---|
| LEFT | 97 to 103,106 to 112 |
Case 2:
| ItemTouchHelper | path(line numbers) |
|---|---|
| RIGHT | 97 to 103,112 to 118 |
3. DISPLAY HOMEPAGE: At the homepage, when a user logs into the app, the application queries the data stored in the database and displays Expense, Income and Savings data.
Case 1:
| Called Method | path(line numbers) |
|---|---|
| onViewCreated() | 45 to 72 |
4. NAVIGATION ACTIVITY: We have a Drawer Menu in our application where the users can navigate and click to go on their desired page. The user is led to the home page when Home is clicked. Similarly user is led to user details when User Details is clicked, transaction history when History is clicked, application settings when Setting is clicked, graphical charts when Overview is clicked and email reports when Reports is clicked (however, this feature is yet to be completed).
Case 1:
| MenuItem | path(line numbers) |
|---|---|
| nav_history | 180,182,184,186,190 to 193 |
Case 2:
| MenuItem | path(line numbers) |
|---|---|
| nav_setting | 180,182,184,186,190,194 to 197 |
5. DISPLAY HISTORY: When user is searching for transaction history in History page, user can apply their desired Filters to search for particular transactions. When user clicks on Transaction Type, a dialog box is opened witch the options for Transaction Type. When the user clicks on Category filter, again a dialog box is opened where they can check/uncheck the desired categories.
Case 1:
| Function | initDialog | path(line numbers) |
|---|---|---|
| Tranfilter() | 1 | 334 to 341 |
Case 2:
| Function | initDialog | path(line numbers) |
|---|---|---|
| categoryfilter() | 3 | 343 to 350 |
Black Box Testing:
The technique of testing without having any knowledge of the inner workings of the application is called black-box testing. The tester is oblivious to the system architecture and does not have access to the source code of the application.
Typically, while performing a black-box test, a tester will interact with the system’s user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon. Black box testing being well suited for application with large code and also testers with less programming knowledge can be employed. This can be applied to every level of software testing such as Unit, Integration, System and Acceptance Testing.
It is also called as Behavioral/Specification-Based/Input-Output Testing.
Below chart depicts five Test Cases derived from our User Stories, as well as comparison of the expected results with the actual results. Data values in these cases adher to either Equivalence Partitioning or Boundary Value Analysis.
Summary of Changes
We didn’t make any major changes to the application. However we did make slight modifications to the homepage where we added a Pie Chart. We also moved Categories to the Settings page.
Apart from this, we added Filters for Transaction History, a minimum threshold amount for Savings, a virtual back button, confirmation dialog boxes at a few places, and notification alerts.
We leave you with a few screenshots.
That’s all for this blog, we look forward to finishing the App and reaching the next milestone. Stay tuned :)