So what goes wrong?
Firstly, software testing is generally regarded as a non-profit making burden. Token testing schedules are devised according to commercial expedience rather than a serious consideration of the implications of possible errors. The more cynical might point out that, as with the automobile industry, it is often commercially expedient to settle any claims retrospectively than fix the problems before the product is rolled out. There are of course relatively few successful claims against software companies, partly because of their all-encompassing disclaimers and partly due to the difficulty of convincing a jury of wrongdoing in such an intangible technical area as computer software.
Secondly, when anomalies are found that sugest deeper underlying issues the attitude is often to address the symptoms and not to explore further because that would delay the project or open the door to claims of negligence or malpractice. This sometimes extends to turning a blind eye to problems which can be inferred to exist, for example, because they have already been encountered on other developmental branches of the same code base.
Thirdly, with the exception of acceptance testing, testing teams are generally employed by the same organization that wrote the software. This produces an obvious conflict of interests and allows unfair pressure to be brought to bear on the staff concerned.
Fourth, (and this is where methodologies can impart a false sense of security), if the specification is flawed and the testing simply checks the function against the specification, the testing is not going to reveal a problem. Of course the person doing the test may suspect something is awry, but now they are put in a difficult situation. Anecdotal evidence suggests those who speak out in such situations may find their career prospects take a sudden downwards turn. As far as flawed specifications are concerned, I suspect many experienced analysts would agree that competitive tendering is hardly conducive to ensuring that the team who best appreciate the problems actually go on to do the work.
How widespread is the problem?
That is something the IAP has decided to investigate as a step towards realizing the Institution’s transformational statements set out in the IAP “10 Es” launched by the Director General, Alastair Revell at the start of 2013. Your input is vital. It can be anonymous and we are not seeking to highlight particular companies or organizations. If you have encountered any of the issues above please let us know. If you think there are other issues which we should consider then please do likewise. At the moment we are looking for generalized non-technical reasons as this is where we feel the IAP can make a contribution. We will float another article exploring the near impossibility of exhaustively testing virtualized networked multi-processor, multi-tasking systems later if it appeals to our audience.
What can the IAP do about it?
One of our most important aims is to let you know that you are not alone. In keeping with the IAP “10 Es” we aim to stimulate discussion, encourage exchange of ideas, give a voice to our membership, provide guidance to the Industry, and engender the spirit of professionalism within our members. From your responses we will be able to formulate guidelines alerting developers to possible scenarios and suggesting ways of dealing with them in a proper and ethical way. Being a member of a professional body with a Code of Conduct means that you can use refer to our definition of ethical practice when faced with situations in which you feel that you are being pressurized to act in an improper manner. Given a good response we will analyse the information we receive and use the broad findings to encourage debate and improve practice across the industry. If you feel modifications are needed to our Code of Conduct then let us have that debate.
What can you do about it?
We need feedback from within the industry. Whether it is a few lines in an email, academic essay or a multi-page rant every bit of feedback counts. I know many people within our sector have had experience of the issues above and will feel strongly about them. This is an opportunity to have your say and contribute to bringing attention to what is a vital but often overlooked part of our activity as computing professionals.
Please send your comments to ethics@iap.org.uk
Relevant links:
http://www.telegraph.co.uk/news/uknews/royal-mail/10179024/Labelled-as-criminals.html
http://www.dailytech.com/UK+Post+Office+Software+Bugs+Likely+Created+False+Financial+Shortfalls+Imprisonment/article31924.htm
http://www.contactlaw.co.uk/unfair-treatment-of-postmasters-due-to-fault-in-their-horizon-software.html
