Team's Response

In the current state, no validation is done on the maximum value of payment for any given lesson. This may lead to users using the application overcharging their tutees unneccasarily.

This is not a feature issue. It is intentional for the users to add multiple times as some tutors may conduct lessons and only collect every month (e.g. 4 lessons) and not after every lesson, which is the assumption made in this report. Furthermore, if the tutor makes an error in adding the fee details, he can simply use the payment amount command to rectify such an issue.

It is unclear why this is allowed in the UG.

An example would be: for the first Sunday of the month, he adds the fees of the lesson. However, tutee delays on payment and hence fees accumulate. For the next Sunday of the month, he then adds the fees on this lesson again, hence no restriction should be made. This provides flexibility for the tutor on when he should collect payment.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

[x] I disagree

Reason for disagreement: "This is not a feature issue. It is intentional for the users to add multiple times as some tutors may conduct lessons and only collect every month (e.g. 4 lessons) and not after every lesson, which is the assumption made in this report.". This assumption is not mentioned anywhere in the report. I feel that this could have been explicitly stated to make it clearer to the end users why the collection of payment is not automatically calculated from the day and time of the lessons themselves.

"Furthermore, if the tutor makes an error in adding the fee details, he can simply use the payment amount command to rectify such an issue." That is exactly the point that I am trying to make. Making the step of collecting payments manually allows for a lot of possible errors to occur which is sure to inconvenience the user.

"An example would be: for the first Sunday of the month, he adds the fees of the lesson. However, tutee delays on payment and hence fees accumulate. For the next Sunday of the month, he then adds the fees on this lesson again, hence no restriction should be made. This provides flexibility for the tutor on when he should collect payment.". Not sure how this example applies here. As mentioned in the bug report, automatically calculating the payment amounts based on the day and time of lessons would actually help the user in this scenario. If the tutee delays the payment or not, the fees that he owes can be automatically calculated and shown in the application. It does not takeaway from the flexibility in collecting payment for the user as that is entirely seperate from the actual amount owed. In the current state, the user has to manually add the amount owed and also add the amount received, which is a great inconvenience. With an automatic calculation of amount owed, the user only has to add the amount received manually.

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

[x] I disagree

Reason for disagreement: Not sure how this is a verylow severity as it is clearly not a cosmetic error. As stated above, allowing for the user to manually add the amounts owed and received manually is susceptible to a lot of bugs due to human errors. As the team itself has mentioned, "the tutor makes an error in adding the fee details" is a common occurrence with the current state of the feature. This is a flaw that causes occasional problems to some users and is likely to cause great inconvenience when it happens. Having the management of amount owed be manual also takes away from the effectiveness of the application as a tutee management platform. Hence I feel that this should remain as a Medium severity bug.

rohit0718 / pe

App Allows for Overpayment #6

Team's Response

Items for the Tester to Verify

:question: Issue response

:question: Issue severity