Test Report:
Task1 Solomon (Front End)
The front end was built using Angular 6 as a single page application. There are seven components inside this application communicating via observables. These components are:
The Authentication component: which has the Login and Register subcomponents.
The Header component: which is used to show notifications in relation to username and user avatar.
The Make Complaints component: which is used to let the user make complaints in case there was a denial of tax return.
The Request Input component: which is used to allow the user input his personal and financial data. Also does basic client side validation.
The show responses component: which is used to show all notifications concerning the status of the request for a tax refund.
And the welcome component: which is the component the user sees when ever the user is not logged in.
Services
We have a data service at the request input component that posts the data against the necessary interface required by the specification on the workflow management system.
We also have a complaint service at the complaint component which allows posts the complaint data against the necessary interface as required by the specification on the workflow management system to the database.
Moreover, we also have a shared service called ui-features which is used to listen to events and show a wait animation for better user experience.
The Authentication service is handled by Google Firebase Auth. Although not used in sensitive government offices such as a tax bureau, we have included here a convenient login for users (students who will be testing out the system) to use either their google or facebook accounts in addition to registering and using username and password for logging in.
Pages
Admin Page: The admin is the employee that brings the human touch to the system. This person will go through a list of complaints and decides on making changes to the decision through his own only interface on the front end.
Complaints making window of opportunity expires as is the case in the real world. To show this, the system also does the same using shorter delays for demonstration sake.
The Response page: this is a page where the user can come again and again to see what happened to his request in a later time.
The frontend is hosted on Google Firebase Hosting.
Task2: Patrik (Input form validation)
Input form validation application is a simple microservice which is deployed on Heroku. The microservice is subscribed to external tasks defined in the BPMN model so whenever a new form is submitted, the microservice completes the task and passes the information onwards.
The validation requires the following information from the form:
User information (firstName, lastName, emailAddress, childrenCount)
Address (street, city, state, postCode)
Financial information (iban, incomeX, incomeY, incomeZ)
Validation consists of simple restrictions that users don’t submit overly long strings and that everything that should be numbers are (positive) numbers and that all fields have a value. For example postCode must be 4 numbers and IBAN exactly 20 characters. IncomeX, Y and Z are incomes from different sources and must be between 0 and 99999999. Email address validation checks that the address is a valid email address (follows regex ^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$).
The response generates two variables, formValid which can have either values 1 (valid) or 0 (invalid) and errorMessage, which contains all the errors that user input might have had. Inspecting errorMessage-variable reveals for example the following errors in the input data if invalid data was submitted:
* Children below 18 must be defined.
* IBAN must be exactly 20 characters.
Based on the formValid value, the process moves then through the workflow.
Task3 (Michael)
The calculation process is a microservice deployed on Heroku. It requires the following input-data: four different types of income, childrenCount). Based on the income types it sums all of them up in order to have a basis for tax calculation. For each child a fixed amount is deducted from the income total. Depending on the income class, different tax rates are considered and the tax amount is calculated. We are then simulating taxes received over the last year for the particular person by taking the calculated tax amount and multiplying it by a random percentage in the range of -5 to 5. The calculated tax amount and the simulated tax amount received are compared. The difference between these two is the result of the microservice and passed on. The microservice was tested successfully locally with several different combinations.
Task4 (Paavo)
The complaint process is a microservice initialized by the user ('complain on decision' etc.). The service is evoked by post request from the server. The service randomly assigns the complaint to one of our group by getting the list of group members from camunda. When the user is assigned to the task the workflow will continue to the next block 'assigned complaint' from which the front-end is able to access.
Task5 (Murat)
In principle, task 5 should send system process information to the front end, so that the user and admin receive the info, whether his request was accepted or denied. The camunda engine will also get the result of the business logic.
The log process task is processing the workflow variables to make summaries and send the information to the front-end.
To fulfill task 5, i implemented a microservice. This microservice is executing GET/POST requests to the camunda engine. When a request reaches the log process task, the busines logic of the microservice will begin to run. After the process is finished, the information will be sent to the camunda engine, so camunda workflow can start the next task.
For testing purpose the application was deployed on a local apache tomcat server.
The application has been successfully tested. A camunda process instance was started and the system information send.
Final Testing:
After testing all tasks (=applications) individually on our local machines, we deployed all applications on individual physical servers. We tested all possible ways an individual user may move through the workflow (depending on different types of inputs, calculations, etc.). All generated errors were checked and resolved.
KPI list:
How many people used the system, how many got rejected first time, how many got rejected after complaining, what was the general response of the users when they were complaining, how long did they take to make the complaint, what is the average speed of the system under normal conditions, and under peak conditions, are there any mistakes the system made?
we have 27 people who have used their full student id to make a request.
of those 15 did not get their request accepted
of the 15 all complained
of those who complained, 6 got again rejected
Most inserted gibberish into the complaint text box while some had interesting jokes,
all the users completed the task with the same average time, 1 and a half minute
there was no difference in the system's performance in average use or peak as there was no peak to speak of
