• Author
  • #13362

    As a tester, what things make you really, really angry?


    Poor Business Analyst job when communicating specs (either written or verbally). It drives me bananas 🙂
    Did it also happen to you, guys?


    When test environment/infrastructure fails. We have to wait almost over few hours (> 5hrs) to have the new version of product to be deployed and tested. Any hiccups is ending up a “mad me” in the morning 🙂


    Unclear acceptance criteria and constantly changes on approach of the development (e.g conceptualization, project estimates, etc.)


    Ever moving goals. Whether that’s requirements, expectations, start dates without moving end dates, resource priorities. I like the fluid nature of Agile. But at least thats fixed in the sprint.


    Tested !!! Verfied a bug !! and then we hear,, there is product specification changes went inside, it is not a bug :-p


    My red flag is absolutely: dishonesty.
    I know my first time encountered a client that had received a test report from my project manager (old skool type project / IT organization), that apparently had been altered to reflect a somewhat more positive situation than really was the case. The scope had been narrowed so that cases that failed weren’t in it anymore and the advise was altered to a conditional yes in stead of a conditional no. That was the last time I let the PM communicate results to the client without me knowing what exactly was send AND the last time I send a report in word-format; since then everything goes by (signed) PDF and directly to the client with the PM in cc… luckily communication between IT (test) and business has grown more to a standard way-of-working, but nevertheless I insist as tester to communicate my results directly to the (business/operational) stakeholders.


    1) Frustrations could be because of dealing with unprofessionalism
    2) Disrespecting others time, effort and value add.
    3) High dependency on various teams eg: to bring services up/down
    4) Gaps in cmmunication between dev and the testing team
    5) Intereference in the name of process
    6) Different standard/level/meaning of Quality among the involved teams


    Unreliable test environment where you can’t trust what you see in that environment.
    Then when you find bugs – you get told “don’t worry – that won’t happen in production” – makes you wonder how many bugs you opened could actually be in production and which bugs you missed because of how unreliable the test environment is.


    So much to learn and so much to Explore 😀


    The first that comes to my mind is when a developer goes into a defensive mode and argues why the defect is invalid. I agree defects can be invalid, but getting into an argument is very unprofessional. Defects are not raised to find faults in the work done by a developer. They are raised to make sure that the system is free of defects. Discussing the issue to come up with a valid conclusion should be the way to go.


    I have additional remark: it is one of the most popular threads ;-D very good topic @emmaconnor!
    I plan to organize a discussion panel “What drives you mad at work as a tester?”.

    I’m really angry when developers treat me as a clicker who should thoughtless do the work of automated test – fortunately it is quiate rare thing.
    Also it is a ‘fatal error’ when somebody (business or dev) doesn’t see the sense of testing until the first serious bug, or until something came back from the client because they wanted to save time on testing..


    One more thing is when the test environment is very slow and you literally have to wait for the next page / screen to open.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.