I support the idea of cross-functional teams. However, I don't agree that one never needs to hand off a given piece of work for it to be thoroughly tested. That really depends on the nature of the software. For cases like financial software, medical software, military software, I believe it can make sense to test that software in a way that the developer alone cannot, even if the developer has worked with QA and Acceptance to carefully produce something they have confidence in.
Assuming the quality of software handed over is high, much of this additional testing work may end up not revealing any new problems, but there are cases where that extra due diligence is required. Another example is when software has to be supported in a lot of different environments such as different browsers, different operating systems, different hardware.
Web Engineer. Working mostly with PHP, Symfony and Golang.
Entusiast about Engineering Best Practices, Continuous Delivery and DevOps.
Sports and FC Porto fan!
I am not saying that there shouldn't be a QA phase, after the development is complete. Of course it should. But I think having QA embedded in the development team makes the process and communication much easier.
I just dont like terms like "hands off" because sometimes it could be interpreted as "my work is done. its not my responsibility now" and the burden is put entirely on QA. I have experienced that and worse with a dedicated QA team, shared across development teams.
Of course, it depends a lot of the context of the organization. As you said Financial Software or Medical Software might require a special attention.
Still in 90% of cases, I would say a cross functional team is a way to go.
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.
I support the idea of cross-functional teams. However, I don't agree that one never needs to hand off a given piece of work for it to be thoroughly tested. That really depends on the nature of the software. For cases like financial software, medical software, military software, I believe it can make sense to test that software in a way that the developer alone cannot, even if the developer has worked with QA and Acceptance to carefully produce something they have confidence in.
Assuming the quality of software handed over is high, much of this additional testing work may end up not revealing any new problems, but there are cases where that extra due diligence is required. Another example is when software has to be supported in a lot of different environments such as different browsers, different operating systems, different hardware.
I am not saying that there shouldn't be a QA phase, after the development is complete. Of course it should. But I think having QA embedded in the development team makes the process and communication much easier.
I just dont like terms like "hands off" because sometimes it could be interpreted as "my work is done. its not my responsibility now" and the burden is put entirely on QA. I have experienced that and worse with a dedicated QA team, shared across development teams.
Of course, it depends a lot of the context of the organization. As you said Financial Software or Medical Software might require a special attention.
Still in 90% of cases, I would say a cross functional team is a way to go.