University of Dhaka

Department of Computer Science and Engineering

CSE-3112: Software Engineering Lab

Software Testing Document
Project Title: MyBudget

Submitted to
Dr. Saifuddin Md. Tareeq
Professor and Chairperson,
Department of CSE, DU
Dr. Sarker Tanveer Ahmed
Assistant Professor, Department of
CSE, DU

Submitted by
San Ibn Ashraf
Roll no.: 52
Sakib Ahmad
Roll no.: 58
TABL E OF C ON TEN TS

1. Unit Testing
1.1 Static testing

1.1.1 Walk through

1.1.2 Code review

1.2 Dynamic testing

1.2.1 Black box testing

1.2.1.1 Range partitioning

1.2.1.2 Set partitioning

1.2.2 White box testing

1.2.2.1 Statement/Code coverage

1.2.2.2 Branch and conditional coverage

1.2.2.3 Path Coverage

2. Integration Testing
2.1 Bottom up testing

2.2 Top down testing

2.3 Sandwich testing

3. System testing
3.1 Functional testing

3.2 Performance testing

3.2.1 Security testing

3.2.2 Timing testing

3.2.3 Volume testing

3.3 Acceptance testing

3.3.1 Alpha test

3.3.2 Beta test

1. Unit Testing
Our android application MyBudget is consist of these classes
AboutAppActivity,AccountActivity,ForgetPasswordActivity,
DailyAnalyticsActivity,HistoryActivity,LoginActivity,MainActivity,M
onthlyAnalyticsActivity,MonthlySpendingActivity,RegistrationActivit
y,SelectAnalyticsActivity,TodaySpendingActivity,SetBudgetActivity,
WeekSpendingActivity, WeeklyAnalyticsActivity. We have
scrutinized all the classes and their desired tasks. We have also
checked the codes of each part and found no anomalies. Thus it can be
said all the subsystems are correctly coded and perform the desired
tasks they are designed to do.

1 Static testing
.
1.1.1 Walk through

We have used Java programming language which is an object-

oriented programming language and Android Studio IDE to write the
codes of our application. We have used some extensions to check our
coding errors and warnings. Any coding anomaly is checked in real-
time. So, there is no chance of having any uninitialized variables.
Every block of the code is well-documented. So, there is no
undocumented code block. Most of the functions that we have used
are built-in functions. So, we didn’t have to assign them again.

We have followed the general coding conventions. For variable and

function names we have used easily understandable names and
CamelCase notation. We have used proper indention and spaces so
that they can easily be read and understood. We have tried our best to
remove any coding and structural anomalies as much as possible.
1.1.2 Code review
We took suggestions from different online platforms most notably
StackOverflow. We also took suggestions from our classmates and
seniors. They have suggested how to improve our code and fix
errors. From their suggestions we have selected some to mention
here:

Code Formatting:
▪ In the codes, proper alignment and white space should be
maintained and unwanted trailing white spaces and empty
spaces should be removed.
▪ You have ensured that proper naming conventions for
CamelCase have been followed.
▪ The commented codes should be removed as it makes the code
look disorganized.

Maintainability:
▪ Readability is important as it helps others to check the code
easily. The code is easily readable as it is properly organized.

Reusability:
▪ We have uploaded our code to GitHub which will help
anyone to further develop the applications and reuse it again
later at any point.

Reliability:
▪ The exception handler can be further improved to handle a
wide range of scenarios.
Security:
▪ Google Firebase is enough for security in most cases for
general users.
1.2 Dynamic testing
1.2.1 Black box testing
Several test cases have been run and the results are given
below;
Test Case 1: Create new account.
Input: User will provide some of his personal information
like name, email, age etc.
Output: An verification email will send to his email account
and if verified, new account will be created.
Test Case 2: User Signing-in.
Input: Types user credentials.
Output: If logged successfully, user is moved to main
activity screen.
Test Case 3: User wants to add or edit budget details.
Input: Users selects “My Budget” option from main screen.
Output: User will enter into “My Budget” option and will
be able to add or edit budget items.
Test Case 4: User wants to save daily expenses.
Input: Users selects “Daily” option from main screen.
Output: User will enter into “Daily” option and will be able
to save daily expenses item-wise.
Test Case 5: User wants to save weekly expenses.
Input: Users selects “Weekly” option from main screen.
Output: User will enter into “Weekly” option and will be
able to save weekly expenses item-wise.
Test Case 6: User wants to see analysis of expenses.
Input: Users selects “Analytics” option from main screen.
Output: User will enter into “Analytics” option and will be
able to see details analysis of expense.
Test Case 7: Users wants to see past history of expenses.
Input: Users selects “History” option from main screen.
Output: User will enter into “History” option and will be
able to search for past details of expenses.

