71–80 of 84 posts
The QA team brings something significant that developers (myself) will never have: their machines closely represent the customers machines. They use a well-polished methodology to push the models we ship to their limits and provide relatively detailed information about how to reproduce failures. I can't count the number of times I've tested something 5 times, convinced myself that the code handled tons of error cases…
It is a lot of work to maintain all of the tests that we have. However, we have an incredibly good track record of releasing on time and critical bugs are rarely introduced.
QA teams primary benefit shouldn't be running automated tests that the developers could do. It should be to do exploratory testing and trying to break things. There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released. If there's only developers who test their own code then they're not incentivize…
Then fire all your QA people, because they just keep getting in the way, and the developers can do all of their own QA anyway.
Then don't be surprised when they fire all the developers because they've got this new "no code" thing. But then who is left to implement the "no code"?
QA teams primary benefit shouldn't be running automated tests that the developers could do. It should be to do exploratory testing and trying to break things. There should be a adversarial, yet respectful, relationship between dev and QA where dev tries to get their software released and QA is finding reasons why it shouldn't be released. If there's only developers who test their own code then they're not incentivize…
Beautifully articulated. This is exactly what’s going on. Incentives are simply misaligned with expectations. In all likelihood, the market doesn’t reward quality software as much as it rewards robust feature sets.
It is easy to see the increased traction due to building new features. It is difficult to understand the slow, grinding attrition that happens due to bad quality.
Having been through the decision process in the past for whether to go when centralized QA, dedicated QA on teams, or automated testing as an engineering responsibility, I came away with the personal opinion that the quality of automated test frameworks has improved so drastically in the past five years or so that we really are in a different place than we were when concept of dedicated QA teams was invented long ago…
In an ideal world, devs would always have the time to test their own code. The unit and integration bits aren't the pain point, but once you reach the API or UI, people's knowledge varies widely. That's where a good QE org, either embedded or a mix of centralized and embedded, can be very helpful. In my past companies we've pushed to be champions or domain experts in test automation who's main purpose is to make test…
>In this case, I wouldn't say you absolutely need a full quality team, but having some folks whose primary focus is testing and test automation to help skill up your dev teams sounds reasonable.
This is what we have at our current team, as I have described in a comment above, and it has worked very well for us.
The QA team brings something significant that developers (myself) will never have: their machines closely represent the customers machines. They use a well-polished methodology to push the models we ship to their limits and provide relatively detailed information about how to reproduce failures. I can't count the number of times I've tested something 5 times, convinced myself that the code handled tons of error cases…