Project 08

We tested our system task by task and the whole system itself. Accordingly to our .bpmn model our process is based on one bet. For the test we create multiple users using our mass account creation tool and verified that emails with the accounts information were sent and received. Furthermore, we verified that users can login with the given details and that activities within the application require a logged in user. All users hat their intended initial balance. Afterwards we verified that the system doesn’t recognize these students as having completed the workflow process already. Accessing the system without any bets created doesn’t create issues in the webapp. We tested if it is possible to successfully create an bet in the system. Therefore we verified if all variables (including the generated Json) where in the right process instance correct created and passed to the next task. We have also tried to enter incorrect values and tested if the program prevents the input of faulty values. All bets have to be listed in the overview ordered by their time left. Bets are not listed in the recommended bets and general bets section. Recommended bets are ordered by the users preference, which at this point are none. In Accept Wager part of the system we verified if it is possible to place a wager. We checked if the wager was placed in the right bet and if the metrics and variables where set right. We also ensured that the json string of the bet with the placed wagers is summed up correct. Furthermore the balance of the user must be updated in the database and in the actual session. A transaction with the relevant data is also saved for each user and each wager on a bet. After placing a wager for a bet the user preferences have changed, which change the ordering in the recommended bets section. The recommendation depends on the chosen category of the bet. To test the Enter Event Result and the Check If Valid task, we created different bets in the system, with a different number of bet result choices to check whether this task allows the selection of the winning bet result as expected. After one of the choices has been selected within this task, we checked if the correct variable has been set in our process for further processing. Next we tested if a provided message to add a comment together with the result is also correctly written into the appropriate process variabel. For this we tried a few Strings of different length. We also tested if it is possible to initiate an appropriate error for our exceptional control flow by trying both boolean values the checkbox in the embedded form allows. It was then tested if the variable was correctly set in our process and if the system then triggers the error in the Check If Valid task and therefore the expected control flow is taken in our process. Once a bet has ended we ensured that users have received email when having a payout and/or refund is issued to them. Furthermore we have checked whether the correct users have had the correct amount added to their balance when a bet has ended or has been canceled. Once a change has occurred in an user’s balance, we made sure that a transaction entry has been added to the database, detailing the change in the balance. In order to test the aforementioned features we have manually created all the necessary conditions such as users, bets, event results, and placed wagers and simulated the workflow of the payout module all whilst monitoring the changes that took place. If a bet gets cancelled every user receives a mail that the payment would be refunded. The balance of the user will be updated by adding the wager to the credit of the user again. After cancellation no more bets will be accepted. After placing a bet the user has completed all actions required for him to complete the process. We verified that the active users page now correctly displays the students active participation. In the end we had a quick look over the metrics page to ensure the correct measurement of KPIs and other statistics. We used the following different bets to test the above mentioned parts of the system: Bet with start in the future and regular end, Bet with start in the past and regular end, Bet with start and end in the past, Bet with regular start and triggered cancellation. We used users with the following attributes: User has no known preferences, User places wagers on not recommended bet, User places wagers on recommended bet. We verified the following areas: Is the bet gone through each task (including an test with error & compensation),Is the input and output of each task as expected, Is it possible to fill in form data (tasklist/human-task) or access and interact with the corresponding web page, Is the communication of each part of the system (webserver, database, refund&compensation) with the bpmn-plattform successful.