In Accelerate, Forsgren and co. found that having a QA department who is responsible for the automated testing of releases does not lead to improved IT performance. The logic being that if development is not made responsible for automated test coverage, the applications they create will too often be untestable for a QA department. Forsgren and co. come to the conclusion that the role of the QA team should be a mixture of 1) consulting with the development team on how to create their tests and 2) exploratory testing the applications (presumably looking for unanticipated use cases that weren't covered by the spec). Do you have any thoughts on this theory based on your experience?
This sounds reasonable to me. I think that expectations on QA and the traditional approach to QA record keeping make it hard to find that talent and cultivate it.
One other add I provide the team is organize what changes take place for a release.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In Accelerate, Forsgren and co. found that having a QA department who is responsible for the automated testing of releases does not lead to improved IT performance. The logic being that if development is not made responsible for automated test coverage, the applications they create will too often be untestable for a QA department. Forsgren and co. come to the conclusion that the role of the QA team should be a mixture of 1) consulting with the development team on how to create their tests and 2) exploratory testing the applications (presumably looking for unanticipated use cases that weren't covered by the spec). Do you have any thoughts on this theory based on your experience?
This sounds reasonable to me. I think that expectations on QA and the traditional approach to QA record keeping make it hard to find that talent and cultivate it.
One other add I provide the team is organize what changes take place for a release.