Magical Telepathic Software Required



  •  So I got into work this morning to find this newly raised bug report waiting in my inbox.

    I had to strip out quite a bit to anonymise it, but hopefully there's enough context left to see why it made me chuckle.

    [Mobile device] isn't logging the "No network connection" error in web app
    --------------------------------------------------------------------------
    
                 Key: ***
                 URL: ***
             Project: ***
          Issue Type: Bug
          Components: [mobile device software]
    Affects Versions: ***
         Environment: ***
            Reporter: ***
    

    The "No network connection" error [...] is not logged in the [...] web app [...].
    The error is displayed in the [mobile device] UI and logged in the [mobile device] log.

    Repro:

    1. Install web app and configure [mobile device] to use this web app.
    2. [Trigger the device to connect to the server]
    3. At the command prompt asking the user if they want [to connect], put the phone into offline/flight mode, then go back and accept the prompt.

    Expected result:
    [mobile device] UI displays "No Network Connection" [...] The error is logged in the [mobile device] log and reported to the web application [...].

    [...]

    Actual result:
    [mobile device] UI displays "No Network Connection" and the error is logged in the [mobile device] log. However the error is not reported in the web application's [list of errors].

    [...]







  • — What his phone number?
    — Dunno. Give'm a call.



  • So, wait, the bug report is basically -- If I turn off cell and wi-fi on my phone, it can no longer connect via cell or wi-fi?

    Solution: Have user pack up mobile device and ship it back to the vendor, as the user is too stupid to use a mobile device.



  • @Medezark said:

    So, wait, the bug report is basically -- If I turn off cell and wi-fi on my phone, it can no longer connect via cell or wi-fi?

    Solution: Have user pack up mobile device and ship it back to the vendor, as the user is too stupid to use a mobile device.

    They are actually complaining that they can't log a "no network error" to the online service.



  • @XIU said:

    They are actually complaining that they can't log a "no network error" to the online service.
     

     Yup. This came from the test department, not from a user. The tester just took the script literally and recorded the failure, which I suppose is understandable.

     



  • This reminds me of that one time...

    (Me calling my ISP's helpdesk, back when connecting to the internet meant firing up the 56k6 in Windows 98)

    Me: Hi, I can;t connect to the internet, modem acts funny...
    She: That's probably a driver problem, sir.
    Me: Yeah, I thought as much
    She: You can download the latest drivers from our site
    Me ... Didn't I just say my Internet connection was down?
    She: Yes sir, so you will have to sownload the latest drivers
    She: Is there anything else sir?



  •  @steenbergh said:

    This reminds me of that one time...

    (Me calling my ISP's helpdesk, back when connecting to the internet meant firing up the 56k6 in Windows 98)

    Me: Hi, I can;t connect to the internet, modem acts funny...
    She: That's probably a driver problem, sir.
    Me: Yeah, I thought as much
    She: You can download the latest drivers from our site
    Me ... Didn't I just say my Internet connection was down?
    She: Yes sir, so you will have to sownload the latest drivers
    She: Is there anything else sir?

     

    There might have been an implied "borrow someone else's Internet connection for the purpose" there, but for Cliff's sake, she works for an ISP's helpdesk, it should be SOP to spell that out explicitly because most people are too computer-illiterate and blindered to think of it.  Especially back in the 56k days.

     



  • @dhromed said:

    — What his phone number?
    — Dunno. Give'm a call.


    Seriously, I once had a senior manager complain to me why I hadn't emailed everyone to tell them our email server was down... I have had a "Bang Head Here" sign next to my desk ever since.



  • @MeesterTurner said:

    Seriously, I once had a senior manager complain to me why I hadn't emailed everyone to tell them our email server was down... I have had a "Bang Head Here" sign next to my desk ever since.

    Yes, but that was a manager. I expect more from the helpdesk person mentioned earlier, they're usually smarter.

     



  • @Medezark said:

    So, wait, the bug report is basically -- If I turn off cell and wi-fi on my phone, it can no longer connect via cell or wi-fi?

    Solution: Have user pack up mobile device and ship it back to the vendor, as the user is too stupid to use a mobile device.

    No, the bug is that when a user receives a "no network connection" error, that error is not logged on the server.

    It's a perfectly valid bug. It's just a "can't fix".



  • @blakeyrat said:

    No, the bug is that when a user receives a "no network connection" error, that error is not logged on the server.

    It's a perfectly valid bug. It's just a "can't fix".

    Well, unless you log the error on the server once you [i]do[/i] have a connection again…


  • @Enterprise Architect said:

    @blakeyrat said:

    No, the bug is that when a user receives a "no network connection" error, that error is not logged on the server.

    It's a perfectly valid bug. It's just a "can't fix".

    Well, unless you log the error on the server once you do have a connection again…

    True, unless I misread it, the bug specifically states that the mobile device keeps a log of connection failures, something like Windows' Event Viewer. You could potentially grab it out of there and pass it on next time you get a connection.



  • @blakeyrat said:

    You could potentially grab it out of there and pass it on next time you get a connection.
    Hey that's an awesome idea! Let's fill our logs with loss of network errors.



    Seriously though, unless these devices are managed and supposed to never lose connectivity then this is pointless, and even then you should be pinging them constantly anyways.



  • @Lingerance said:

    @blakeyrat said:
    You could potentially grab it out of there and pass it on next time you get a connection.
    Hey that's an awesome idea! Let's fill our logs with loss of network errors.



    Seriously though, unless these devices are managed and supposed to never lose connectivity then this is pointless, and even then you should be pinging them constantly anyways.

    I'm not saying it's pointful. Or that it should be fixed, even if it was fixable. I'm just saying it's a valid bug. Not a WTF to see a valid bug in a bug database.



  •  I find this difficult to believe. Your QA team is honestly capable of this level of clarity in filing the defect report? A real QA defect report would be more along the lines of "[Product] has an error". And usually, [Product] would be different from the one that actually has a problem.



  • @blakeyrat said:

    I'm not saying it's pointful. Or that it should be fixed, even if it was fixable. I'm just saying it's a valid bug. Not a WTF to see a valid bug in a bug database.
    Fair enough.



  • @Lingerance said:

    @blakeyrat said:
    I'm not saying it's pointful. Or that it should be fixed, even if it was fixable. I'm just saying it's a valid bug. Not a WTF to see a valid bug in a bug database.
    Fair enough.
     

    I can even see some cases where this would be pointful (which I wanted to nominate as "most useful new word" for today but which already exists - I'm behind, as usual).

    "We have a perfect network, none of the phones reported downtime"."Well, I'm the customer, and I can never get a connection with your stupid network"

     



  • @cdosrun said:

     I find this difficult to believe. Your QA team is honestly capable of this level of clarity in filing the defect report? A real QA defect report would be more along the lines of "[Product] has an error". And usually, [Product] would be different from the one that actually has a problem.

    And wouldn't actually be one that you have anything to do with.



  • @cdosrun said:

     I find this difficult to believe. Your QA team is honestly capable of this level of clarity in filing the defect report? A real QA defect report would be more along the lines of "[Product] has an error". And usually, [Product] would be different from the one that actually has a problem.

    My QA department has difficulty applying thought to bug reports.  However, they have no problem applying rules.  For example, on one bug, they'll report a screenshot of an intermittent error condition that plainly shows the product is broken, but with no steps to reproduce the problem.  After a short talk, a QA person does a bit of scribbling on a pad and goes away.  Half an hour later another bug is filed, this time for a report.  The report formatting is incorrect, but all that I find in the bug report is a set of steps to reproduce (literally instructions on how to run the report).  I go back to talk to the individual and hear "but you said ...".


  • Now, if only they could combine rules…



  • @Wrongfellow said:

    @XIU said:

    They are actually complaining that they can't log a "no network error" to the online service.
     

     Yup. This came from the test department, not from a user. The tester just took the script literally and recorded the failure, which I suppose is understandable.

     

    All you can really hope is that the testers follow the script to the letter and if that means raising defects like this then so be it. 

    If there is a specific functional requirement for the app to log the "no network error" on the server then either the FR needs to be changed, the functionality added or the exception noted. 

    If there is no functional requirement for this behaviour then I don't believe there should be a specific test for it.  In this instance the defect could be closed as an issue with the test script.  The test script should be updated to change the expected result and the test re-run.

    Note - This presumes the existence of documented functional requirements.

     



  • @cdosrun said:

     I find this difficult to believe. Your QA team is honestly capable of this level of clarity in filing the defect report?

    For the most part this is a remarkably WTF-free company to work for.

    @RTapeLoadingError said:

    If there is no functional requirement for this behaviour then I don't believe there should be a specific test for it.  In this instance the defect could be closed as an issue with the test script.  The test script should be updated to change the expected result and the test re-run.

    Yes, that's what happened - the bug ended up in the hands of the guy who wrote the test script (who apologized for not paying enough attention while cut-and-pasting!)


  • 🚽 Regular

     These kinds of bug reports get me so frustrated because even if I physically go into the QA department and try to explain with magic markers and puppets why this bug is either impossible to solve or ridiculous they still don't get it. In some cases they'll simply refer to the requirements doc and say, "But it's here in the req doc so you have to honor it."

     This reminds me of an old WTF article where someone was asked to produce a survey and after he built it the client demanded to know what the results are before the survey is administered. No amount of explanation was satisfactory to the client and he lost the bacon.



  • @RHuckster said:

    These kinds of bug reports get me so frustrated because even if I physically go into the QA department and try to explain with magic markers and puppets why this bug is either impossible to solve or ridiculous they still don't get it.

    Why do they need to get it?

    A bug is a deficiency in the product. It doesn't imply "this has to be fixed" or even "it is possible to fix this." I could write a bug for my car that says, "car requires purchase of expensive gasoline to operate. Expected result: car operates infinitely without gasoline" and that's a *perfectly valid bug*. It just happens to be a "can't fix" bug.

    Instead of going and yelling at your QA department, just mark it as "can't fix" in the bug tracker and move on with your life.

    I get the sense nobody here has ever worked QA, or understands how QA is supposed to work.

    @RHuckster said:

    In some cases they'll simply refer to the requirements doc and say, "But it's here in the req doc so you have to honor it."

    If it's in the requirements, then why are you yelling at your testers? Yell at the idiot who wrote impossible requirements. Your testers are just doing their job, leave them alone.

    @RHuckster said:

     This reminds me of an old WTF article where someone was asked to produce a survey and after he built it the client demanded to know what the results are before the survey is administered. No amount of explanation was satisfactory to the client and he lost the bacon.

    He lost... the... bacon? I guess he should have padlocked his fridge.


  • 🚽 Regular

    @blakeyrat said:

    A bug is a deficiency in the product. It doesn't imply "this has to be fixed" or even "it is possible to fix this." I could write a bug for my car that says, "car requires purchase of expensive gasoline to operate. Expected result: car operates infinitely without gasoline" and that's a *perfectly valid bug*. It just happens to be a "can't fix" bug.
     

    First of all, usually a QA who files a bug report is expecting some sort of action besides marking it "Can't fix". In one office I used to work at, when I resolve it as "Can't Fix" I need to convince the QA of that fact, so yes, they do need to get it. I can't just mark a bug "Can't Fix" and move on. If I need to, I'll bring a project manager or someone else who has authority above QA to back me up. In the end, whether it's the QA manager, the project manager, or the client, there is SOMEONE who needs to get it, otherwise they'll simply reopen the bug and tell me to resolve it.

    Most office environments I've worked in are small and tight knit, without the red tape mumbo jumbo that larger operations have. Nevertheless, the QA I've dealt with in the past have low self-esteem and can't fathom the fact that any bug report they might provide is unfixable or "ridiculous" and if I simply mark my bug "Can't Fix" they'll simply walk into MY office and confront me about it. If I had it my way, I'd demand that they seek the project manager for these kinds of conflicts, but it didn't work out that way and I had to deal with them personally.

    That being said, I'm talking about a particular place I worked at a long time ago, and the employer I'm working for now has a much better organization set up so in the rare case someone makes a ridiculous bug report or requirement like, "User must be able to download video instantaneously while in deep space" it's resolved and filtered through management before it even gets to my desk.



  • @RHuckster said:

     This reminds me of an old WTF article where someone was asked to produce a survey and after he built it the client demanded to know what the results are before the survey is administered. No amount of explanation was satisfactory to the client and he lost the bacon.
    The WTF there was about a programmer failing to realise that clients commissioning surveys generally expect the answers to be as they implicitly request - but without being able to say so explicitly, for obvious reasons. Not quite the same thing here.



  • @blakeyrat said:

    A bug is a deficiency in the product. It doesn't imply "this has to be fixed" or even "it is possible to fix this." I could write a bug for my car that says, "car requires purchase of expensive gasoline to operate. Expected result: car operates infinitely without gasoline" and that's a perfectly valid bug. It just happens to be a "can't fix" bug.
    Not the same thing as in the OP. That your car requires gas to run is not a bug, but if it's supposed to report imminent depletion of critical resources - oil, brake pads, coolant, fuel, etc - then failure to report is a bug. In the OP, it was not a bug that the phone did not connect without a phone connection available, but it was a bug - possibly not an important one - that the connection failures were not being logged as specified, even though it is impossible for them to be logged to a web app on the fly.



  • @RHuckster said:

    This reminds me of an old WTF article where someone was asked to produce a survey and after he built it the client demanded to know what the results are before the survey is administered. No amount of explanation was satisfactory to the client and he lost the bacon.

     

    DAMMIT FRED!  I WAS SAVIN THAT BACON!!!



  • A bug is a deficiency in the product.

    No, a bug is a mismatch between reality and the spec. If the spec says "The car uses gasoline" then it is not a bug that the car needs gasoline.



  • @Wrongfellow said:

    @RTapeLoadingError said:

    If there is no functional requirement for this behaviour then I don't believe there should be a specific test for it.  In this instance the defect could be closed as an issue with the test script.  The test script should be updated to change the expected result and the test re-run.

    Yes, that's what happened - the bug ended up in the hands of the guy who wrote the test script (who apologized for not paying enough attention while cut-and-pasting!)

     

    Having written my share of test scripts I can believe this.



  • On a semi-related note, I keep on getting e-mails from Wells Fargo with the subject:

    Wells Fargo Alert: Unable to Deliver Email

    Oh really? Then how did I get this e-mail, if you can't e-mail me?

    (apparently they have the wrong e-mail address on record for me in an account that doesn't exist any more, I've called them about it before and their tech support people have never been able to resolve it)



  • @Tacroy said:

    On a semi-related note, I keep on getting e-mails from Wells Fargo with the subject:

    Wells Fargo Alert: Unable to Deliver Email

    Oh really? Then how did I get this e-mail, if you can't e-mail me?

    (apparently they have the wrong e-mail address on record for me in an account that doesn't exist any more, I've called them about it before and their tech support people have never been able to resolve it)

    Sounds like spam to me.  I've received several fake delivery failed spam messages.  They think you'll be curious and open it up.  Alternative explanation is that a bot on person A's computer sent spam to person B, but the spam bot software put your address as the sender.  Person B's account has been closed, so you got the bounce.


  • @Jaime said:

    @Tacroy said:

    On a semi-related note, I keep on getting e-mails from Wells Fargo with the subject:

    Wells Fargo Alert: Unable to Deliver Email

    Oh really? Then how did I get this e-mail, if you can't e-mail me?

    (apparently they have the wrong e-mail address on record for me in an account that doesn't exist any more, I've called them about it before and their tech support people have never been able to resolve it)

    Sounds like spam to me.  I've received several fake delivery failed spam messages.  They think you'll be curious and open it up.  Alternative explanation is that a bot on person A's computer sent spam to person B, but the spam bot software put your address as the sender.  Person B's account has been closed, so you got the bounce.

    Spam or phishing. Is there a link?


Log in to reply