Page 6 of
1.2.1.1 Range partitioning
In our app we take user input with buttons for most of the
activities. So, we do not have to worry much about range
values. But there are also some string inputs in some
activities in our app.
We used Java built in data type String for those inputs. The
maximum length of String in Java is 0 to 2147483647. That
means we can have 2147483647 characters in our string input
at most. In real world this is impossible and impractical to
give have these many characters to be in a string. Therefore,
the limitation of output for the range of a particular value is
irrelevant in our app. The only limit for our output is the
capacity.
1.2.1.2 Set partitioning
Test Case 1:
Input: Type valid email and password in the signing in
field.
Output: For correct info, user is moved to main activity
screen.
Discussion: For valid input, the output is as expected.

Test Case 2:
Input: In the search box of “History”, select any date which
has information about expenses.
Output: Shows details of the expenses of that day.
Discussion: For valid input, the output is as expected.

Test Case 3:
Input: In the budget field of “My Budget”, type “ansddh”
as input
Output: Shows warning (invalid type of input, expected
type is number)
Discussion: For garbage input, a warning message is
shown.

Page 7 of
1.2.2 White box testing

1.2.2.1 Statement/Code coverage

In our app MyBudget, the classes are -
AboutAppActivity,AccountActivity,ForgetPasswor
dActivity,DailyAnalyticsActivity,HistoryActivity,
LoginActivity,MainActivity,MonthlyAnalyticsActi
vity,MonthlySpendingActivity,RegistrationActivity
,SelectAnalyticsActivity,TodaySpendingActivity,S
etBudgetActivity,WeekSpendingActivity,
WeeklyAnalyticsActivity.
The main functionality of this application is to help the
users to maintain their personal finance effectively by saving
daily, weekly, monthly expenditures and compare expenses
with budget.

Test Case 1:
Input: Select ‘add budget item’ option from “My Budget”
and fill up the provided fields.
Output: The newly created budget item will be
showed in the item fields.
Discussion: The functionality of add budget item is
working properly.
Test Case 2:
Input: Select “Daily”, “Weekly” or “Monthly” option.
Output: Users will be able to save expenses item-wise.
Discussion: The functionality of saving expenses is
working properly.
Test Case 3:
Input: In the search bar of “History”, a date is selected
Example: 1 February, 2022
Output: Shows the detail information of expenses of that
day.
Discussion: The functionality of the fixture is working .

Page 8 of
1.2.2.2 Branch and conditional coverage
The home screen of the application has buttons for navigating
My Budget, Daily, Weekly, Monthly, Analytics and History.
Here the control flow of every condition is tested by some test
cases:

Test Case 1:
If we click on the signup button, it will take user to create
new account page.
Here the new user will have to give some personal
information like name, age, profession, email address
etc.
Test Case 2:
If a user clicks on “My Budget” option it will enable the
user to add or edit budget items.
Test Case 3:
If a user clicks on “Daily” option it will enable the user to
save daily expenditure item-wise.
Test Case 4:
If a user clicks on “Weekly” option it will enable the user
to save weekly expenditure item-wise.
Test Case 5:
If a user clicks on “Monthly” option it will enable the user
to save monthly expenditure item-wise.
Test Case 6:
If a user clicks on “Analytics” option it will enable the
user to see and compare the expenses and budget item-
wise in a detailed way.
Test Case 7:
If a user clicks on “History” option it will enable the user
to search and see the expenses of a selected day.

Page 9 of
1.2.2.3 Path Coverage
An example is given below considering the number of
distinct paths through the program is traversed at least once

Test Case:
On the main screen of our application, there is a navigation
menu which includes My Budget, Daily, Weekly, Monthly,
Analytics and History.
If a user clicks on “My Budget” option it will enable the user
to add or edit budget items.
If a user clicks on “Daily” option it will enable the user to
save daily expenditure item-wise.
If a user clicks on “Weekly” option it will enable the user to
save weekly expenditure item-wise.
If a user clicks on “Monthly” option it will enable the user to
save monthly expenditure item-wise.
If a user clicks on “Analytics” option it will enable the user
to see and compare the expenses and budget item-wise in a
detailed way.
If a user clicks on “History” option it will enable the user to
search and see the expenses of a selected day.
Log out option is uses for logging out from the application.

Discussion: The number of distinct paths through the

program is traversed at least once and all the outputs are
satisfactory.

