I could not agree with you more! There is a place for business experts and engineers to perform unit testing of components, but that should not be the extent of testing. A well-trained, knowledgeable software testing staff is absolutely critical.
When I manage a development project, I establish an initial team consisting of members from management, development, QA, Support, Documentation, Training, and Production Operations (Data Center) who see the project through from beginning to end. They attend all development meetings, discussions, code reviews, etc. Likewise they attend meetings specific to the other areas of the development lifecycle such as all phases of testing and documentation.
It is imperative, IMHO, that people outside the development team understand the process that takes place to develop a particular software project. They are therefore able to explain to others in their respective departments why we made one decision over another, which business requirements were included or dropped and why, which features are critical or optional. It provides the documentaton staff with key insight into the project, which I find allows them to document particular components or aspects of the project as we are in development to prevent a mad rush at the end of the cycle. And to your point of not compressing the software testing phases, having QA involved in the project meetings allows us to begin testing earlier in the lifecycle and often times to test some components while others are still being developed, which is beneficial because defects found early in development can be prevented in other components still being developed.
As a side note on software testing, I require systems-level testers (e.g. white-box testing) on my teams in addition to application-level testers (e.g. black-box testers.) And like you, I think automated tools have a specific purpose, but they are not the only solution and are not a good fit in some areas of testing. That’s not to say I’m not a proponent of automation because I absolutely am.
Including a representative from key areas of the development lifecycle is critical to meeting hard timelines and provides a better informed team all the way around. Sometimes the discussion is over a few of their heads or seemingly irrelevant to their job function, but I have never encountered a team, once the software is released and in production, who did not think being included from beginning to end was beneficial. I’ve had data center operators come back months later to tell me that the knowledge they gained in the project meetings helped them understand and meet customer requirements more effectively.
Ping. Forgot to copy you on my response at #101.
If I could add to what BuckeyeTexan said: that sets up the possibility of much more effective and efficient processes. I used to feel sorry for Q&A people sometimes - when they’d get thrown a large complex system all and once and were told to start testing. HEY! You’re holding up delivery! It was the same attitude that the engineers had faced, but much later in the process when managers had already spent a lot of money and were already under pressure from customers to deliver.
Like BuckeyeTexan said, the agile approach gets everyone involved from the start, in their respective roles and allows taking it a bit at a time. While doing that, you don’t need to rely entirely on generalists who feel uncomfortable about taking on certain tasks - especially under pressure to complete them. You can have various specialists forming a nice balanced production line of sorts. And the best thing about it - it goes on and on. I don’t mean that it delays project indefinitely. I mean that people can get expert in their specialty work, get in tune to working with everyone else in their group - and even continue the same way on more than one project - acting more as a continuous production entity than an ad hoc group with too few resources and time.