51–60 of 84 posts
Are you a SaaS practicing continuous delivery? Can customers report bugs rapidly? Can you fix them rapidly? If you can reduce the turn around time of fixing a bug to less than 1 hour, you can use your customers to QA.
If so, you should not have a QA department. They only slow things down.
Of course, this depends on the type of business you are in.
We don't have a QA team; we have an internal team that uses our product to do their work. It's part QA, part product development, part marketing; they help us prioritize feature work, they write blog posts about the cool stuff they can do with our product, and when bugs surface, they find them, because it's all part of their workflow. This doesn't work for all companies; if you're building a system for children to le…
Devs can add automation tests to a suite just fine. What you lose when you lose dedicated QA is: who improves the automation suite? Who checks out new testing tools and POCs them? Who reads QA blogs and goes to QA conferences and generally considers it their profession to find ways to test more effectively?
This is my take as well. I've worked with various types of QA teams over the years (all in SaaS). Based on my experience, from MOST effective to LEAST effective: 1. QA team works on test harnesses, automation, and works alongside developers to improve how we do testing. This was by far the most effective. 2. No QA team. Developers own every aspect of quality. This worked, but was not as effective as #1. 3. All releas…
This seems to be a pretty common setup. I’ve heard opinions on both sides about whether it is a good idea. One of the biggest challenges with it for me is that a dev who is a dev is a very different personality who a dev who manages the entire SDLC. The former placed in the latter environment is going to be lost and annoyed at all the moving parts. They signed up to write code and to trust that the process would deli…
The most irritating aspect I notice is the tendency for having to do the same project multiple times because requirements, and user/devteam communication isn't what it should be.
QA's increasingly are facing an uphill battle against information overload, that management and typical textbook PM processes are very ill-equipped to detect; there's also the fact that your "contract" QA departmemt, does not have incentive alignment. The most horrible devs can be endured by a QA group that cycles out QA's on a 2-3 month basis. The in-house QA group that logs in to the same steaming pile of low-quality crap will soon either find themselves motivated to trim waste or otherwise increase the efficiency and processes where they are.
I can only ever get FTE QA's to even deeply learn the business... I can't do that generally with contractors. So if places are doing away with QA... I wouldn't be surprised. And I don't think the upswing in software origin'd suffering from my perspective is just a coincidence either.
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…
Automated tests (at least when it comes to web) are unlikely to catch graphical and UX issues in my experience, even when you're doing screenshot comparisions--things get missed. I've also had manual QA discover unrelated UX bugs too.
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…
The problem with this is that a person who makes a mistake when doing something is much more likely than someone else to make a mistake when evaluating that same piece of work.