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.

Improve this question
4
  • 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, 2015 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, 2015 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, 2015 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, 2015 at 9:53

1 Answer 1

Reset to default
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.
Improve this answer

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