Page 10 of
2. Integration Testing
We are going to use all three strategies to test the interface among
subsystems and interactions among software modules. We will use
bottom-up, top-down, and sandwich testing modules to locate if there
are any errors in the app.
2.1 Bottom up testing

The lowest submodules in our app are -

MainActivity,SetBudgetActivity,TodaySpendingActivity,Wee
klySpendingActivity,MonthlySpendingActivity,SelectAnalyti
csActivity,DailyAnalyticsActivity,WeeklyAnalyticsActivity.
MonthlyAnalyticsActivity, HistoryActivity.

MainActivity: After a successful login, user will be moved to the

main activity. Mainly all the options will be shown in the main
screen. There is a navigation menu. All the app options will be
shown in the menu.
We have checked the subsystem and it works fine. We can move to
other activity and move back to the main activity successfully.

SetBudgetActivity: In the main screen, there is a option called “My

budget”. If a user selects this,(s)he will be able to add or edit budget
item.We have checked the subsystem and it works fine.

TodaySpendingActivity: In the main screen, there is a option

called “Daily”. If a user selects this,(s)he will be able to save daily
expenses. We have checked the subsystem and it works fine. We can
move back to main screen from this activity.

WeeklySpendingActivity: In the main screen, there is a option

called “Weekly”. If a user selects this,(s)he will be able to save weekly
expenses. We have checked the subsystem and it works fine.We can
move back to main screen from this activity.

Page 11 of
 MonthlySpendingActivity: In the main screen, there is a option
called “Monthly”. If a user selects this,(s)he will be able to save monthly
expenses. We have checked the subsystem and it works fine. We can
move back to main screen from this activity.

SelectAnalyticsActivity: In the main screen, there is a option

called “Analytics”. If a user selects this,(s)he will be able to see the detailed
comparison between expenses and budget. We have checked the
subsystem and it works fine. We can move back to main screen from
this activity.

DailyAnalyticsActivity: Inside the “Analytics” option, there is

another option called “Daily Analytics”. If a user selects this,(s)he will
be able to see the detailed comparison between daily expenses and budget. We
have checked the subsystem and it works fine. We can move back to
main screen from this activity.

WeeklyAnalyticsActivity: Inside the “Analytics” option, there is

another option called “Weekly Analytics”. If a user selects this,(s)he will
be able to see the detailed comparison between weekly expenses and budget.
We have checked the subsystem and it works fine. We can move
back to main screen from this activity.

MonthlyAnalyticsActivity: Inside the “Analytics” option, there is

another option called “Monthly Analytics”. If a user selects this,(s)he
will be able to see the detailed comparison between monthly expenses and
budget. We have checked the subsystem and it works fine. We can
move back to main screen from this activity.

HistoryActivity: In the main screen, there is a option called

“History”. If a user selects this,(s)he will be able to search for the past
detailed information about expenses and budget of a specific date. We have
checked the subsystem and it works fine. We can move back to main
screen from this activity.

Page 12 of
2.2 Top down testing
The top-level submodules in our app are - RegistrationActivity,
LoginActivity, ForgetPasswordActivity, AboutAppActivity ,
AccountActivity, in a hierarchical manner. Their sub-modules and
interactions are given below:

RegistrationActivity: This part of the app enable the new user to create
new account. We checked the subsystem and were satisfied with the
result.

LoginActivity: User will be asked to enter credentials i.e. Email and

Password. For correct credentials user will be moved to the main activity.
But for incorrect credentials an error message will be shown. We have
checked the subsystem and it works fine.

ForgetPasswordActivity: If any user forget his/her password this part will

allow them to recover the lost password. We checked the subsystem and
were satisfied with the result.

AboutAppActivity: If any new user wants to know about how to use the
app or what the app does, this part will provide the information. We have
checked the subsystem and it works fine.

AccountActivity: The account activity contains the user account creation

page and database. From here the user can create their account using their
google account. We checked the subsystem and were satisfied with the
result.

Page 13 of
2.3 Sandwich testing
The submodules in our application are -
AboutAppActivity,AccountActivity,ForgetPasswordActivity,
DailyAnalyticsActivity,HistoryActivity,LoginActivity,Main
Activity,MonthlyAnalyticsActivity,MonthlySpendingActivity
,RegistrationActivity,SelectAnalyticsActivity,TodaySpendin
gActivity,SetBudgetActivity,WeekSpendingActivity,
WeeklyAnalyticsActivity. Submodules and interactions during test
cases are given below:

Test Case 1:
The user clicks the user account button and creates
his/her account using a google account. Then they
can log into their account and add or edit their
budget details. Interaction between navigation
options, home and data update requests these sub-
modules worked fine and perfectly.

