• LCrawford (unregistered)

    They forgot: if (pageFrom != fristHomePage) m_backStack.Push(pageFrom);

  • Anon (unregistered)

    The global WTF: customers being pissed of by the program doesn't following exactly the specification... which was ambiguous.

  • Prime Mover (unregistered)

    Heh. That reminds me ...

    I was on a project once which had been an analysis paralysis mode for an age. I was brought on board, new to the consulting firm, to replace another engineer who had been moved into a different team. My responsibility was to maintain the design spec. To start with. That was a clusterfornication to start with, but never mind, we'll gloss over that, and also gloss over my attempt to clarify what we were supposed to be doing by drawing a great big flow diagram on an A1 pad on an easel, which attracted the attention of everyone walking past and hence inspired much-needed dialog ...

    ... and move onto a later stage of the process, when I had been moved out of the team and then moved back in. I cast an eye over the specification. It detailed some user journeys which had some fairly complicated logic. Then I saw the code which had been generated as a result f those user journeys. I could see for a start that it would not work, because there were paths through that code which were not covered, and would cause definitely incorrect behaviour. So I raised this with the team leader and the project manager, and was immediately slapped down with: 1. It implements the logic as detailed by the user journeys, and 2. the programmers who put this together are deeply offended by my implication that they have not done a good job.

    Hence I got a reputation as a pedantic little nit-picker whose next career move would be to move into the test team to take over the utter shambles that was the automatic test suite for our flagship product, where I was happy as a clam until our little company was bought by a multinational conglomerate and the test department offshored.

  • Ruts (unregistered)

    Like the bit about A1 pad on an easel - have done much the same myself, or a whiteboard when I had one by my desk. This can really help with 'serendipitous discovery' with the random inputs it can elicit.

    Now with so much working from home means that one more communications channel or information radiator that no longer works :(

  • Brian (unregistered)

    As I move along in my software-development career, I'm increasingly convinced that a good QA person is a treasure to be hoarded. So many QA folks I've encountered are bottom-of-the-barrel types who only do exactly what they're told, which is the kind of thinking that contributed to today's story. But someone who thinks beyond the requirements and creatively pokes the system as a user might, will uncover all kinds of crazy edge cases that the devs may not have considered (or simply not cared about, as this case may be).

    So to all the QA folks who have been a pain in my rear, thanks for doing your job.

  • (nodebb)

    Requirements Engineer/Manager here: The spec was written wrong, too. All requirements need to be written in terms of "at least" or "no more than," rather than, as in this case, "exactly". Also, use "shall,' not "will". So,

    12.2.23.a.2 The app SHALL remember AT LEAST the last 5 screens the user has visited

    Not that this excuses the failure to define what a "screen" is, or the complete cock-up of the implemented code.
    Or I suppose they could have written "shall remember NO MORE THAN" , which is not only abusive , but passes test if zero screens are remembered.

  • Anon (unregistered)

    I once meet a QA that found a lot of errors... All of them useless because were triggered by actions users wouldn't never do and were only considered bugs because the company owner dictated "no generic error messages" and that QA missed all errors... That a plausible use of the system would trigger.

    So after an exhaustive period of writing error messages that no user would ever read we had a stressful launch week with users reporting tons of errors and the owner inquiring us of what we were doing during the bug fixing period...

  • Prime Mover (unregistered) in reply to Anon

    "actions users wouldn't never do" ... Oh sweet summer chile ...

  • 🤷 (unregistered) in reply to Anon

    triggered by actions users wouldn't never do

    You are right. Actions users would not never do. Meaning, they would always do it.

    Double negative aside, you must be one of thouse "fresh out of college" guys. Don't worry, we've all been in your shoes, thinking "oh come one, no user will ever be THAT stupid". But let me tell you: Yes, users really are THAT stupid and will use any given product in ways you wouldn't imagine in your wildest dreams.

  • Steve (unregistered) in reply to cellocgw

    [All requirements need to be written in terms of "at least" or "no more than," rather than, as in this case, "exactly".]

    12.2.23.a.2 The app SHALL remember NO MORE THAN the last 5 screens and AT LEAST the last 5 screens the user has visited

    There. Fixed. No more "exactly"...

  • Sole Purpose Of Visit (unregistered) in reply to 🤷

    Excellent idea for a one-line, very strict, Requirements Spec, though:

    1. The System shall make the correct state transition for all plausible actions that a user shall take.

    There, that should about cover everybody's ass. I'll get me MISRA Compliance Hat and leave.

  • (nodebb) in reply to 🤷
    You are right. Actions users would not never do. Meaning, they would always do it.

    Double negative aside, you must be one of thouse "fresh out of college" guys. Don't worry, we've all been in your shoes, thinking "oh come one, no user will ever be THAT stupid". But let me tell you: Yes, users really are THAT stupid and will use any given product in ways you wouldn't imagine in your wildest dreams.

    Yep, been there done that.

    I still remember my surprise when we deployed my first reservation system where I (in a bit of misplaced humour) had added a few 'Cant happen' error messages (fortunately none of them abusive).

    I had included a test for a reservation only being possible in the future (and the GUI would only allow user to attempt to reserve in the future) and the error was: 'Spacetime Discontinuity error: You can not reserve in the past'.

    Imagine my surprise when that error started showing up once in a while in the error log of the application......

    Somehow users till managed to trigger it even though it should not have been possible.

  • T. E. (unregistered) in reply to 🤷

    "oh come one, no user will ever be THAT stupid"

    Working at a software supplier, I once crashed one of our programs by paging down several time (500 or 5000 times, I forget which) in succession. The programmer responsible gave me the response that (unregistered) suggested.

    Just a few days later, a customer reported the same crash. They did this completely on their own, without any hint from me. (My colleagues didn't believe me, either.)

  • WTFGuy (unregistered) in reply to Anon

    @Anon ref:

    The global WTF: customers being pissed of by the program doesn't following exactly the specification... which was ambiguous.

    You have obviously failed to notice the crucial difference between "customer", ie. the functionary who signed off on the requirements doc, and "users", the people who actually, you know, use the program.

    Two very different groups with often very different expectations.

  • Anon (unregistered) in reply to 🤷

    You are right, users by-passing javascript formating and validation and complaining about generic "invalid request" errors happen are the most reported bugs, it is totally logical to allocate developers time to write detailed error messages for each of those cases.

  • Kleyguerth (github) in reply to Anon

    Sometimes all it takes is an outdated browser, a timezone difference or even a locale difference to get into those "can't happen" situations. Not every user running into invalid request are bypassing javascript on purpose.

  • Naomi (unregistered)

    RE: Anon: Generally, I think it's best to assume someone has at least a little understanding of their own story, at least until it's been shown otherwise.

    Setting your own email address to a blank string could be called "something a user would never do". Setting your own email address to a 4294967297-character long string could also be called "something a user would never do". The difference is that one can plausibly happen because a user messes up a copy-paste, or gets curious, or is annoyed about boilerplate emails, while the latter is something that truly can't happen under anything approximating likely circumstances other than a user intentionally trying to overflow a buffer or something. (I'm sure at least some of you are reflexively thinking of things to shout about how wrong I am, but shut up and think for a moment.) And that's not even getting into what the app might actually be doing, and whether something in the actual problem domain is merely silly (and should be accounted for) or truly implausible (in which case, shut up and think about whether it really needs to be).

    The fundamental problem is that exactly one person here knows which it is, and that's @Anon. None of us were there! We're all going to hear different things when they say "something a user would never do". Recognize that! You could - if you're willing to, gasp, talk to someone instead of immediately jumping to telling them why they're wrong and bad and should feel bad - ask what the situations in question were. @Anon - the person actually there - seems to think they're actually implausible, or at least close enough that spending development resources on them was misguided. Or did you conveniently gloss over the part where they said there were serious bugs revealed after the project went live? Ah, I see you reaching for that keyboard to tell me why I'm wrong! Shut up. You're pretentious and don't know half as much as you believe. Get over yourselff.

    @Anon, what kind of circumstances were these?

  • (nodebb)

    "your own email address to a 4294967297-character long string", of course that is implausible, it is a 4294967296 character text document that was in the past buffer....

  • Rhialto (unregistered)

    Sometimes your clipboard doesn't contain what you think it contains - even if you just "right clicked" and selected "copy" (I frequently copy from a Remote Session [a Windows Server] and paste into a screen on my PC. And more often that you would think; "RDP Clipboard Monitor" isn't). But surly you would notice that it was wrong? Well maybe. Perhaps only the first few characters are visible; that the Form submits "onchange" or, more likely for me, the time between pasting, and submitting can be incredibly short but not as short as the time it takes to think "Oh %&*$! What have I just done?"

  • Rhialto (unregistered)

    @TheCPUWizard Dammit! :)

  • Harris Mirza (unregistered) in reply to Naomi

    A 4294967297 character long email address is invalid according to RFC 3696 and so any comprehensive email validation should catch this.

    Emails can have 64 characters in the 'local' part before the @, and 255 characters in the 'domain' part.

  • Prime Mover (unregistered) in reply to Naomi

    There is another fundamental point being missed here.

    When a programmer is writing a routine, he (or she) "knows" that when this routine is called, the parameters adhere to a certain set of specifications, because he (or she) is also writing the routine which calls this one. Hence no need to test its inputs, because he (or she) knows they're correct because he (or she) knows they are correct in the routine calling it (because he (or she) has made sure in the calling routine).

    Such an assumption is dangerous for obvious reasons.

  • Naomi (unregistered)

    No. That is not the "fundamental point being missed". The "fundamental point" has nothing to do with technology and everything to do with attitude.

    Too many people in this industry have this puerile fascination with telling other people why they're wrong. And they (you) will do so even if it means jumping to unjustified conclusions or outright ignoring things that don't fit their (your) narrative. You did it to Anon and now you're doing it to me, because you've gotten it into your head that talking down to people makes you look smart.

    It doesn't.

    You chose to ignore the part of Anon's story where they're talking about "generic error messages". Not missing functionality. Not security issues - the fact that there were error messages indicates that input was being validated correctly. Not actual bugs - per Anon, these error messages were triggered by user error. You've also chosen to ignore the part of Anon's story where serious issues did exist and were ignored in favor of adding more specific error messages.

    You're making an obvious bad-faith argument because you think bullying someone over a perceived inconsistency in a forum post makes you look smart, and I have no patience whatsoever for either it or you.

    Grow up.

  • Naomi (unregistered)

    Oh, and by the way, some quick research suggests there are somewhere between 1,500 and 4,000 characters per printed page. My printed omnibus of The Chronicles of Amber has slightly more than 2,000 pages. Taking the extreme upper bound, we end up with an estimate of 8,000,000 characters for the entire series. Let's round that up to 10,000,000 to be safe. I could have that entire document in my paste buffer four hundred and twenty-nine times and still not hit 2^32 characters.

    Now, even I don't think any of Anon's "actions the user would never do" were quite that blatant. But the thing is, I didn't need to do any of that analysis. Anyone who isn't blatantly, unashamedly arguing in bad faith would recognize that "the user overflowed a 2^32 character buffer by accident" - again, the "defect" Anon was talking about concerned error messages, not security - isn't plausible. So, by asserting that it is? All you've accomplished is re-establishing yourself as the Internet version of a schoolyard bully.

    So, well done, I guess.

  • Lets Get Yelled At (unregistered)

    Do what you want, and write down: PER ECN 12.2.23.a.1

    Then when they open ECN 12.2.23.a.1 they read: FROM RFC 12.2.23.a.1

    Then when they open RFC 12.2.23.a.1 they read: REF SPEC 12.2.23.a.1

    SPEC 12.2.23.a.1 is the power point presentation, v0.0.2. v0.0.2 is a power point annotation that has been sent to a distribution list of you, your lackey, and every other like minded delinquent. The comment references the project where you did what you wanted to do anyways, so any auditor is on an endless loop. Reference that one project, and chain the references.

    Only reason for specs? Boss wants a cash register, not some day dreaming bum, so eventually he can get rid of you.

  • Jarvis Family (google)

    "Somehow users till managed to trigger it even though it should not have been possible." - one classic method of doing this is: application gets time from clock on their workstation, submits request to server, clock on server is a few seconds ahead of workstation clock, and...MAYDAY! MAYDAY! COUNTDOWN TO SPACETIME DISCONTINUITY IN -3 SECONDS! -4 SECONDS!! -5 SECONDS!!! ...

  • Prime Mover (unregistered) in reply to Naomi

    I am so glad I don't have to work with you.

  • Prime Mover (unregistered) in reply to Naomi

    Oh, and by the way, I suggest you explore the concept of malicious attacks on your application by enemy agents. A lot of what QA does is to throw stuff at the application that a proper user would never do, but which a hacker and/or saboteur may well do. One of those things is to fill the entry fields with huge quantities of data, perhaps automatically generated, in order to see exactly what you need to do to break it.

    When I was in the business of designing public-facing applications for use on the web, one of the first things we did was to establish exactly the maximum number of characters that you could enter into any given field. Any more than that would either be ignored or cause the app to shut you out, depending on the sensitivity of the application we were designing. And if there were any other limitations on the data that the field was allowed to hold, that again would be rigorously enforced at the input.

    This does not preclude the programmer from defensively programming every routine written. You never know when someone is going to write some new code which invokes your routine from somewhere else where the parameters are not as well protected. Code may still go wrong, but at least the stuff you are responsible for is not what causes the sky to fall.

    And if my intolerance of halfwits and slackers who can'tbe bothered to sanity-check their inputs is considered "bullying", then take that (SLAP).

  • Anon (unregistered) in reply to Naomi

    You got it Naomi, there were no security issues, a mal-formed request would trigger a generic "invalid request" error message, it is sad to see that people like Primer Mover didn't read the part of "generic error messages".

    By coincidence one of the "bugs" was that when the name field were filled with a very big input the system would return an "invalid request" instead of "name field too long".

Leave a comment on “Going Backwards”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article