Software Testing: System Development and Implementation Report

This report details a software testing project focused on mobile application development. It outlines the research design, data collection methods (interviews, observations, and questionnaires), and data analysis techniques used to gather information from stakeholders. The report discusses the iterative SDLC methodology and system implementation using Android Java for Android Studio. It explores various testing phases, including usability, functionality, and non-functional requirements, as well as black box and white box testing. The report includes JUnit tests and validation procedures, covering user acceptance testing and system evaluation based on research objectives. The project also involves system analysis and design, utilizing Use Case Diagrams, Sequence Diagrams, and Entity Relationship Diagrams to refine the mobile application's physical and logical designs. The report emphasizes the importance of testing and validation in ensuring the quality and functionality of the developed mobile application.

SOFTWARE TESTING
System Development
Introduction
Rigorous research and design methodology has to be undertaken to explicitly describe how
each research objective for this study will be fulfilled. The results from this analysis guided
the mobile development and testing phases to ensure that an application that effectively
facilitates the activities regarding the subject of study via the use of mobile app technology
Deak, Stålhane and Sindre, (2016).
Research Design and Development
Research design is the plan and structure of investigation so convinced to obtain answers to
research questions. It is the glue that holds together all the elements in a research project Pei,
Cao Yang and Jana, (2017). There are many activities that are fundamental for the success of
this project each to be carried out as specified in different sections.
This objective has been achieved by the use of iterative SDLC methodology testing every
module of the system once it is completed.

Data Collection
The research focuses on getting information and data from relevant stakeholders in
institutions encompassing the software and the learners in higher institutions. The methods
used to achieve this are interviews, observations and questionnaires. To supplement the data

collected from interviews the research also uses observation and questionnaires as methods of
data collection.
Data Analysis and Synthesis
The data collected via the above means will be analysed by and presented in a systematic
manner. Data was collected regarding various types of animals and their different behaviours
with some information on how to tame the animals. Bar graph, pie chart diagrams will be
used to show the relationship between the various factors in the wild field and the effects.
This is the link between the raw data and the significant results leading to relevant conclusion
and inferences, the analysis is intended to be result oriented, for that matter data will also be
tabulated, from this analysis the application requirements and specifications will be drawn
and forwarded on for the design and implementation.
Planning and Requirement Analysis
It was imperative for the study to capture user opinions of the shortcomings of the current e-
learning platforms in the country especially in the institutions of higher learning, to do this a
survey was conducted in the planning phase by the use of Google Forms and sent to a sample
of 80 people in the researcher’s mailing list. A copy of the survey can be found on Appendix
A. The criteria of choosing the sample respondents for the survey familiarity with Google
Surveys and Internet-savvy. Google Survey was the appropriate tool since it is free and
guides the outcomes into a shareable spread sheet (Randal, 2015). With this, it is easier to
disseminate as compared to the Microsoft counterparts. The results informed the requirement
analysis as the respondents clarified the type of mobile application would meet their
requirements.

System Implementation Tools and Techniques
This chapter discusses on how the system was implemented from scratch from the stage of
conceptualizing the idea to the point of actualizing it through coding.
Mobile application
There are various ways of developing mobile applications, the chosen method all depends on
the requirements of the users, for instance there are various frameworks for mobile
development such as Framework7, Ionic, Cordova and even xamrin, all of them could
facilitate this project however they support multi-platform aspect of mobile development
which was not necessary for the project, this hence led to the settling on Android Java for
android studio.
Cordova mobile
The mobile application platform is a cross-platform such that it supports; IOS, android and
windows phones. The source code has been written in TypeScript utilizing the cross-platform
Apache Cordova tools for visual studio and Node.JS tools for mobile development.
JavaScript Object Notation (JSON) have been used to provide the linkage between mobile
application and the firebase database.
Android mobile (Kotlin and Java)
It can also be done by Java or Kotlin for Android studio exclusively, in this case the project is
developed in Java for android implementing the use of Object Oriented aspects of
inheritance, polymorphism and abstraction.

