If development adds a patch or two, is that good for a build? Shouldn't a whole new build be done andnot just patched? Our development team is adding three patches so we can release on time. I don't agree and would rather have more time to test a full build. Any ideas? Thanks.
It doesn't sound like the issue is patch-versus-full build, but rather the amount of time you are given to conduct testing.
I assume getting a patch is the equivalent of "you don't need to test too much" in your shop?
- Joe (firstname.lastname@example.org)
No, we do need to test. We make a WEb Application and a new version is supposed to go up tonight. My problem is that we have had inadequate time to test this build fully, and to save time, Development is adding patches rather than full builds. I just don't like it. By rushing we will miss some things, it is a given. Also, I hear patches are not good b/c they can affect other areas of the product... True?
(By the way I changed my username, This is still "Taz")
Perhaps I wasn't clear.
You said "Our development team is adding three patches so we can release on time".
So presumably, in your shop, the development group believes it will take less time to test the system with these three patches, than it would take to test the system with a new build?
Clearly, you aren't convinced.
Of course a patch can cause undesirable side-effects!
There's no way to tell how bad the side effects will be without knowing the details of the patches. In my (web) environment, changing (patching) one Include file could change (and potentially break) everything!
So the only way to analyze the situation is to dig in, understand exactly what is getting patched, and give your assessment as to the real testing required to reduce the risk of problems sufficiently. Only then, will you be able to give your assessment of the risk of moving the code to production tonight.
- Joe (email@example.com)
[This message has been edited by jstrazzere (edited 02-26-2002).]
Patches can affect other aspects of the system, which means you need to test those aspects in terms of the integration of the patches. As Joe said, it does boil down to time to testing on the one hand because whether this was a full build or just the inclusion of patches, you still should do a regression test cycle and, for that, you need time.
In general, however, patching is a bad way to do things because it does introduce elements of risk that some testing will not necessarily catch, particularly under a time crunch, but this could be the case even if there is testing time. It depends on the nature of the patch. For example, perhaps you do a full regression test and the functionality works fine but in terms of performance, there is now a slight degradation that was not present before and that is cumulative.
In general, there should be a change control process in place of some sort that allows you to assess the impact of these patches based on the nature of the patch itself. (A corrected spelling is a lot different than a new algorithm, for example.) If you have a new build going up tonight and patches still coming in, I would not sign off on the build. They can release it and they probably will but I would make sure that it is known that QA does not sign-off on the build so that if problems do develop, you have recourse to your objection. Again, this depends on the nature of the patching and what is going on but that is my two cents on this issue.
In general, patching suggests problems in the process to begin with and, as such, that process (of patching builds) should be mitigated as much as possible by looking at why this patching has had to occur. Full builds are always better because that can catch errors right at the outset that the developers can deal with before it gets handed off to testing and then has to get handed back to the developers.