QA



  • Conversation with QA five minutes ago:

    QA: Why didn't message x get sent from app y to app z?
    ME: Because the user of app z didn't purchase the functionality to get this message
    QA: But we want to send it
    ME: So set that user up with the functionality so the filter won't trigger
    QA: But we're not supposed to change the data
    ME: Perhaps you should choose data that meets the requirements of the functionality
    before trying to test it
    QA: We should be able to test using any data we want
    ME: Yes, but you won't always get the desired results: that's WHY there's filtering!
    QA: Can we bypass the filter?
    ME: No; the whole point of the filter is to limit messages to sensible situations
    QA: Can we bypass it just for testing?
    ME: Then you're not testing what will be deployed; what's the point?
    QA: We don't understand all this filtering? Why is it there?
    ME: Per BA requirements, to limit network traffic and eliminate nonsense messages to
    reduce thrashing on messages that cannot possibly be of use to anyone. Don't you
    have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do
    ME: How do you know what to expect if you don't know how it's supposed to work?
    QA: We don't need to know what the BA's think; it needs to pass OUR tests!

    I sent a transcript of that up and down the chain, far and wide. It created quite the sh*t storm.



  •  qaaaaaaaaa is like a sound that you should make at them, trying to communicate.



  • Oh lord, looks like my company:)

     QA: THIS IS WRRROONG!

     Me: What? Spec says it is this way.

    QA: No! This is wrong. Spec is wrong. System architects are wrong.



  • @edgsousa said:

    Oh lord, looks like my company:)

     QA: THIS IS WRRROONG!

     Me: What? Spec says it is this way.

    QA: No! This is wrong. Spec is wrong. System architects are wrong.



    Same here. I just wish we could get them to screw up and put it in writing that they don't read the requirements... of course, considering how things have been handled in the past, nothing would come of it.


  • Trolleybus Mechanic

     @snoofle said:

    QA: Yes, but we don't want to read them. The code should do what we expect it to do

    Snoofle: You should do what I expect you to do. Your mouth says no, but your other holes say yes.

    #PurpleDildo



  • I know what "QA" is, but what does "BA" mean?


  • ♿ (Parody)

    @Medinoc said:

    I know what "QA" is, but what does "BA" mean?

    It's Mr T's greatest role.



  • @Medinoc said:

    I know what "QA" is, but what does "BA" mean?

    EDIT: DAMN YOU BOOMZILLA! DAMN YOU ALL TO HELL!!!!!!


  • Discourse touched me in a no-no place

    @Medinoc said:

    I know what "QA" is, but what does "BA" mean?

    Business analyst. Their output typically (directly or indirectly) produces the programmer's input (i.e. the specs. Or they should.) Their output should also go to QA so they can (independantly) design the tests required against what the programmers produce.



  • @Medinoc said:

    I know what "QA" is, but what does "BA" mean?

     

    Business Analyst. A genuinely useful and valuable job, if it's done by a competent person that has an actual interest in understanding the problems a piece of software is supposed to solve and the needs of the customers who will be using said software.

     



  •  @lscharen said:

    A genuinely useful and valuable job, if it's done by a competent person that has an actual interest in understanding the problems a piece of software is supposed to solve and the needs of the customers who will be using said software.

    But when it's not the B stands for "Big" and the A is uncomplementary bit of anatomical synechdoche.

     

     

     



  • @snoofle said:

    ME: ... Don't you have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do

    Blakey is one of your QA people?



  • @snoofle said:

    QA: Can we bypass it just for testing?

    QA: Yes, but we don't want to read them. The code should do what we expect it to do

    QA: We don't need to know what the BA's think; it needs to pass OUR tests!

    I'm not feeling the assurance of their quality.

    Snoofs... what happens if it passes their tests and fails in production? Do they get a kicking for having poor quality tests?

    @Lorne Kates said:

    Snoofle: You should do what I expect you to do. Your mouth says no, but your other holes say yes.

    #PurpleDildo

     

    Apparently he didn't QA the colour...

     



  • @edgsousa said:

    QA: No! This is wrong. Spec is wrong. System architects are wrong.

    @CodeNinja said:

    Same here. I just wish we could get them to screw up and put it in writing that they don't read the requirements...
     

    Don't the specs get Quality Assured (and preferably signed off) before design and implementation?

     



  • @PJH said:

    Business analyst. Their output typically (directly or indirectly) produces the programmer's input (i.e. the specs. Or they should.) Their output should also go to QA so they can (independantly) design the tests required against what the programmers produce.
     

    That.

    @lscharen said:

    Business Analyst. A genuinely useful and valuable job, if it's done by a competent person that has an actual interest in understanding the problems a piece of software is supposed to solve and the needs of the customers who will be using said software.

    That too.

    Stupidly many organisations leapfrog this stage - or they have a sales droid who leaps into this position, is poorly-trained, doesn't ask the right questions and overcommits the organisation into deliverables that cost far more to produce and reduce the profitibility of the entire process. Or the task is shouldered off to a "Senior Programmer" or "Development Team Lead" that may have years of coding experience but knows fuckall about requirements gathering and value proposition.

    Scrimp on this role, and you're into the realms of "how can you produce a solution if you don't understand the problem?". You'll design what you think is needed, and someone will build what they think is wanted... and as each stage progresses, you drift further away from what is actually being paid for and needed.

     



  • @Cassidy said:

    @edgsousa said:

    QA: No! This is wrong. Spec is wrong. System architects are wrong.

    @CodeNinja said:

    Same here. I just wish we could get them to screw up and put it in writing that they don't read the requirements...
     

    Don't the specs get Quality Assured (and preferably signed off) before design and implementation?

     


    Yes, but by Product Managers and the Customer, not QA.


  • Discourse touched me in a no-no place

    @flabdablet said:

    @snoofle said:
    ME: ... Don't you have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do

    Blakey is one of your QA people?

    How I chuckled.....



  • @PJH said:

    @Medinoc said:

    I know what "QA" is, but what does "BA" mean?

    Business analyst. Their output typically (directly or indirectly) produces the programmer's input

    Ah, the famous "Human Centipede" model of software development!




  • Me: Don't the specs get Quality Assured (and preferably signed off) before design and implementation?

    CodeNinja: Yes, but by Product Managers and the Customer, not QA.

    So they have been QA'd to some degree, just not by the QA dept (the customer has provided assurances that it's what they want). And they still claim the specs are wrong? Or are you stating that they don't read the specs and hence their tests are crap?

     

     


  • Discourse touched me in a no-no place

    @Cassidy said:

    Don't the specs get Quality Assured (and preferably signed off) before design and implementation?
    Not usually. QA are Quality Assuring the software after it's written, not the specs before it's written. There may be a department to sanity check the specifications before they hit the software department, but they won't be the people testing the software that comes out as a result of them.



  • @PJH said:

    There may be a department to sanity check the specifications before they hit the software department, but they won't be the people testing the software that comes out as a result of them.
     

    Yeah, perhaps I should have said "tested" or "checked". Now I'm got ISTQB to my name, I see all testing activities as being QA (a process), rather than QA being a specific department.



  • @snoofle said:

    Conversation with QA

    Here, they sometimes go like this:

    • QA opens a bug.
    • Dev checks that what was reported actually happens (usually takes 20-30 minutes).
    • Dev then checks the spec and sees that it's supposed to happen.
    • Dev resolves bug "As Designed".
    • QA checks that what was reported actually happens.
    • QA then checks the spec and sees that it's not supposed to happen.
    • QA reopens the bug.
    • Dev sees bug again; goes to talk to the QA. Turns out both have different versions of the spec.
    • Both go to see the BA; apparently, both the dev and QA are wrong and it should be done a third, completely unrelated, way.

    Today I overheard the BA and QA try to come up with a way to test that a quite-complicated calculation is done correctly, but neither of them new how the calculation is done so couldn't recreate it. In the end, as far as I know, they decided the program is the only authoritative data, so is tautologically proven to be correct.



  • @configurator said:

    Both go to see the BA; apparently, both the dev and QA are wrong and it should be done a third, completely unrelated, way
     

    All 3 attack the PM with the Spiky Cluebat of Stakeholder Analysis and the Sandpaper Dildo of Improved Change Communication.



  • @Cassidy said:

    Me: Don't the specs get Quality Assured (and preferably signed off) before design and implementation?

    CodeNinja: Yes, but by Product Managers and the Customer, not QA.

    So they have been QA'd to some degree, just not by the QA dept (the customer has provided assurances that it's what they want). And they still claim the specs are wrong? Or are you stating that they don't read the specs and hence their tests are crap?

     

     


    Something like that. Our QA team likes to just, out of the blue, decide that the design documents are wrong and write up bugs on it. One of the things we had to simulate was a 'Jake Brake'. Basically, an engine brake specific to large diesel engines. This does not work the same way as engine braking in your car. However, our head QA guy was insistent we had it wrong even though it fit the requirements to the letter, which he also determined were wrong. How did he determine this? The engine braking on his Dodge Ram didn't work that way, so it obviously didn't work that way in a large armored semi-truck like vehicle with a completely different engine setup and a special engine mode just for this.

    I assume other companies have similar QA teams.



  • @CodeNinja said:

    Our QA team likes to just, out of the blue, decide that the design documents are wrong and write up bugs on it.
     

    That's not tooooo bad. If QA (or some testing team) realised there was a fault in the spec then I'd expect them to highlight it earlier rather than later. But the decision about it being "wrong" should rest with the customer/client - it's up to them to flag it as a potential issue, sure...but usually they don't get to decide. Their role is in establishing just how close to specs everyone else is at each progression stage.

    @CodeNinja said:

    However, our head QA guy was insistent we had it wrong even though it fit the requirements to the letter, which he also determined were wrong.

    Cue to get QA to raise a ticket and kick it back to the BA/PM with a note of "$QA has identified an issue; development shall pause and I shall resume playing Q3TA until I receive notification that the specs are correct and I am designing/building the right system"



  • @CodeNinja said:

    Something like that. Our QA team likes to just, out of the blue, decide that the design documents are wrong and write up bugs on it. One of the things we had to simulate was a 'Jake Brake'. Basically, an engine brake specific to large diesel engines. This does not work the same way as engine braking in your car. However, our head QA guy was insistent we had it wrong even though it fit the requirements to the letter, which he also determined were wrong. How did he determine this? The engine braking on his Dodge Ram didn't work that way, so it obviously didn't work that way in a large armored semi-truck like vehicle with a completely different engine setup and a special engine mode just for this.

    I assume other companies have similar QA teams.

    Do you not have a mechanical engineer on staff to tell him he's an idiot?



  • @Cassidy said:

    Cue to get QA to raise a ticket and kick it back to the BA/PM with a note of "$QA has identified an issue; development shall pause and I shall resume playing Q3TA until I receive notification that the specs are correct and I am designing/building the right system"


    Pretty much what happened. The issue bounced back and forth for a long time, since the PM we had at the time wasn't one to ever make a decision about anything. Our project lead just kicked it into the, "Meets requirements, so it's closed" folder, QA would open it back up... wash, rinse, repeat. We worked on other stuff until someone in the management chain got pissed and the issue suddenly died. We still hear grumbling from the QA lead about it, but he won't write it up anymore.



  • @Cassidy said:

    ...Q3TA...

    My Junior year of High School called and was like "Wow, people really still play this 12 years later?"



  • @configurator said:

    In the end, as far as I know, they decided the program is the only authoritative data, so is tautologically proven to be correct.

    So your QA guy just resigned on the spot?



  • @CodeNinja said:

    since the PM we had at the time wasn't one to ever make a decision about anything.

    How the fuck did anything get done?

    Oh.

    It didn't.

    Are your PMs held accountable for project failure? Or are they weasels that manage to point elsewhere with such a large finger that management concentrate upon the problem and not upon who was mandated to ensure it got fixed?



  • @morbiuswilters said:

    @Cassidy said:
    ...Q3TA...

    My Junior year of High School called and was like "Wow, people really still play this 12 years later?"

    You're barely 30? Yeesh, that explains a lot.



  • @Zylon said:

    You're barely 30? Yeesh, that explains a lot.

    1. Yes. We've had this discussion a million times before.

    2. Did the nurses forget to add a few shots of bourbon to your dialysis mix again? You always get so cranky when your kidneys are failing and you're still cogent enough to use the Internet..



  • @morbiuswilters said:

    Filed under: Actually‚ I'm not "barely 30"‚ I'm not even 29 yet.

    Actually, I'm not "barely 20", I'm not even 19 yet.



  • @snoofle said:

    Conversation with QA five minutes ago:

    Absolutely mind boggling.

    I've done some QA and if I submitted my test specs for review and could not show that all documented functional and business requirements were being tested I'd expect to be in trouble. Testing against the requirements isn't some sort of arcane knowledge - it's what QA is.



  • @Ben L. said:

    @morbiuswilters said:
    Filed under: Actually‚ I'm not "barely 30"‚ I'm not even 29 yet.

    Actually, I'm not "barely 20", I'm not even 19 yet.

    So you created a TDWTF account when you were 17? Wow, what's it like knowing you will die a virgin? In some ways, I guess it's pretty liberating--you've been freed from the outmoded shackles of procreation to pursue a life of pure intellect..

    Oh, but wait, you're spending your time here, so I guess it's not one of those transcendence things, after all. Sorry for the false alarm, carry on.



  • @boomzilla said:

    @Medinoc said:
    I know what "QA" is, but what does "BA" mean?

    It's Mr T's greatest role.

    I pity the fool who doesn't pass my QA testing!

     



  • @morbiuswilters said:

    In some ways, I guess it's pretty liberating--you've been freed from the outmoded shackles of procreation to pursue a life of pure intellect..
     

    That's my excuse.

     

    We technically don't have a BA (which we call "[technical] consultant"). We had a few good ones, the kind that knows tech and that a good feature must serve the client's goals, but they saw greener grass and flew off. :'(


  • Discourse touched me in a no-no place

    @snoofle said:

    ME: [...] Don't you have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do
    Look! QA thinks they're the customer!



  •  @PJH said:

    Business analyst. Their output typically (directly or indirectly) produces the programmer's input (i.e. the specs. Or they should.) Their output should also go to QA so they can (independantly) design the tests required against what the programmers produce.
     

    @lscharen said:
    Business Analyst. A genuinely useful and valuable job, if it's done by a competent person that has an actual interest in understanding the problems a piece of software is supposed to solve and the needs of the customers who will be using said software.

    Thank you both.



  • @CodeNinja said:

    The engine braking on his Dodge Ram [b]large armored semi-truck like vehicle[/b] didn't work that way, so it obviously didn't work that way in a large armored semi-truck like vehicle [b]Dodge Ram[/b] with a completely different engine setup and a special engine mode just for this.



  • @morbiuswilters said:

    Do you not have a mechanical engineer on staff to tell him he's an idiot?

    Well... here's the thing. I work at a company that does a lot of work for the government, in specific, the military. So we have a lot of ex-military folks around. Most of them are awesome, lots of character, great work ethic... this guy is ex-military as well who, in my opinion, gives his branch a bad name. But he's good buddies with the QA manager, who no one screws with, so he's basically untouchable. Everyone just pretty much shrugs and says, "Eh, he's a dick, he's always like that" and ignores him. Sadly, since Software directly deals with QA (the hardware team has their own QA group), we don't have that luxury.



  • @PJH said:

    @flabdablet said:
    @snoofle said:
    ME: ... Don't you have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do

    Blakey is one of your QA people?

    How I chuckled.....

    If I recall correctly, he did QA for a while and really enjoyed it but left because there was no career building path, which is a shame because good QA people are hard to come by.



  • @serguey123 said:

    left because there was no career building path, which is a shame because good QA people are hard to come by.

    Protip for people running software companies: there's a causal relationship somewhere in that sentence. Can you find it?

    But yeah. Exactly right. Even worse, the few companies that do believe there should be a career path in QA usually make it something stupid, like QA -> automated QA -> database developer or some other nonsense. The hype over unit testing has done so much damage to the software development industry.



  • @dkf said:

    @snoofle said:

    ME: [...] Don't you have the requirements?
    QA: Yes, but we don't want to read them. The code should do what we expect it to do
    Look! QA thinks they're the customer!
    Bravo. Made me spew oatmeal out my nose.

     



  • Is it pronounced qué?



  • @blakeyrat said:

    Even worse, the few companies that do believe there should be a career path in QA usually make it something stupid, like QA -> automated QA -> database developer or some other nonsense.

    That doesn't sound right at all. What would you want a career path to be?



  • @configurator said:

    @blakeyrat said:
    Even worse, the few companies that do believe there should be a career path in QA usually make it something stupid, like QA -> automated QA -> database developer or some other nonsense.

    That doesn't sound right at all. What would you want a career path to be?

    QA -> higher paid and more senior QA -> higher paid and more senior QA -> higher paid and more senior QA -> QA management (optional)

    Read about the Peter Principle. Just take that into account and I'm good.



  • @configurator said:

    What would you want a career path to be?
     

    You promote to Team QAptain, obviously.



  • @blakeyrat said:

    higher paid and more senior

    Oh, I thought you had some role (other than "more QA") in mind.



  • Where I work, we build what we think they want then the QA team tests the requirements into the software.

    They call it "test driven software development".

     

     


Log in to reply