Test Case 2:
If a user clicks on one specific option from the
main screen, they will enter into their
selected option and interact with the app .
If the user selects any date from the provided
calender in the “History” option, user will be
able to see detail information of expenditure
and budget of that day.

Page 14 of
3. System testing

In this section, System testing, we will discuss about the behavior of our
entire system.
3.1 Functional testing

The functional requirements of our system are:

▪ User can Set/Edit Personal Profile Details
▪ User can add or edit new budget item
▪ User can save his/her expenditure on daily, weekly or monthly basis
▪ User can see the analysis of expenses and budget on daily, weekly or
monthly basis.
▪ User can see past history of expenses anytime.

Test Case 1:
User can Set/Edit Personal Profile Details
Input: User gives Name, age, mobile number, Email, password.
Output: Information saved on the Firebase real-time database.
Discussion: Functional requirement of user can set or edit
Personal Profile Details is checked and it works perfectly.

Test Case 2:
User can add or edit budget item.
Input: User clicks on add button inside the My Budget option and provide
needed information or clicks on any budget item and then change and save.
Output: Budget item saved or edited as user wanted.
Output: The blood group of having these users will be shown.
Discussion: Functional requirement of user can add or edit budget
item is checked and it works perfectly.

Page 15 of
Test Case 3:
User can save his/her expenditure on daily, weekly or monthly basis
Input: User selects Daily, Weekly or Monthly option and save
expenses.
Output: Information about expenses are saved on the Firebase real-
time database.
Discussion: Functional requirement of user can save his/her
expenditure on daily, weekly or monthly basis is checked and it
works perfectly.

Test Case 4:
User can see the analysis of expenses and budget on daily, weekly or
monthly basis.
Input: User selects Daily, Weekly or Monthly inside the Analytics
option.
Output: Information about expenses and budget are shown on the
sc r e e n .
Discussion: Functional requirement of user can see the analysis of
expenses and budget on daily, weekly or monthly basis. is checked
and it works perfectly.

Test Case 5:
User can see past history of expenses anytime.
Input: User selects a specific date on the provided calender.
Output: Information about that day are shown
Discussion: Functional requirement of user can see past history of
expenses anytime is checked and it works perfectly.

Page 16 of
3.2 Performance testing

3.2.1 Security testing

The app MyBudget, uses security provided by Google Firebase.
We used CIA triad (Confidentiality, Integrity and Availability)
to check this app security.

Test Case 1:
Input: User sends data to the admin for database
update.
Output: Data can be seen only by admin.
Discussion: The confidentiality of data is maintained.

Test Case 2:
Input: User sends data to admin for database update.
Output: The exact data sent by user is received by system
admin. The data is not manipulated.
Discussion: The integrity of data is maintained.

Test Case 3:
Input: User uses the app roughly and sends harmful data to
app admin.
Output: App doesn’t crash or take any harmful data.
Discussion: The availability of the system is maintained.

Page 17 of
3.2.2 Timing testing
Our application MyBudget, can be run in real-time mode. But in
offline no functionalities are available. It gives real time
response when the device is online.

Test Case 1:
Input: User selects add new budget item in
navigation menu.
Output: Enables the user to add new budget item.
Discussion: Just a not considerable delay for showing real-
time information.

Test Case 2:
Input: User selects Analytics option from the navigation
menu.
Output: Shows the co m p a r i s o n o f e x p e n s e s a n d
budget item-wise.
Discussion: Just a not considerable delay for showing real-
time information. Delay depends on internet speed and Google’s
API.

Page 18 of
 3.2.3 Volume testing
Here we check if the app can handle big amount of data given by the
user. Also check when many users give data same time then if the
app works properly or not.

Test Case 1:
Input: User sends User Name with 1000123 letters.
Output: Data is received and ignored.
Discussion: System avoids unrealistic datasets.

Test Case 2:
Input: 30 users give data at the same time.
Output: All the data sent by users is received by system
admin. The app handled all the data easily and did not crash.
Discussion: Many users can use the app and send data at
the same time.

3.3 Acceptance testing

3.3.1 Alpha test

Issue 1:
There was no way of error handling while connecting to
the database was missing.
Fix: Necessary code to handle errors gracefully was added.

Issue 2:
Some block comments were missing in the codes.
Fix: Necessary block comments were added.

Page 19 of
3.3.2 Beta test

Issue 1:
There was a sizing issue while navigating the application
from a tablet.
Fix: An appropriate device frame skin was implemented.

Issue 2:
Some buttons were not properly aligned in some old devices.
Fix: An appropriate design changes were implemented.

Page 20 of