6 ms·

This person is giving way too much credit to QA. At least in enterprise software, which I was working on for 20 years, QA were mostly useless. In SAAS, having d

This person is giving way too much credit to QA. At least in enterprise software, which I was working on for 20 years, QA were mostly useless. In SAAS, having developers own their entire code including unit tests all through to deployment in my experience has yielded the best code quality that I've seen. Also, I don't consider security to be QA, that is a specialty in my opinion, similar to the article. The normal development cycle in enterprise shrinkwrap software is that you would take a 12-18 month release cycle, and then plan out X features. QA would come back and say "We can only test 6 of those features", so the feature list gets cut. Then as you develop the features and finish them, you don't hear back from QA because their cycles are different from developers, except maybe a few weeks before the end of the release cycle, and then you get hit with a flurry of bugs, because that's when the QA is testing most of the code. Then more features get cut because of the high bug count, and then even more features get cut and you end up with 2 out of 10 features. This is how most development occurred all the way up until I left enterprise software about 10 years ago. The best way is to cut QA entirely out and kill it as a career path. Give developers the entire burden of coding and testing, including end-to-end. I personally dislike TDD and would never join a company that developed using TDD but that's just my opinion. Obviously a SAAS vs shinkwrapped software is different, but overall, the best code quality I've seen is at my latest company where the developers owned everything. The buck stopped with you, and it behooves you to write good quality unit tests and integration tests. Cutting out QA forces developers to own their code and doesn't have a wall where developers would code, write some small tests, and then throw it over to the QA and not look at their feature for weeks or months.

JohnBooty 6y ago
That sounds like a particularly toxic relationship with QA. I've had quite a few positions where QA was very helpful. In those cases, QA interfaced with users/customers and had a great level of knowledge of how people actually use the product, and often had a more holistic view of how the entire suite of features works together, compared to developers who had more specialized knowledge of various specific bits. Now, I would agree that ideally developers should get lots of hands-on experience with how customers actually use the software. And I would also agree that ideally developers should have a holistic view of the entire suite of software features, rather than being silo'd. I definitely aim for those things as much as possible, but it's not always practical. Both of the things I listed above add up to a fulltime job, or multiple fulltime jobs if the product is large enough. Usually engineers are in short supply and working mad hours already. I would also like to point out that QA engineers are really vital when it comes to developing games. I do not work in the game industry, but I have a friend who is a QA engineer lead. Games are complex realtime systems and it can take a LOT of work for those folks to find and come up with reproducible cases for bugs.
beatthatflight 6y ago
Wow. Having worked as a dev, and as a QA for 17 years, I've never experienced a relationship between dev and QA as you describe above. Current role is about shifting quality to the left, helping build in quality into the process, and being less a "tester at the end" to which you throw something over the wall (I've not had that in probably 14 years), and someone who helps Quality Assure/Assist. Have a look at the World Quality report this year. Spending on QA helps a lot in reducing bugs further down the line. There are always exceptions I guess, and looks like you were in that.

JohnBooty 6y ago

That sounds like a particularly toxic relationship with QA. I've had quite a few positions where QA was very helpful. In those cases, QA interfaced with users/customers and had a great level of knowledge of how people actually use the product, and often had a more holistic view of how the entire suite of features works together, compared to developers who had more specialized knowledge of various specific bits. Now, I would agree that ideally developers should get lots of hands-on experience with how customers actually use the software. And I would also agree that ideally developers should have a holistic view of the entire suite of software features, rather than being silo'd. I definitely aim for those things as much as possible, but it's not always practical. Both of the things I listed above add up to a fulltime job, or multiple fulltime jobs if the product is large enough. Usually engineers are in short supply and working mad hours already. I would also like to point out that QA engineers are really vital when it comes to developing games. I do not work in the game industry, but I have a friend who is a QA engineer lead. Games are complex realtime systems and it can take a LOT of work for those folks to find and come up with reproducible cases for bugs.

beatthatflight 6y ago

Wow. Having worked as a dev, and as a QA for 17 years, I've never experienced a relationship between dev and QA as you describe above. Current role is about shifting quality to the left, helping build in quality into the process, and being less a "tester at the end" to which you throw something over the wall (I've not had that in probably 14 years), and someone who helps Quality Assure/Assist. Have a look at the World Quality report this year. Spending on QA helps a lot in reducing bugs further down the line. There are always exceptions I guess, and looks like you were in that.