Hi all
Does the notion of QA make sense when talking about shell script development?
I would like to put in place such a QA procedure to ensure the code we provide is full compliant with certain norms we think are right. I just thought it would be a good idea to ask the community about the following things:
Are there any QA tools for shell scripts on the market?
If you think an internal QA procedure implementation is more adapted, which criterions would you suggest to base the checks on?
Doesn't seem this thread has got so much success so far... so let's boost it a little bit.
I had a look on the net to check for QA tools and I can tell my search wasn't that successful. I simply wonder if QA even exists for shell programming, but could it be also that QA only makes sense when internally defined as well as maintained, which would explain why there is so poor reference about it on the web?
Or, could it be that shell script pays the price to only be seen as a "support" programming language at a OS level to applications coded in more evaluated languages (where you really find QA procedures).
Hi Indalecio.
First of all, I'm not an expert in QA as long as developing is not related to my actual job. Now, back to answering your question about QA in shell scripts, I haven't heard about it before, at least in shell script terms, of course. I' more close to:
Though, I'd say that shell scripts are meant to help sysadmins to automate their tasks, not to make "real & complex" apps. This, in my modest opinion, could be the reason why there's nothing related to QA in this field.
I think you're pointing to something right: it has definitely something to do with the way people use shell scripts.
Apart from performing quickly one-time tasks as you supposed in your reply, I heavily use shell scripts to maintain a system interface as well as a bunch of utilities securing the data input/output from the system I'm responsible for.
Now, not many people will actually look deeper into these interface scripts apart from me and a few team members. However, I just wonder if this would justify the fact we have no quality assurance on these scripts, as they almost are as important as the code used behind the interface.
I think I will implement some kind of a basic qa-script to secure at least documentation, backup and version control. The rest is more or less pointless as long as the code's visibility and a few more things like the usage specification and the code comments look fine.
Yes, I also use scripting in some more complex tasks and, of course, I try to assure a minimum quality in terms, mainly, of documentation, comments, version control, etc. But in this world of sysadmins, this task is up to you. In some way it's a matter of making your life easy. Specially when you mantain a great amount of machines and you work in a huge team. But again, no matter how complicated your scripts are, they're not considered as apps. However, that does not mean that those QA techniques or procedures are not suitable for scripting "apps". Even more, in some cases it could be useful.
That's what I say above: QA It's up to you.
Very interesting. I've never thought of implementing that... I just practice my own "QA" just to help myself (and partners) beacuse, nobody's gonna check my scripts. Perhaps, only, their functionality but that's all.
if your scripts affect the business or your company's bottom line, it would be best to treat them as apps --- regardless of what developers think --- and QA them to make sure that whoever needs to support their upkeep can easily do it and to make sure that they adhere to certain standards (i.e., not emailing server error reports to management, not using plain FTP to transfer financial data files, etc.) ...
in this highly audited world we now operate under, all scripts that affect production will eventually be looked at with more than a passing glance and could possibly affect your job situation if found to be non-compliant ...
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.
Exactly. They all will eventually be looked at. But most scripts are no controlled untill they "affect" your job situation, don't you think?
Of course there are places where everithing is taken into account, and must fulfil a bunch of rules and requirements. I think that's a matter of money.
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.
