Stupid QA tester



  • Earlier today, I mentioned that we had this huge DB where people search on descriptive, rather than indexed keys. I just now encountered a complaint from one of our QA testers on a critical, top priority; job-one; must be done now issue...

    The stack trace (I had to rerun the app) indicates a null pointer exception on a ticket-id (PK). I spend 30 minutes walking through the code per the stack trace in the logs. I finally get to some funtion in the middle of the stack that looks familiar. I had modified it last week to check for orders that don't have a ticket associated with them (special case). My first thought was that someone trashed my code. No such luck; the check was right there at the top of the function.

    Long story short, someone truncated one of the transaction tables (the one with all of the parent records) and so the person testing the program was running a report on a zillion child orders that had parents, but the lookup failed because the table with the parent records had been truncated.

    In our particular system, if you run it a second time, it overwrites the log files. I've always trained anyone testing my code to look in the logs for exceptions and to mail me the stack traces. These guys won't do that because they're only supposed to see if it works, not figure out why it doesn't work (I contrast debugging the code with saving an error message for me to work with).

    In essence, the QA guy said: I don't know how to set up the data to do my job, the app doesn't work, I don't know why, I don't know what I did, and the only record of what happened has been trashed because it's not my job to preserve it for you.

    Wheeee!

     



  • "It doesn't work" bug reports are always the best.  I do prefer the tester who gives you some information over the one who attempts to give you "the relevant" information.  Had quite a few situations where I've looked at a stack trace wondering why some variable was never initialized, only to find that a warning had been logged saying exactly what the problem was.  At least with the guy who gives you nothing, you don't assume you have the full set.



  • @vt_mruhlin said:

    "It doesn't work" bug reports are always the best.  I do prefer the tester who gives you some information over the one who attempts to give you "the relevant" information.  Had quite a few situations where I've looked at a stack trace wondering why some variable was never initialized, only to find that a warning had been logged saying exactly what the problem was.  At least with the guy who gives you nothing, you don't assume you have the full set.

    Don't get me wrong, I never trust anything a QA tester tells me, but the more info they give, the more quickly I can zero in on the problem.



  • That's nice. So if a QA just checks if it works or not - I definitely don't want to be dealing with your company. I  had a long conversation with one of the ladies working with a program that I wrote about 10 years ago. She was reporting me "the program doesn't work and it hasn't been working for a while now and I cannot do my job because I cannot enter anything". A few times after investigating where the hell the problem is, it turned to be a very minor problem and in a special case that wouldn't work - like when entering a too long company name, which is being truncated, but she had to enter it or the invoice wouldn't be valid. However she was giving me crap for a while until I spoke to her that it's basically useless to call me with "it doesn't work, and hasn't been working for a while" unless she can provide some more information like what she did before, what and how she managed to crash the application so we can reproduce this, anything else is just a waste of time to speak - I wouldn't understand it anyway so why bother to listen. She commented that I was way too arrogant and she's older than me so I should treat her with respect, but since this conversation she called me only a few times and the info I got was really helpful.


Log in to reply