Welcome to another blog by Nullfinders on Test case design of the fintrack application. We have been working on the test case design of the application. Here on this blog we will be discussing about the test cases developed and used for testing our code.
Overview
- Testing
- Black box testing
- White box testing
- Summary of changes
- Reference links
Testing
Software testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. Testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements. It can also be stated as the process of validating and verifying that a software program or application or product: Meets the business and technical requirements that guided it’s design and development. Being one of the major phase in a software development cycle we have taken atmost care in testing all the funcitons of the application. Here below we are presenting the test case results and other testings done for our application.
Black Box Testing
The technique of testing without having any knowledge of the interior 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. 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.
Black box testing steps
Basic requirements and specifications of the application is examined
Next one is the tester choose valid inputs(positive inputs),to check whether application under test processes them correctly and also have to see the application has to detect in case the negative input given
Software tester creates the test cases with selected inputs and the test cases are executes
ester have to compares the actual output with the expected output
If there is any defect it would be fixed and retested will happen
Test cases carried out
We have tested the below functionalities of the fintrack application
User Authentication
Add Income
Add Expense
Report View
Navigation
User Authentication
Below is the test cases for user authentication.
When user enters right password ,login successful and it moves to home screen page
If invalid Character given ask user to re-enter password
Enter password is equal or more than five characters ,login successful and it follows next step
If user enter less than five characters the password become invalid and asks to re-enter password
Add Transaction
Below is the test cases for Add transaction which covers add income and add expense modules.
We have tested with six scenarios for adding transaction, data values amount, date, category and payment method and all are mandatory fields except data note field. Transaction is successful when this criteria is fulfilled else it fails.
First three scenarios fails as mandate fields are not filled thus adding of transaction is not successful and user will be notified like ‘please enter all mandatory fields’.
Whereas fourth and fifth scenario is filled with all mandatory fields hence transaction is successfully added.
Report
Below is the test case for the report module.
We have five scenarios displaying possible combinations with which report can be seen, we have three filter
Filter by date - Date range is mentioned and transactions within this range are displayed to the end user
Filter by category - Select category (can be single/multi select also) and transactions of this type are only shown
Filter by payment - Select payment method and transactions of this type are only shown
First scenario is about displaying all results from the database as no filters has been added
From and To date are specified and transactions of this date range will be displayed, if only From or To is selected, user is prompted to fill in both dates
In 3rd scenario category is selected and transactions for that particular category are displayed
In 4th scenario payment method is selected and transactions for that particular payment type is displayed
In 5th scenario multiple filters are applied and result based on those filters will be displayed
Navigation
White-Box Testing
White-box testing is the detailed investigation of internal logic and structure of the code. White-box testing is also called glass testing or open-box testing. In order to perform white-box testing on an application, a tester needs to know the internal workings of the code. The tester needs to have a look inside the source code and find out which unit/chunk of the code is behaving inappropriately. As the tester has knowledge of the source code, it becomes very easy to find out which type of data can help in testing the application effectively.
User Authentication
Below is the white box texting for user authentication along with the path diagrams.
The above diagram shows the statement coverage of the login activity. The best example of login component. All variables are initialised first, Oncreate function is called during beginning of the login activity and later entered values in the edit text fields are captured and finally stored in DB.
Add Transaction
Below is the code coverage testing donne for the transaction module.
Report
Below is the code coverage testing donne for the report module.
above shows the path coverage, sequence of statements are repeatedly executed finite number of times. Here the statements between 1-5 are executed to initialise the values for income and expense n number of times. 10-16 statements are used to set new expense and income values for the transaction. Statements between 18-25 are used to update the transaction.
Summary of Changes
Multi Select of Category in view report, this lets user to choose more than one category to view his/her transaction with respectively
Recurring Transaction functionality was added, this allows user to specify transaction to add repeatedly for next 3/ 6 months on the specified date while adding a transaction. For example Salary is recurring transaction every month.
Usage of + and - for the amount field in Add Transaction window based on Income / Expense selected. This lets the user to get an idea of what type of transaction he/ she is going to give as input
Added a cancel button, in the “Add Transaction” page which enables user to return to home page
Showcasing the total balance on the report screen based on the applied filters