• boog (unregistered)

    Alex really owes us after yesterday.

    (repost to get to top of page 2).

  • (cs) in reply to BrainiacV
    BrainiacV:
    I chose the account of a particularly big ticket offender and chose to pay off $25,000 of a $30,000 outstanding invoice. I used my personal credit card and in the comment field wrote "TEST TEST TEST do NOT process! TEST TEST TEST' Everything seemed to work well until I got a call from my credit card company saying I was WELL over my limit, immediately followed by a call from my companies Accounts Receivable, saying my card was denied. Mind, our web apps were not tied directly into the accounting database, someone had to print out the entries, walk them to another terminal and re-enter them.
    I hope their termination letter read, "FIRED FIRED FIRED you're an idiot! FIRED FIRED FIRED FIRED" (extra FIRED added to fix bug).
  • (cs) in reply to Your Name
    Your Name:
    BrainiacV:
    I had written a credit card accepting web application for unpaid bills for my former employer. Everything worked in Test, on the big day that it was moved to production, I tested it again. I chose the account of a particularly big ticket offender and chose to pay off $25,000 of a $30,000 outstanding invoice. I used my personal credit card and in the comment field wrote "TEST TEST TEST do NOT process! TEST TEST TEST' Everything seemed to work well until I got a call from my credit card company saying I was WELL over my limit, immediately followed by a call from my companies Accounts Receivable, saying my card was denied. Mind, our web apps were not tied directly into the accounting database, someone had to print out the entries, walk them to another terminal and re-enter them.

    Why the hell would you type your own (or any valid) credit card number into a test order? You must be one of those idiots that emails your password to people right after they specifically say "we wont ask for account details."

    Maybe because that would only test whether their connection to the CC processor was working? The order wouldn't be completed.

  • (cs) in reply to Anonymoose
    Anonymoose:
    Of course you don't make up a credit card number. In fact, having a validation for CC numbers is required in case someone enters a typo on their CC number. The proper way to test credit card-handling systems is to use credit card test numbers.
    That would make more sense. There are test SSNs and names for pulling credit reports too. They use the modified names of cartoon characters and such.
  • Anmol Sharma (unregistered) in reply to port22

    Well it was showing two results as the the testers would do the testing for single search in downtimes and marketing department would think that the actual transactions are being made and so they made the book popular and published another updated version which actually resulted in two results being fetched up..!

  • Geoff (unregistered) in reply to Steve The Cynic

    Thank You! Never put test data into your production database unless its going to get backed out ASAP. The entire reason you are using a database in the first place and not just scribbling into some txt file, is to have integrity. Part of integrity is not having bogus records in the data.

    I once worked on a data warehouse project for a certain retailer. I spent a day trying to figure out why some numbers would not come out right. The reason one someone had put a product 'Bird Bath Brush' into the active inventory data that they did not actually sell. Apparently this was widely know in the transaction processing group but they neglected to tell us about it. Why they named it something that seemed real I don't know, you'd think they could have at least named it 'XX DELETE ME XX' or something but its still a dumb idea.

  • (cs) in reply to boog
    boog:
    Alex really owes us after yesterday.

    (repost to get to top of page 2).

    Owes you for what? What have you done for him? Have you prepaid for something you haven't recieved?

  • BentFranklin (unregistered)

    Pretty funny, especially since I had a pdf of Who's Got the Monkey on my desktop for years. Everyone should read it.

  • Bridget (unregistered) in reply to Your Name
    Your Name:
    Why the hell would you type your own (or any valid) credit card number into a test order? You must be one of those idiots that emails your password to people right after they specifically say "we wont ask for account details."

    When we found that our test environment had accidentally pointed towards the production credit card service for a couple hours, we had the devs asking a very similar question - who the hell would use their own credit card in our test system, anyway? My response was "your boss does." There were a lot of phone calls to make sure nothing was entered during those few hours we were pointing at production.

  • jdw (unregistered) in reply to operagost

    So don't pay $25,000. Pay one cent. Unless you're specifically testing large amounts of money for some reason...?

  • AGray (unregistered) in reply to Anketam

    TRWTF is that these test cases were being executed on production. If you add garbage data to a production environment, it will mess with real processes.

    In this case, the hapless victims were Harvard's marketing.

    Lesson: don't test on production, keep your testing safely hidden away!

  • (cs)

    When testing our purchasing system, I used to order gold bricks (big ones). Too bad that never made it to production.

  • Peter (unregistered)

    I know folks are saying to use test credit card numbers, but we had one situation where the code handling (trapping) test credit cards was buggy, so I used some (spent) rebate credit cards. Charge won't go through, but if you've got one path that supposedly inserts the test credit card number in debug mode (and it doesn't do that all the time), well, that way my bank account doesn't get hosed.

    In the above case, we had some code on the desktop application that ran a LUN check and would't pass known test credit cards to the server, and a server app that was supposed to insert test credit card numbers when in dev/debug mode and pass those to the actual server that ran the credit cards. It was a mess.

  • Dave (unregistered) in reply to Ben Jammin
    Ben Jammin:
    BrainiacV:
    ... Mind, our web apps were not tied directly into the accounting database, someone had to print out the entries, walk them to another terminal and re-enter them.

    I believe this may be against PCI Compliance.

    I believe this may be because of PCI Compliance.

  • Ken B. (unregistered) in reply to Jack
    Jack:
    Steve The Cynic:
    Anketam:
    But it is not your BuildMaster's monkey though. Anyways classic wtf not for technical reasons but for marketing, but then again marketing is so full of things to make fun of, it is almost not fun.
    No, the WTF is very much technical. They were polluting the production database with the side effects of //testing//. *And* they were creating an interesting situation: loads and loads of orders that were fulfulled, but no physical product shipped...
    I reserve judgement on whether this sort of testing should ever occur in production. But in any case, I agree that it's not the marketing department's WTF. How can they be expected to know they're supposed to ignore certain orders unless they are told? For that matter, I doubt they are directly querying the database themselves to generate the reports they use. Certainly the test entries could have been filtered out for them.
    Why were the test orders fulfilled (or left in the system as "not fulfilled"), rather than canceled by the back-end people?

    Any why didn't the marketing department try to contact "Mr. Test Test" to get a good quote to put on the cover of the second edition? After all, he's the one who bought virtually every one of those "best seller" copies.

  • Ken B. (unregistered) in reply to Jack
    Jack:
    Your Name:
    BrainiacV:
    I had written a credit card accepting web application for unpaid bills for my former employer. ... Mind, our web apps were not tied directly into the accounting database, someone had to print out the entries, walk them to another terminal and re-enter them.
    Why the hell would you type your own (or any valid) credit card number into a test order? You must be one of those idiots that emails your password to people right after they specifically say "we wont ask for account details."
    I assume it had to be valid, because he was trying to test the functionality to validate the number.

    ...but I still don't see why he had to use his OWN.

    Given that the system couldn't "validate" it in the sense of "is this a real credit card number of a real account for a real person whom we can really charge" (that was done by the person who had to walk it over to the other terminal and re-enter the data), there is no reason to have used his own real number. There are test numbers that are "valid" in the sense that they will pass any preliminary tests (like the check-digit) that can be done prior to submitting the charge. For example, "4111111111111111" for Visa, or "5555555555554444" for MasterCard.

  • (cs)

    I'd be willing to bet the revised edition would never have been published without the fake sales.

  • Axel (unregistered)

    As of end-of-year 2017, the top Google hit for "Who's Got the Monkey? best seller" is a 1999 Harvard Business Review article calling it "one of the top two downloaded articles in HBR history." I wonder what the other one was, and how its author feels about sharing the spotlight with monkey boy.

Leave a comment on “Classic WTF: I've Got The Monkey Now”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article