• (nodebb)

    The response to the ticket is obvious: "It isn't returning data because you are asking it to return no data. Working as intended. Closed. Not A Bug."

  • Low Quality Assurance (unregistered)

    TRWTF here is allowing QA to write the automated tests. QA is where people who don't like writing code go. Automated tests, or at least this kind of back-room utility to be used in e.g. a JBehave test, should be written by engineering.

  • SG (unregistered)

    The real WTF is someone actually using the Java Calendar API. Most people quickly figured out that this was one of those rare cases where writing your own framework was a better idea than using the native one...

  • MiserableOldGit (unregistered)

    Looking at those if statements, seems the date range should be "from" this many "days" before today.

    I know it's scruffy code, but hasn't she just forgotten to deduct days from start and then raised a ticket rather than done a sanity check?

    Oh, and talking of sanity checks, I was trying to work out what those Assert checks were doing, other than checking reality wasn't out of whack, and discovered Remy's reality may will be wobbling a bit ... https://thedailywtf.com/articles/the-same-date

  • tbo (unregistered) in reply to MiserableOldGit

    Heh. Well, unless the same person at that company submitted the same piece of code twice, I'm left to believe that two different people submitted the same piece of code two years apart.

    I'm not sure which is worse.

  • Mark (unregistered)

    I'm pleased that the comments to the daily WTF are moderated. I'm more pleased that the previous comment was allowed through.

  • Moss (unregistered)

    QA is where people who don't like writing code go.

    I would have to agree.

    Do developers never write WTF code? Of course they do. We wouldn't have this website otherwise. Hopefully though, you'll have at least a few members in the team who are smart and know what they're doing, and if you work with them, or even at least end up reading their code, you learn from them. Never the case with automation testers.

    Not once have I seen automation test code that made me go, "hmm, I like what they've done here", be it good code organisation, encapsulating external library code to make its usage easier*, decent naming, elegant use of language features, etc. Automation testers seem to just chuck some code at the problem, and if it works, that's good enough. Don't bother refactoring, don't bother making things easier to comprehend, don't bother improving performance. Just keep churning out test code.

    • Sometimes you really need this with testing libraries. And while I've seen attempts, the results were only marginally easier to use then the library itself.
  • MiserableOldGit (unregistered) in reply to tbo

    Well, the fact that in one answer it was supposedly QA picking up on shoddy coding from Prod (which implies the company has JUnit in its Prod code), and this time round it's Prod getting to sneer at QA.

    I went googling because I did wonder if it was some example code on some awful coding forum somewhere ... I still think it might be.

  • gone ratting (unregistered)

    One thing I started doing was test for composition:

    API request is the flow of input to format to request

    Format returns valid dates Request responds

  • gone ratting (unregistered)

    One thing I started doing was test for composition:

    API request is the flow of input to format to request

    Format returns valid dates Request responds

  • Ex of a different Nanette (unregistered)

    My first technical job was writing test code and building test fixtures for circuit boards. Those boards went into computers which were again tested. Those computers went into memory-test systems which tested memory chips on the production line. Some of those chips went into the boards that I helped test.

  • sizer99 (google) in reply to Moss

    It's rare, but there are some QA guys who can write damn good code - and the reason for that is they're real engineers doing real interesting engineering work to QA a specific type of product.

    For instance, if you've got a human only multiplayer game you probably still want bots for testing, and writing those bots is some of the most fun in the world (IMO). From simple bots that just fan out across the terrain and look for places they get stuck or fall through to really meaty machine learning bots looking for exploits. So some place like Psyonix (Rocket League) may (koff) have real engineers in QA writing these bots.

    I totally get that most QA doing scripting are just doing it as a hobby or tool so never developed any discipline (and should probably not be writing the API tests), but in some places QA transcends the hamster wheel.

  • SyntaxError (unregistered) in reply to MiserableOldGit

    Haha good find... maybe the COVID-19 stay at home order is getting to Remy.

  • MiserableOldGit (unregistered) in reply to sizer99

    Good read, and well said.

    It's a crying shame QA/Testing/BA are used as dumping grounds for failed devs, and a travesty Project Management is used as a promotion out of harms way.

    I won't deny some of the people whom I know who have shifted roles have proved to be great, but there's still something fundamentally dysfunctional. I do wonder how the ones who actually take those roles seriously feel about what seems to be SNAFU. I have worked with people in those professions who are truly great, but (sadly) they're the exception.

    Fun, fun, fun.

  • Erica (unregistered)

    I am having to write a drag and drop tool for QA to write tests with, which is on that level 2 of Code That Doesn't Do Any Real Work. Anyway apparently there's a legendary test file that runs hundreds of pages. Why is our counting unit pages and not lines? Well, because until this tool is developed QA have been writing tests in Microsoft Word.

  • Some Ed (unregistered) in reply to Low Quality Assurance

    I've known a couple of programmers who went to QA because they were interested in writing automated tests for their code and they were told they couldn't because it was QA's job to test things. Thus, logically, the place for them to have the kind of job they wanted was QA.

    I'd guess the only reason why there aren't droves of people busting out laughing from my post already, despite the fact that I haven't posted it quite yet, is because I'm coming to this party really late.

    Yeah, it was more or less like you'd expect. They went from not being allowed to write automated tests to not being allowed to write any code, because they were supposed to be busy testing things. Never mind the fact that they managed to test more things and find more bugs their first week on the job than the senior QA people were finding in a month... collectively... by writing scripts to do their testing for them.

    I think it was somebody noticed that this one person had the ability to eventually code all of the rest of the department out of a job.

    They were not, unfortunately, at the same company, so not able to work together on this stuff. One of them at least managed to keep writing his automated tests, he just disguised this effort by taking longer to report the failed quality checks. "Sorry it took a week to get to these problems, we're just really backed up here." lol.

Leave a comment on “Dating Automation”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article