What are valid bugs

  • I have been working in testing for almost 4 years and had never had to ask this question because I worked in highly commercial and critical products.

    Whatever bugs I raised were marked as “to be fixed”.

    Recently I have taken QA ownership of an in-house REST API implementation

    One of the acceptance criteria was that if a user searches for a project which does not exist, the result should be

    project "xxx" not found

    However, if I search for a project named “xxx\n”, the message that is retrieved is

    Project Resource not found

    The developer is the PO of the project and he is insulting me, saying that no one will enter emoji, emoticons, or special characters in the search field. Even if someone enters nothing, the error message is logically correct.

    But the error message is not as expected per the acceptance criteria. Is this a valid bug?

    The work environment is getting toxic as corner case bugs like special characters, spaces, etc. are being treated as silly.

    What should a tester do in this situation?

  • Take a deep breath

    step back

    and look at the big picture

    Talk to folks / your boss about standards. Have a meeting. Agree on standards including items such as special characters. Take short term initiatives this month to reduce long-term repetitive pain next year.

    and allow for humans

    I've lost track of the number of times I've: typed weird characters by mistake; clicked the wrong link; clicked 'ok' by mistake; dropped my keyboard; had my cat walk on my keyboard. These might seem silly or funny or whatever to some, but they are amazingly common. They've happened to me; my wife; friends at work; personal friends - all that's a lot for a pretty small group. Two weeks ago i dropped my keyboard and my display went like 400x600 and it took me 2 hours to fix it - and I was quite motivated because it was (supposed) to be a screen share remote pairing session for an interview!

    Then live by the agreement you make


    • Don't enter bugs outside of the agreement
    • Don't breach the agreement for parts you didn't really like but agreed to anyway
    • Ask in person, such as 3 amigos meeting (product-dev-qa) when you meet an edge case
    • Generally prefer asking product owner over developers

    To avoid toxicity and being seen as silly, take initiative in these areas and you'll be seen as quite serious without seeming toxic (although it depends on how you act)

    Remember to focus on the business and the business goals, not just 'tests and bugs'. When you relate bugs to lower revenue or less customers it means more to the business.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2