Team's Response

IMAGE 2023-11-18 21:36:17.jpg

This is less of a bug and more of a suggestion. As the main purpose of this app is for an engineering hiring manager to handle multiple job interviews, it is unlikely for the user to remember the interview by the name of the applicants and more so by the job role of the intended interview. Therefore, the inconvenience is not as severe. Furthermore, the flow that the team trying to achieve is : Find Interview based on Job Role -> Find the corresponding Applicant thereafter for their contact details.

In conclusion, the report can be considered as an enhancement for a better user experience which is valued but it is not problematic/creates frustration to the user at the moment.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

[x] I disagree

Reason for disagreement: While I acknowledge the team's viewpoint that the primary use case involves finding interviews by job role, I maintain my position that the inability to find or list interviews for a specific applicant is a significant oversight in the app's design, warranting a medium severity classification.

I disagree with the notion that the applicant name is not used for the interviewer. For example, when an applicant have completed an interview, the user have to give a rating to the user, when the user need to find the specific applicant to give the rating, they will still need to go through the list, even if the list is filter by job role. As mention in another response (issue id #4 in catcher), the team intend the app to have the ability to first make the interview as done, then only rate the interview, these two designs will contradict each other and may not work well in practice.

Rationale for Disagreement:

Consistency with Application Purpose: As an application designed for managing interviews, being able to swiftly locate interviews by applicant name is not just an additional convenience but a core necessity. This functionality directly impacts the primary purpose of the app, making its absence a medium-level concern rather than a low-level one. The team's response on the flow of using the app is undermining how the real user works, and it's an assumption which will lead to design that is less useful to the intended user, hence it is an feature flaw rather. User Experience: The current limitation forces users to manually scroll through the app, which is inefficient and counterintuitive, particularly in cases with a large number of interviews. And it mentioned in the UG that the app is designed for fast typing, having the need to scroll in the flow of using the app. Design Limitation: The lack of this feature restricts the app's usability, making it less accommodating for varied user needs and workflows.

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Severity: When compared to other issues that might be categorized as low severity, such as purely cosmetic concerns or minor inconveniences, the inability to efficiently search for interviews by applicant name is a more substantial limitation that warrants a higher severity classification. As I faced such inconvenience when testing the app with just 7 applicants on the app. Even if there's a filter function, having to go through all the records is still time consuming. By reevaluating this issue as a medium severity FeatureFlaw, it would acknowledge the importance of versatile search capabilities in enhancing the app's overall user experience and functionality.

tanboonkhong / pe

Should be able to Find/List Interview for a specific Applicant #3

Team's Response

Items for the Tester to Verify

:question: Issue response