jnjy / pe Goto Github PK

Would be better if provide a subheader for all the other manual test cases.

Steps to reproduce:

1. add n/NUS r/AI Engineer s/Accepted d/2023-04-14 c/woohoo nus work
2. add n/NUS r/AI Engineer s/rejected d/2023-04-14 c/woohoo nus application

Expected:
My thought is that since InternBuddy is a more personalised internship or job application tracker, allowing the user to accept and reject the same job may be odd (at the same date).

Suggestion:
Team can maybe try adding an unique internship/job application ID to uniquely identify each job posting instead of using status, name and date to check for duplicate, to prevent such odd occurrence from happening.

Severity is given as low because it does not affect normal application operation.

The same instructions is not clarified in delete-field, hence the reader may attempt to delete listing with field not in the current filtered list. As I did the same thing as well, assuming I can delete job with listing not in the list after find.

clarification that has the same effect as delete index is not mentioned here

Labelling it as documentationbug as understand that not being able to delete jobs not in the current filtered list has its benefits. Will be good if it is included in the UG as a constraint to avoid repetition in two different sections.

I believe that this is to tell the reader that these are the status that can be used for the upcoming command. However, when placed together in a single code block makes it confusing for the reader, hence possibly hinders the reader's understanding on this command when trying out.

Suggestion:
Can try separate the status instead. For example, NEW / OFFERED / ASSESSMENT / INTERVIEW

Steps to reproduce:

1. add n/Apple r/Web Developer s/New d/2023-02-01 t/Front-End
2. add n/Apple r/Web Developer s/New d/2023-02-01 t/Back-End

Checking duplicates for same company, date, role and status may not be extensive enough for the user. From my understanding, many big companies have the same role (e.g. software engineer as general role name) focuses on different work, for example, back-end and front-end. My suggestion would be try to check duplicate based on the specific role.

Severity low is given as it does not affect the functionality of the application.

this is a dummy bug >

Below are examples of all repetitions of INDEX constraint:

View:

Copy:

Suggestion:
Can add these example into the constraint section of UG to avoid repetitions.

Steps to reproduce:

1. add n/NUS r/Software Engineer s/Applied d/2010-02-01 c/outdated application

Expected:
My thought is that it will reject insertion of new application with deadline that has already passed, as applying for past job ad will result in nothing. Hence, it will be just another item in the memory.

Actual:

Date of insertion of the new job posting: 14-04-2023

Suggestion:
It would be better if there is a check on the date of insertion of NEW application to ensure that the new job applied always has a deadline which is in the future.

Severity is given as low because it does not affect normal application operation.

Steps to reproduce:

1. add n/NUS r/Software Engineer s/Applied d/2021-02-01 c/2103 pe wooo

2. edit 9 s/accepted

Expected:
My thought was that InternBuddy will prompt the user for the date of acceptance instead of using the current date and carry forward when status of application is updated.

As mentioned, I think the team can include compulsory date parameter when the user attempts to change the status of application to ensure that the date is always updated with the status.

Severity is given as low because it does not affect normal application operation.

Cheers!