search

maj0-0 / pe

0 stars 0 forks source link

Manual testing test case does not produce expected result #2

Open maj0-0 opened 10 months ago

maj0-0 commented 10 months ago

image.png

image.png

When testing out the manual testing commands from the DG, the expected output differs as the phone number does now follow the correct format.

nus-pe-script commented 9 months ago

Team's Response

This is a typo made by me when writing the manual testing instruction, thus I accept the bug.

However, I think that it does not hinder the tester from testing the product. UG has clearly specified the format of the phone number, with proper examples; Appendix : Planned Enhancement have mentioned the plan to accept different format of Singapore number (e.g. 1234 5678 and 1234-5678). I think upon reading these, the tester would have an clear idea of the correct format for phone number.

Additionally, Manual Testing Instruction is only provided as a brief guide to help users get started to with testing our product, thus I do not think that this typo will cause any issue except for the first time the tester tried out this command. In fact, this might not even cause any issue if the tester have first read the UG and Appendix : Planned Enhancement as the typo can be clearly spotted. Therefore, I believe that it is rather uncommon for users to get confused by this mistake, which leads to me lowering the severity level.

At last, thank you for pointing out the typo.

Items for the Tester to Verify

:question: Issue severity

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

Reason for disagreement: I wanted to share some thoughts based on why I think the severity should be kept at Medium:

  1. Enhancing Testing Flow: I noticed that the typo in the phone number format in the DG might lead to some confusion, especially for those who primarily use the DG for guidance. While the DG and User Guide (UG) are wonderful resources on their own, not every tester may cross-reference both documents for each detail. This is particularly pertinent as our course website mentions that the DG should complement the UG. Perhaps ensuring accuracy in the DG could enhance its standalone value and make the testing process smoother.

  2. Clarifying Documentation Roles: Your DG and UG are both fantastic tools serving different needs. I believe maintaining the DG's accuracy is key, as it's a go-to resource for clear and reliable testing instructions. If we could minimize the need to cross-reference with the UG for basic information, it might streamline the testing experience and reduce any possible inconvenience.

  3. Upholding Documentation Standards: As per our course guidelines, which rightly emphasize the importance of accuracy, incorrect instructions are considered bugs. Addressing the typo in something as crucial as the phone number format could prevent any potential missteps in test execution and help us maintain the high standard of our documentation.

  4. Supporting Effective Testing: Adhering strictly to the DG, testers might encounter unexpected scenarios due to the typo, which could lead to some confusion. By just referring to the DG and typing in the commands, the message that the phone number should be a 8-digit number is retuned, but it doesn’t clearly establish that is should be purely numerical and that no additoinal spaces/characters are allowed, so the UG must be referred to for this information. I think addressing this small detail could prevent any misallocation of effort and ensure a more efficient testing process.

As you have stated that "Manual Testing Instruction is only provided as a brief guide to help users get started to with testing our product", I think it's still important that the commands be right. And to summarise, I think the severity should be kept at Medium as when testing the command out, there is no indication in the error message to what is wrong with the phone number, just that it should be 8 numbers, so if I were to replace the "-" with a space " " (a common way that singaporean numbers entered eg. 1234 5678), the error message shows up still. I think the fact that this commands fails when copying from your actual documentation, and that the error message provided on it's own may still not solve the problem justifies the severity staying at medium.