There is a great deal of benefit to using automated tests, they will help insure that positive flows through the code's logic work, and that common error handing routines are sufficient. I have over a decade of OO automated tool experience so I am not panning well constructed automation, but I guarantee you I can break any code tested only in this manner.
In my humble opinion, the path to achieving what you have outlined is:
- Components need to be simplified, documented, thoroughly tested, and rock solid.
- Developers need to be penalized for reinventing the wheel, unless it is truly a better wheel, and then the old wheel should be thrown out.
- QA needs to be brought into the process at inception, not after development has already started.
- QA cycles should not be compressed in order to make up for development overruns (yes I know that I'm dreaming here).
- Project management needs to play a much more active role in projects while they are in flight and learn to close them out when complete to the original scope.
- All major development methodologies are valid and sound if the rules are followed, however most of the time the rules are bent or broken.
Yes, I agree with much of what you say. I don’t see why that would be a problem with the suggestions I’ve made. In fact, I’ve pointed to the fact that keeping up with modern technology, modern project process has become more agile. This means that project participants should be involved in the flow of work - must less like the olden days when project emphasis would shift from one group to another in large phases.
The one thing about your comments that leaves me a little cold, is the way you want QA people to monopolize testing. If engineers do no testing, then they’ll end up shipping a lot of stuff that doesn’t work to QA. No point in that. And software systems need to end up doing what they’re intended to do - and for many best efforts that involves experts and specialists in the application area (and often end use customers).
Each has a particular role within the quality assurance process.
I want a gold star for this comment: Quality is everyone’s concern!
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.