• Lightor@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    3 days ago

    I’m setting a new low sure, and you’re moving the goal posts. What “well” means is incredibly subjective.

    You worked in QA, cool, and I’ve manage the entire R&D org of a nation wide company, including all of QA.

    Your saying that since companies don’t invest in it enough it doesn’t matter at all? Why do they even invest at all then, if it truly doesn’t matter.

    Yes a QA can test old features and keep up with new ones. WTF, have you never heard of a regression test suite? And you worked in QA? ok. Maybe acknowledging AQA is an entire field might solve that already solved problem.

    You did a whole lot of complaining and non relevant stories but never answered any questions I’ve been asking you across multiple comments…

    • Modern_medicine_isnt@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      2 days ago

      What goal post have I moved. My initial comment could have said work well for the user. But the second sentence implied that pretty clearly. And I am still saying it now. And great for you. You probably drank the kool-aid to get that position, so you feel the need to claim carry water for the illusion that upper management always try to project. I mean, you might be the exception, and truely believe in the things you say. Maybe you even work for one of the rare companies where it is true. But the vast majority of people working in the field that I have talked to have said that just isn’t how it is most places. Many said it used to be, when their company was small… but that it changed.

      And yes I wrote regression tests. And I worked hard to maintain them while writing tests on features. But with a 5 to 1 ratio of devs to QA, it wasn’t possible to not cut corners. A year after I changed jobs I found out they had lowered the bar for releasing to 55% passing of the regression tests. I never had the tools to make them able to resist change as they had no one owning the automation tools. The next guy just didn’t care as much. The job I moved to was qa automation so the qa’s were my customers. I did my best there to give them automation that would reduce maintenance costs. But we weren’t allowed to buy anything, we had to write it all. And back then open-source wasn’t what it is today. So the story was the same, cut corners on testing. And of course the age old quote… “why is QA slowing down our release process”. Not why are the devs writing poor code. The devs weren’t bad either, but they were pressed to get features out fast.

      As for why do they invest in it at all. Optics is a big part of it. But also to help maintain that low bar you spoke of. The moment industry trends started touting the Swiss army knife developer who could do it all including testing, they dropped qa teams like a bad habit. Presentations were given on how too much testing was bad, and less tests were better… that pendulum swings back and forth every decade or so. Because quality drops below the low bar, and the same exec who got a promotion for getting rid of the qa team at his last job 7 years ago, gets accolades for bringing it back in his new job.