I am attempting to set up a better build notification/information process in my company.
What are some of the basics that are imperetive, yet realistic, to have for a good process?
so far i got:
When there is an update for each platform/application, developer will send the following information..
1.What changes where made for each platform/ product (new functionality, change in existing functionality, enhancements)
2.What bugs were fixed(bug numbers)
3.What parts of the product did the fix potentially effect.
Am i forgeting anything else?
#3 could be wider: what are upgrade path/instructions complications? Backward compatibility: with previous build and any older (compared with previous build)?
Also notification should include identification and location of new build as well as note about smoke/sanity tests of the build.
?:the art of a constructive conflict perceived as a destructive diagnose.
We also have Development include a suggested test methodology for individual updates and fixes. Not that we aren't able to figure it out ourselves, it's a holdover from days gone by and does give us a different viewpoint for approaching testing. We also have a hand-off memo for initialing that new build was received, and also passed acceptance testing by the testing group.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~