Quote:
Originally Posted by grial
I agree. That's what it should be, but in my experience it's not. I mean, there is no control but when something fails.
Some of the scripts we've implemented so far are used to transfer the main data output of our system to another company, to say how they are important. They deal with high volumes of financial information, we even get penalties if we get delayed during the transfer or if something wrong happens.
Now we can't release one of these scripts in production without a bit of testing, however these procedures are really up to the developer, there is absolutely no generic process in place, nor review. We're not that far from a file version control regulated by the emacs' ~ save file... But the scripts themselves are kept easy to read and commented. If I had put some qa-scripts in place, they would have gone through them without any problems I believe.
The problem could be that the developer is the QA analyst at the same time, but I think QA should be defined at a team level to really work. Just the fact somebody else looks at your script brings forth other points of view and good critics.
Back to the little story, it has already occured several times that the other company we transfer our files to changed their server configuration (password, dirs) without having warned us. I don't remember of any specific checking procedures having taken place when amending the scripts in question as they got released in production without any CM work around.
This could look scary if you don't explain it's shell scripting in there. But just because it's shell, some concepts of CM and QA cannot really apply. The fact it is very hard to find anything told about it on the web tends to show people haven't really put themselves into such CM process analysis.
10-20-2006
