On Thursday, 31 October 2013 at 20:32:49 UTC, Marco Leise wrote:
Am Thu, 31 Oct 2013 17:00:59 +0100 schrieb "eles" <e...@eles.com>: I would discriminate between change requests and bug reports. You should be responsible for any bugs and fix them, but changes resulting from unclear specifications are entirely different. I wouldn't do any more real work on the project than is written down in the contract. (Meaning: Be prepared for the changes you allowed for, not random feature requests.)
Yeah, maybe is a corporation culture to avoid the term "bug", but we always use the term "change request". Maybe it has a better image :)
Normally, it is assumed that passing the tests proves that specifications are accomplished, so the software is perfect.
This, of course, if the tests themselves would be correct 100% and *really* extensive.
Or, some things like race conditions and other heisenbugs occur only rarely. So, you still need to conceptualize and so on.
In practice, is not really different to fix a bug or to make an evolution of the code, except that for the former the urgency is greater. Anyway, in the end, it is the guy with the budget that decides.
It is an iterative process, however: you start with some ideas, you implement some code, you go back to the architecture description and change it a bit, in the meantime you receive a request to add some new specification or functionality so back to square one and so on.
But this is development. What really ensures the quality is that, at the end, before shipping, all the steps are once again checked, this time in the normal, forward mode: requirements, architecture, code review, tests. *Only then* it is compiled and finally passed to... well, not to the production, but to the dedicated Validation team.
