ABSTRACT The responsibility for correct execution of software, as well as its fitness in any given setting, becomes increasingly complex, especially when the software impacts and death. This paper addresses the role of the software quality assurance (SQA) function and explores the ethics of the SQA organization as the last point of contact between the software manufacturer and the consumers of the software application. We explore the range of potential ethical issues, possible mitigation strategies, and responsibilities to disclose findings to both software manufacturers and consumers of software applications. INTRODUCTION Software plays a role in many facets of our lives--from software embedded in ovens, to software in cars, and software applications in offices. Some of these systems don't have much impact on our lives, should they fail. If the microwave doesn't come on when set to time bake, or an email to a friend does not get sent, it typically is of little consequence. On the other hand, the failure of some software could cause catastrophic consequences for individuals and even society. The failure of the antilock brake system in a car, or the avionics in an airplane, or the software in an x-ray machine could have serious consequences. One widely cited software related accident in safety-critical systems involved a computerized radiation therapy machine called the Therac-25. Between June 1985 and January 1987, six known accidents involved massive overdoses by the Therac-25, with resultant deaths and serious injuries. Overdoses, although they sometimes involved operator error, occurred primarily because of errors in the Therac-25's software and because the manufacturer did not follow proper software engineering practices. (Leveson & Turner, 1993; Birsch, 2005). Early on we learn, not only to accept but perhaps even expect that software bugs and errors are a normal part of computer applications. The small print when opening and installing software packages may specify that the software manufacturer provides no guarantee of reliability or expectation of correctness. It may even appear that the marketplace rewards low quality in that it may reward additional features and timely release dates, even if they come at the expense of quality. Companies find that it is cheaper to weather the occasional press storm, spend money on PR campaigns touting good security and fix public problems after the fact, than to design security in from the beginning (Schneier, 2007). Who has the ethical responsibility for testing software? Schneier (2005) says that the software vendors that should be liable, not individual programmers. If end users could sue software manufacturers for product defects, then the cost of those defects to the software manufacturers would rise. And if the cost of poor software is higher, there would be more incentive for manufacturers to make their software more secure and with fewer defects. Life and implications are usually associated with doctors. Software engineers and software quality assurance may face similar life and death situations and have corresponding high ethical responsibilities (Qureshi, 2001). It would seem that after decades of software development there would be some assurance that software works as specified in the customer requirements. Is it that software vendors are unwilling to perform sufficient testing? Is it possible to test everything? Finding a certain number of bugs, doesn't mean that the software has no more bugs. On the other hand, not finding any defects doesn't mean there aren't any defects in the software either. Perhaps there are known bugs, but the time and resources to fix these bugs and defects are often not provided and the software is released with known (but not publicly stated) bugs. Is it because there is a low expectation of quality? Is it even possible to get rid of all bugs, especially when we are integrating components from multiple sources and we are dependent on the software that was developed and tested by others? …