Ethical Issues in Computer Engineering: Software Testing

Computer and software engineers are often creating software that will run on a great variety of platforms, from embedded microprocessors to PCs. The code they are creating can be in many different languages, and can be performing many different tasks. Most people probably know about that much, but there is another side to things that they may not understand. When writing code that is going to be produced for a consumer product, there is software testing that happens. Alongside the engineers creating the code for the consumer, there will be others working on code that is built to test the products code. Companies do this so that they can try and work out bugs in their programs, or at least as many as they can. Even though this may seem to be a minor thing, there can be a large ethical debate on how much testing is really enough. There are many bumps on the road to bug free software!

When a company is running software testing not only are they paying the engineers in charge of the testing, but they also have to keep the engineers who are the creators of the original code, and any other support staff necessary. Really on the bottom line, it is a very expensive thing to do. The point where this becomes a problem is when companies want to test their code while also trying to save a buck at the same time. There are many tools available for code testing, and I have even used a couple of them at my job at John Deere Electronic Solutions. Software test programs run the test code and analyze how efficient it is, and if it really is testing everything it should be. In many cases companies will use these kinds of programs to help them with their software testing, but they may not always follow completely though with the test results. Depending on how well the software was written on its first attempt, there could be very few bugs or there could be a seemingly infinite amount of bugs. Ideally as a consumer you want the software you buy to have no problems with it, but that is a very difficult request to make.

Buggy software is a nightmare for both producer and consumer, and both really don't want to deal with it. Our ethical problem comes in here, because most companies will accept that there will be a number of problems with the software they release. The companies will accept the fact that there are bugs, but they will put it out to market just because they need to stop spending time on it. Then we start treading into dangerous waters. How many bugs can a program have for it to be acceptable? How many problems should users just expect to happen? How many problems can the users run into before they get upset, and demand the software be updated?

Consumers want their program to have a minimal number of problems, but they also want their software. In many cases people will present the company with a really "lose - lose" situation. Consumers want their product AND they want it to work. Which from a companies side is a very difficult order to fill, believe it or not. Especially if the company is working under a tough deadline, these sorts of things become nearly impossible. As you can see now, this is indeed a hefty ethical issue. 

The only salvation we seem to have now is in software patches. Because so many of the devices we use today are connected to the internet, it is very easy for companies to update any buggy software via a patch released online. Even though this does fix the issue in a way, there are still some issues to be considered. Some people strongly believe that the ability to release patches like this has made many companies lazy and less motivated to make their software right the first time, because they can just patch up any errors post-release. While it is good that the patches can be made, it is not ideal for them to be used, and it is especially not ideal for them to be abused. I think patching is a fine thing to do, but I don't believe it should be relied upon too heavily. Even understanding that often times the scope of software may be too great to fully iron out all of the bugs, companies should still be trying their very best to make sure as few bugs reach the final product as possible. 

Where I stand on the issue is where most companies get to. I think the best thing for the company to do is to work on the code for as long as feasibly possible, and probably have their testing and debugging set on a timeline so they have a strict due date for their product. It is a dangerous thing for a company to get caught in a cycle of testing and debugging when there is no hope of a solid finish line. It is a ethically wrong thing to release code that has not been completely tested , but it is also ethically wrong for a company to be forced to debug a program for an unrealistic length of time. So there has to be a meeting ground between consumer and developer, on how much testing is enough. Sadly in this situation we end up in more of a gray area of ethics, compared to a clear cut right or wrong side.

Until next time,

-Ian "E Money" Wichmann