131–140 of 193 posts
It is important for code to be looked at and tested with a fresh perspective
and that's what a separate QA team aids in
Many years ago I asked a developer which was a bigger deal: - Having an outage - Missing a deadline They answered: "oh having an outage is WAY worse". I then asked: "if that's the case, why do you push so hard to hit your deadlines with code you know and I both know is probably not ready?" They didn't really answer at the time but it eventually dawned on me what's happening: - odds of being yelled at if you miss a de…
But that's just bad management. It's most of the time better to drop/delay some features, than compromising stability. If the manager doesn't get that, he/she is the problem. And not the software developer.
I'm sure you can make analogies. If you get a new kitchen installed, you expect it to be done properly, if it's finished within the day or so they quoted for you but the doors fall off, you won't be happy. You never SPECIFIED that the doors should be firmly attached - you assume they will be, because you trust in the competency of the people installing it.
Why can’t the QA people just live on the dev team? Why do they need to be siloed away or not exist? I had this in my past job. Have 1 QA per two developers, the QA sits with those two developers, and you are constantly telling them when a build is done and on staging. They write tests, do some manual checks, and then tell you how it is going relatively immediately. They also handle the problem of reproducing bugs and…
Asking developers to own QA is broken because developers are naturally biased towards the happy path. If you want to build a bar, you need someone to order -1 beers[1]. Handing off QA to an external team is broken because those people don't have the necessary experience with the product, nor can they quickly and easily engage with development to get to the heart of a problem (and a fix.) Having QA rely exclusively on…
Wherever I worked so far as a software developer we had the QA department very close. In the same room or next door. They were there from the beginning until the end, tested our software continuously. If we developed something, that was hard for them to test or to understand, they gave us a hard time. So we tried to make software testable. Do meaningful logging. Make things repeatable. Develop tools to export state/p…
Asking developers to own QA is broken because developers are naturally biased towards the happy path. If you want to build a bar, you need someone to order -1 beers[1]. Handing off QA to an external team is broken because those people don't have the necessary experience with the product, nor can they quickly and easily engage with development to get to the heart of a problem (and a fix.) Having QA rely exclusively on…
[author here] You are absolutely right: the optimal setup is a cross-functional team of domain experts collaborating on solving the customer's problem. The article is meant to point out that siloing QA to either just dev or just QA is an anti-pattern that is unstable and will not work, long term, without significant pain. I think the challenge is that, while we agree on the optimal setup, it's almost never done like…
The main challenge with software is the possibility of unexpected regression in areas that are non-obvious when implementing a given feature. One of the more scalable ways of catching these regressions is via some sort of automated testing. I think that a QA support team can provide the tools and support that allow for teams to easily add end to end testing, which is vitally important when build large distributed software.
If the QA team is responsible for testing every feature from many teams there is definite risk of bus factor and finger pointing.
In the super ideal world the testing is specified via something like Cucumber and the orginal author could be the product owner with feedback from the engineer as he works to that specification. But I have never seen this though have heard it can happen, rarely.
They eventually moved an application engineer from pre-sales into the team and it made a huge difference in triaging this stuff, because many 'bugs' that came in were things like "my model isn't converging" and the answer was 75% of the time things like "you need to refine your mesh further", whereas previously it got shunted onto the dev team.
Earlier quoted context omitted.
I've also arrived at this approach and don't think it's that uncommon - IMO the article is presenting a false dichotomy. There are still gotchas to look out for in the team-embedded QA approach. In typical team sizes, you often end up with only one QA per team - you need to make sure they have cover (everyone needs a break), and they need support in their discipline (do something to share QA knowledge across teams).
QA also works best for features that the user can meaningfully interact with. The more esoteric, interconnected, or complex the failure is, the more it gets muddled with other reports and weird conditions (it breaks on 3pm when the moon is in equinox and I have my mouse pointed north). That’s an over exaggeration but the sentiment is accurate. QA will frequently lack a deeper understanding of how the software works a…
it's not.
OpenOffice won't print on Tuesdays https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
etc
I know they have to sell their no-code product which is not targeted at the QA teams but this is too much...
Asking developers to own QA is broken because developers are naturally biased towards the happy path. If you want to build a bar, you need someone to order -1 beers[1]. Handing off QA to an external team is broken because those people don't have the necessary experience with the product, nor can they quickly and easily engage with development to get to the heart of a problem (and a fix.) Having QA rely exclusively on…