System Testing and Validation
Usability testing
Usability testing is done in three dimensions to ensure the quality of the system; these include
as per Garousi and Mäntylä, 2016).:
Moderated in-person: A organiser is co-spotted with the member frequently in a workroom.
Moderated remote: The contributor and organiser are in diverse places. Screen distribution
software such as the GoTo meeting or WebEx permits the organiser to at all timepiece the
contributor tries errands with software or a website and permits for searching on glitches.
Unmoderated remote: Software from Measuring-U or Loop11 manages responsibilities
mechanically to contestants everywhere the domain. You can gather a great deal of
information rapidly and for a portion of the price of in-person challenging. In numerous bags
you have a footage of the member’s screen and webcam, but there’s no method to
concurrently interrelate with all members.
With the type of border and dissimilar challenging approaches in attention here are the five
kinds of usability tests, apiece lecturing a dissimilar investigation objective.
Learn tracking, Benchmarking, eye tracking and competitive methods.
Usability testing has been conducted to determine the usability of the application, the APK
will be given to a sample of users to try use the application and give a feedback on the
experience.
Functionality testing
The functionality testing will be conducted to ensure the developed mobile application
conforms to the requirements as specified in the early stages.

Functional testing is a quality assurance (QA) procedure[1] and a kind of black-box
challenging that centres its test bags on the riders of the software constituent underneath test.
Purposes are verified by nourishing them input and investigative the production, and interior
program assembly is infrequently careful unlike white-box challenging[2] Useful challenging
is directed to assess the acquiescence of a system or constituent with quantified
handy necessities.[3] Practical challenging typically defines what the system does ,Barr,
Harman, McMinn, Shahbaz, and Yoo, (2015).
Practical challenging does not suggest that you are challenging a purpose or a technique of
your unit or class. Practical challenging examinations a slice of functionality of the entire
system.
Practical challenging varies from system testing in that practical challenging "settles a
program by inspection it in contradiction of ... design document(s) or requirement(s)",
whereas system testing "validate[s] a program by inspection it in contradiction of the
available user or system supplies" (Kaner, Falk, Nguyen 1999, p. 52).
Non-functional requirements
The regulator system requires at least 3G internet connection for the peer-to-peer connection
Hardware & Software requirements
 At least 4GB RAM
 At least 2.0GZ processor speed
 100GB Hard disk and above
 Mobile phone; Android, IOS or windows phone, any of the three
System requirements
 Operating system; windows or MAC OS
 IDE: Android Studio or Eclipse
 Programming language: Android Java

 HAXM emulator or real device such as phone of course android phone
 Database; firebase database
 At least 3G internet and above
Black box testing
This method examined functionality such as;
Black-box testing is a technique of software challenging that scrutinises the functionality of
an application deprived of scrutinising into its interior constructions or mechanisms. This
technique of test can be practical almost to every single neck and neck of software
challenging: component, incorporation, system and recognition. It is from time to time
denoted to as requirement-based challenging.[1]
Black box testing examines the real function of the system, checks if the system meets the
requirements that it was meant for. For this case black box testing checked the regulation
process of the mobile app user or users.
In the same package, we create a folder give it a name: Junit test
import static org.junit.Assert.assertTrue;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
/**
* JUnit Test case for the Regulator1 class.
*
* @author Mihai Fonoage
*
*/
public class Regulator1Test {
private regulator1 regulator1;
/**
* Sets up the test fixture.
* (Called before every test case method.)
*/
@Before

public void setUp() {
regulator1 = new Regulator1(6, 4);
}
/**
* Tears down the test fixture.
* (Called after every test case method.)
*/
@After
public void tearDown() {
regulator1 = null;
}
/**
* Test method for {@link edu.fau.csi.junit.Regulator1#add()}.
*/
@Test
public void testAdd() {
assertTrue(regulator1.add() == 10);
}
/**
* Test method for {@link edu.fau.csi.junit.Regulator1#subtract()}.
*/
@Test
public void testSubtract() {
assertTrue(regulator1.subtract() == 2);
}
/**
* Test method for {@link edu.fau.csi.junit.Regulator1#multiply()}.
*/
@Test
public void testMultiply() {
assertTrue(regulator1.multiply() == 24);
}
/**
* Test method for {@link edu.fau.csi.junit.Regulator1#divide()}.
*/
@Test
public void testDivide() {
assertTrue(regulator1.divide() == 1.5);
}
/**
* Test method for {@link edu.fau.csi.junit.Regulator1#divide()}.
*/
@Test(expected = ArithmeticException.class)
public void testDivideByZero() {
Regulator1 regulator1 = new Regulator1(6, 0);
regulator1.divide();
}
}
//Right click on the regulator test class
White box testing/ Structural Testing

