3

In my application there is a 'Reset' button and upon pressing the reset button some fields in application page should be enabled and some should be disabled. Along with reset button, there are other buttons like save and cancel which are working fine but the expected behaviour of the 'Reset' is not happening.

I want to ask what severity should I assign to this kind of defect related to reset button?

Severity has following options:

1)Critical 2)High 3)Minor 4)Trivial

I have assigned 'High' severity to this defect. Have I done wrong?

Moreover, what priority can this defect have?

Priority has values:

1)High 2)Medium 3)Low.

I have also raised this question here.

closed as primarily opinion-based by dzieciou, bish, Helping Hands, Kate Paulk, Michael Durrant Dec 17 '15 at 12:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • In the context of your application, how important is this Reset button? You said it's now working as expected. What does the Reset button do now? Does it just do nothing? Does it wipe out the database? Does it crash the application? Does your shop have definitions as to how Severity and Priority are to be used? What are the defaults for Severity and Priority in your shop? Without knowing these - we cannot tell if "High" is appropriate or not. – Joe Strazzere Dec 13 '15 at 2:37
  • @Joe Strazzere: Upon pressing reset button some fields on page should become enable which is not happening so. Upon pressing reset these fields remain in disabled state but they should become enable. – a Learner Dec 13 '15 at 2:42
  • Priority is not something testers usually set but rather stakeholders. It says how urgently the fix must be applied. The decision is made based on multiple factors, severity included, but also time and resources required and available to fix, ROI, etc. See: sqa.stackexchange.com/questions/7535/… – dzieciou Dec 13 '15 at 9:49
  • Did your team decided which severity means what? The meaning may vary from one company to another. See sqa.stackexchange.com/questions/7531/… for more. – dzieciou Dec 13 '15 at 9:53
5

This question would require an entire book as answer and probably it would not be enough exhaustive. Anyhow, first of all you should know what methodology has been adopted by your dev team or at least what you mean for priority and severity then you should also define the severity and priority levels. What is high? What is low? What is critical?

However in order to give you some inputs for you to start your evaluation I can say that:

  • Severity (if it is as I expect an objective evaluation of how the unexpected behaviour is critical): If clicking the reset button you corrupt the system you should set level critical while if the only consequence is that you have to clean up textboxes, combos, etc. you should set it as low (it doesn't matter if you have to reset tens of fields it is only annoying but it is not a dangerous action)
  • Priority (if it is as I expect a point of view like the customer's one): Is it blocking you by performing further tests of the system? So the priority is high otherwise it is low. The difference with the severity is that when the number of tracked bugs will start decreasing you can change the priority of bugs according to the list of remaining malfunctions.

Not the answer you're looking for? Browse other questions tagged or ask your own question.