According to Jurj, Rotar, Opritoiu and Vladutiu, 2018) White-box challenging also known
as pure box challenging, glass box testing, see-through box challenging, and physical
challenging is a technique of challenging software that tests interior constructions or
mechanisms of an application, as opposite to its functionality i.e. black-box testing. In white-
box challenging an interior viewpoint of the system, as well as programming abilities, are
rummage-sale to plan test gears. The tester selects contributions to workout paths over and
done with the code and control the predictable productions. This is similar to challenging
protuberances in a circuit, e.g. in-circuit testing or commonly referred to as (ICT). White-box
challenging can be functional at the unit, addition and system stages of the software
challenging process. Although old-fashioned testers have a habit of to reason of white-box
testing as existence complete at the component neck and neck, it is rummage-sale for
incorporation and scheme challenging more commonly these days. It can test pathways in the
interior a component, pathways flanked by components all through incorporation, and amid
sub-systems all through a scheme–equal examination. Nevertheless, this technique of
examination plan can expose numerous mistakes or glitches, it has the possible to slip undone
portions of the requirement or absent specifications.
White-box test enterprise methods take in the next cypher attention criteria:
 Control flow challenging
 Data flow testing
 Division challenging
 Declaration attention
 Choice attention
Adapted disorder or choice attention
 Prime path testing
 Trail challenging
This method examines internal structure of the application as far as programming skills are
concerned, checks for test cases. This ensured unnecessary codes are eliminated or
commented out for the efficiency of the system.

User acceptance testing
The system was tested on Android phone, browser for web view and on Android browser
simulation to see how it functions on different platforms. This is tested in the real world, the
intended users are sampled out to use the given system for a while and user experience
feedback regarding the experience of using the software in terms of functionality and
reliability Takanen, Demott, Miller and Kettunen, (2018).
System Validation

Validation is done before and after use of the mobile application for its intended purposes.
Evaluation
The application will be evaluated basing on the research objectives for developing the
application that will facilitate work that it was meant for, data synchrony hence reduces the
current stress seen in systems aspect for use, evaluation,Beyer, 2019).
System Analysis and Designing Phase
In this phase, physical and logical designs of the mobile application have been constantly
refined using Use Case Diagrams and descriptions. Sequence Diagrams and Entity
Relationship Diagrams. These diagrams have been modified using Unified Modeling
Language (UML) notation Mustaqbal, Firdaus and Rahmadi, (2016).

A Use Case Diagram have been used to describe a set of actions that the system should
perform in association with one or more external actors (Bell, 2004). A Use Case Diagram
has been drawn to show the major actions that are performed by the mobile application. A
Use Case description has been used to expound on the major use cases depicted in the whole
use case diagram.
Below is a simple use case diagram of the system designed in Unified Modelling Notion
commonly known as UML notion.
Sequence Diagrams have also been used to show the interactions between objects in the
sequential order that the interactions occur Jacob and Prasanna, (2016).
Introduction
This section describes the tools that were used to analyse and design the system, they include
use case, ERD, logical and physical diagrams.
Logical design