UNIT 6: Software Testing Tools

Chapter Objectives
• Appreciate the need for automated testing tools
• Understand the requirements of testing tools
• Get to know the various categories of testing tools and their functionality
• Learn how to select a testing tool
• Learn the process of introducing the tools in an organization
• Learn how to use WinRunner, LoadRunner and Test Director to get an idea of the
power of testing tools
Software testing tools are of immense use to develop quality software. In this chapter, we
will study the importance of these tools, various categories of testing tools and the
process of introducing tools in your organization. How to use WinRunner, LoadRunner
and TestDirector are also explained-to get an idea of the power of the testing tools and to
illustrate how easy it is to carry out testing by using the tools.
6.1 Need for Tools
Testing the software manually is time-consuming and requires lot of infrastructure and
manpower. All these drawbacks can be overcome if the testing process is automated.
Using these tools has many advantages:
 Once the software is ready for testing, the functionality of the software can be
tested repeatedly to improve the quality and the reliability.
 Testing can be done unattended, for example during night time and during
holidays.
 When the software has to be tested in different environments (different hardware
platforms, different operating systems, using different browsers etc.), the labor
involved can be reduced.
 Performance testing can be done without the need for many computers and many
test engineers. The test tools simulate the multiple users on a single machine.
 Testing process can be planned and managed effectively by using these tools.
 Test reports can be generated automatically for later analysis and corrective
action.
 The testing process can be managed efficiently—the planning can be done
systematically, the tests can be scheduled efficiently, and the bug tracking can be
done effectively.
Hence, using automated test tools results in:
 Improvement in the quality and reliability of the software.
 Drastic reduction in time, effort and money spent on testing.
 A systematic approach to the testing process.
 Efficient management of the testing process even if the teams are at different
geographical locations.
6.2 Classification of Tools
A wide variety of software testing tools are available to carry out the different types of
testing. These testing tools can be broadly divided into the following categories:
1. Functional/Regression Testing Tools: These tools are used to test the
application software and web applications such as web sites. As majority of the
applications involve Graphical User Interface (GUI), the tools test the GUI
objects and functionality automatically. These tools carry out black box testing.
Client/Server applications, Enterprise Resource Planning (ERP), software
packages such as SAP, Customer Relations Management (CRM) software
packages such as Siebel, web sites etc. can be tested for functionality by using
these tools.
Whenever a change is made to the software, the software needs to be retested and
hence these tools are also called regression testing tools.
Example:Compuware's QACenter, Segue Software’s SilkTest, IBM Rational's
Robot, Mecury Interactive’s WinRunner belong to this category.
2. Performance Testing Tools: These tools are used to carry out performance
testing or stress testing. These tools are very useful to test how the application
works when multiple users access the application simultaneously.
The application can be for example, a database or a web site. These tools simulate
multiple users on a single machine and hence you do not need many machines and
many test engineers to do the performance testing.
AutoTester's AutoController, Compuware's QALoad, Mercury Interactive's
LoadRunner, Segue Software's SilkPerformer, IBM Rational's Performance
Tester, Apache JMeter belong to this category.
3. Source Code Testing Tools: These tools check the source code of the application
software. The testing is white box testing and hence the implementation details
are taken into consideration. These tools are divided into two categories:
 Static analysis tools
 Dynamic analysis tools
Static analysis tools are used to check the source code without executing it. These
tools are used to find out a variety of problems in the source code such as:
 Whether coding standards/guidelines are followed or not.
 Whether the code is portable or any machine operating system dependent
features have been used.
 variables declared but unused
 dead code or unreachable code i.e., the code that will never be executed
 Obtaining the coding metrics such as the ratio of commented lines to
uncommented lines, function point average etc.
Popular static analysis tools are IBM Rational Purify, McCabe Visual Quality
ToolSet, Parasoft CodeWizard, QA C and CheckMate. The utility "lint" available
in Unix/Linux systems is an excellent tool for checking the portability of C code
as well as for analyzing the various problems listed above.
 Dynamic analysis tools are used to find out the potential problems in the code, by
executing the code. These tools are used
 To detect memory errors such as memory Allocation errors, memory
leaks, buffer overflow problems
 To check line coverage, branch/path/condition coverage
 Time taken for execution of different portions of the code which is
required to carry out the code optimization etc.
IBM Rational's Purify is a popular tool for checking memory leaks. In Unix/Linux
systems, "profilers" are available (Iprof and prof commands) -- these profilers
display the number of times when each line is executed. Some application
software source code testing tools are: AutomatedQA's AQtime, Parasoft's
Insure++ and Telelogic's Logiscope.
4. Java Testing Tools: As Java has become a popular programming language in
recent years, a number of tools are available exclusively for testing Java
applications. These tools are for testing applications written in Java programming
language and for testing Java classes.
Jemmy is an open source library to create automated tests for Java GUI
applications. JMeter of Apache is open source software to do performance testing.
Parasoft's jtest is used for Java class testing.
5. Embedded Software Testing tools: Testing embedded software is a very
challenging task as the timing requirements for these applications are very
stringent. In embedded systems, the code has to be optimized so that it occupies
the minimum memory. IBM Rational Test Real Time is the widely used test tool
in this category.
6. Network Protocol Testing tools: As computer networks are becoming
widespread, testing networking/communication software has attained lot of
importance in recent years. A number of tools are available for testing networking
and communication protocols. Many test instrumentation vendors such as Agilent
Technologies, Rhode & Schwartz etc. supply protocol analyzers which generate
the necessary protocols based on international standards such as ITU-T standards.
netIQ's ANVL (Automated Network Validation Library) is to test routers and
other networking products. This software generates packets in correct and
incorrect formats to test the networking software. netIQ's Chariot is a network
performance testing tool.
7. Configuration Management/Bug tracking tools: In large software development
projects, configuration management is a very important process. Also, when the
test engineers report bugs, the managers have to track these bugs and ensure that
all the bugs are removed. To facilitate this activity, good workflow management
Software is important. Many such tools, which are web-based, are available.
bugzilla's Bugzilla is an open source defect tracking system. Samba's Jitterbug is a
freeware defect tracking system. Microsoft Excel is also used extensively for bug
tracking.
8. Test process Management Tools: These tools help in managing process-oriented
software testing. Using these tools, the QA manager can create a formal test plan,
allocate resources, schedule unattended testing, track the status of various
 bugs/activities etc. AutoTester's AutoAdviser, Compuware's QADirector, QIS's
OCIT, Segue Software's SilkPlan Pro, IBM Rational Test Manager, Mercury
Interactive's TestDirector are some such tools.
9. Support Tools: A number of tools are available that are not directly used by the
test engineers, but these tools help the developers/testers/QA engineers in
different phases of software development. Some such tools are:
 Requirements management tools are used to manage the requirements.
The tools help in keeping track of the priority of the requirement, whether
each requirement is converted into design/code and whether the
requirement is tested or not. Telelogic FOCAL POINT is a tool used
extensively for requirements management.
 Design tools are used to carry out the analysis and the design of the
software. A large number of tools are available for OOA and OOD, such
as IBM Rational tools using which a detailed design can be carried out by
using object-oriented analysis methodology. However, note that these
tools are used by the developers/architects. Some of these tools are also
capable of generating the test cases from the design. Telelogic TAU G2 is
used to model the requirements of application software and Telelogic
Rhapsody is used to model the requirements of embedded systems.
 Traceability tools help in tracing whether all the specifications have been
tested by linking each specification with the corresponding test case.
 Unit testing tools are used to carry out the unit testing. Generally, only the
developers carry out the unit testing, not the test engineers. The tools nunit
(www.nunit.org) and junit (www.junit.org) are popular open source unit
testing tools for C++ and Java programs respectively.
6.2.1 Functional/Regression Testing Tools
In functional testing of software, the functionality of the software is tested without
bothering about the source code and implementation details.
Consider example of testing a login process. In many applications, initially a login screen
will appear and you need to type in a username and a password. Only users who are
authorized to use the application will be allowed to enter the application. Assume that a
user is given the username "john' and password as 'mary'. To test this simple GUI, you
need to generate the test cases. The specification says that the username and the password
are case-sensitive. Hence, if the user types "John", it is an invalid username. You can
generate the test cases as shown in Table 8.2.
Input: user name Input: Password Expected output
john mary Login successful
John Mary Login failed
Jhon [blank field] Login failed
JHON MARY Login failed
Jhon Jhon Login failed
Table 8.2 Test cases for Login screen
Just to test a login screen, you need to generate a good number of test cases. The
development engineer, during the initial stages of development, would give his software
with lot of bugs (the login will be successful if the password field is left blank). Every
time, he modifies the software, you need to run all the above test cases and check whether
the software still has any bugs. Obviously, if you record the test by using a tool, the test
script can be run repeatedly.
When a user enters his login name and password, the software will check in a database
whether a valid username and password are entered. So, the login name can be not only
john, but also donald, bush, prasad and so on. It is not possible to generate test cases by
entering so many usernames and passwords manually. Testing tools provide a beautiful
mechanism through data driven testing. In data driven testing, the username and
password are considered as variables. The values these variables can take can be obtained
from a database and the testing is carried out on them.
All functional/regression testing tools operate in a similar fashion. They capture the user
interactions with the GUI (keyboard entries and mouse clicks) and automatically create a
test script. The script can be run repeatedly without the need for interacting with the GUI
again and again. The scripting languages differ for each tool.
6.2.2 Performance/Load Testing Tools
Client/Server (C/S) applications, many users access the server application (such as a
database) simultaneously. In such a case, the software has to be tested for its
performance.
Consider a database application. When only one user accesses the database, the
transaction responses time to query the database and obtain the report is say, 10 Seconds.
When 10 users access the database simultaneously, what will be the response time--10
seconds or 40 seconds? When 1000 users access the database simultaneously what will
be the response time--10 seconds or 10 minutes? No user will accept a few minutes of
response time.
Generally, in the SRS document, the response time will be specified. How do you test the
software to find out the response time when say 100 users are simultaneously accessing
the database? As shown in Figure 8.2, you need to connect 100 client systems and then
put 100 test engineers on the job and use a communication network such as a Local Area
Network (LAN) or a Wide Area Network (WAN). Your company will go bankrupt by the
time you complete the testing. An economical approach is to use the performance testing
tools which will do the job with minimal infrastructure and minimal number of persons.

Figure 8.2 Performance testing of a client/server application without using tools

The performance testing tools functionality is shown in Figure 8.3. The server application
continues to run on the server. But only one or a few clients will be running the client
application but on these client machines, many virtual users are simulated, effectively
stimulating an environment in which 100 users access the database.

Figure 8.3 Load Testing of client/server application using automated tools

Today's many enterprise applications such as ERP software, web services, web sites,
CRM software etc. need to be tested for performance testing. Performance testing is also
called load testing. These tools display the performance of the application by using
graphs and charts so that analysis will be easy. For instance, you can plot a graph that
shows the response time as a function of the number of simultaneous users who access
the database.
6.2.3 Testing Process Management Tools
Whether you are a manager or a test engineer, you need to follow a rigorous process for
testing. This process involves working out a detailed test plan, working out the test cases,
deciding the schedule for running various tests, generating the test reports, analyzing the
test reports and tracking the bugs and checking whether the bugs have been removed and
doing regression testing on the modified software. In addition, many managerial activities
such as forming test teams, assigning responsibilities and target dates etc. need to be done
to effectively manage the testing process. Many managers do all these activities on an ad-
hoc basis; but making use of testing management tools will increase the productivity
tremendously.
Nowadays, many software companies have teams at different geographical
locations work on the same project. In such a case, the testing management tools can be
used effectively for managing the testing process. Many commercially available testing
management tools are web-based. A test engineer can log into the web site and update the
defect report. The QA manager located at another place can login to the web site, check
the status and assign the bug removal work to a developer. After the developer removes
the bug, he can update the bug status to be corrected. Many tools provide the facility to
generate emails and send the email to the person concerned.
For project managers, defect tracking is the most important activity. During the testing
phase, a large number of defects are reported by the test engineers. Each defect has to be
attended by the development engineer. Tracking these defects is a exceptional task and it
must be done with the help of a tool. The defect tracking or bug tracking tools help in
achieving this. The tools facilitate storing the information about the defect in a database
and periodically updating the status. Each defect has to be put in a database and its details
are recorded. These details include:
 Who detected the defect?
 The entry criteria (status of the software just before the defect occurred).
 The exit criteria (status of the software after the defect).
 Date and time when the defect was found.
 Priority of the defect (how fast the defect has to be rectified).
 To whom the defect rectification been assigned.
 The status of the defect (rectification in progress, rectified, to be taken up later).
 Target date for rectification.
The database can be updated regularly by the engineers/managers. The manager can also
get the necessary reports from the database and also generate the metrics which reflect
the quality of the testing process.
6.3 Benefits of Tools
The potential benefits of the tools are:
 In manual testing, the test may not be repeatable. If the testing is done by using a
tool, the repeatability can be ensured as the test case and test results are stored.
 When testing is done manually, it may result in subjective evaluation of the
software. These subjective statements make the developers very angry. Using test
tools, the testing can be made objective. For example, a test can be repeatedly
done and then the reliability can be assessed.
 In manual testing, to carry out the regression testing, the same inputs have to be
repeatedly given and the output is checked. For human beings, this repetitive
work is very boring and unproductive. Tools are extremely useful for regression
testing.
 If Performance/load/stress testing is done manually for client/server and web
applications, lot of infrastructure (computers and network) and manpower are
required. If tools are used, the testing can be done with minimal infrastructure and
manpower.
 Managing the testing process manually is very difficult. All this can be done very
efficiently by using the tools. Organizations in which there is no defined testing
process will greatly benefit by using the tools.
 For software with thousands and even millions of lines of code, to check whether
the source code is as per coding standards can be easily done through tools.
  For white box testing and to ensure whether each and every line of code is tested,
tools (for example, the profilers) will be very handy, manual white box testing is
next to impossible.
 The test documents (test plans, test logs, test results etc.) can be archived
efficiently and managed by using configuration management tools.
 Test metrics can be easily measured, analyzed and archived. For example, the
number of defects, the severity of defects, the number of incident reports,
productivity of the test engineers, residual defects etc. can be easily collected and
analyzed through statistical analysis tools and presented to the management
through graphs and charts.
6.4 Risks Associated with the Tools
Though using the tools has many benefits, we need to remember that there are some risks
too. We need to appreciate the following risks:
 The management does not estimate the time, effort and money required to
introduce a tool into the development process. The managers/QA specialists need
to appreciate that in addition to the tool cost, the management has to spend on
training the employees on the tool, carrying out a pilot project and if the pilot
project is successful, to introduce the tool in the overall development process.
 When carrying out the pilot project, the success criteria need to be clearly defined.
If the criteria are not defined well, and the tool is introduced in the development
process, there may be problems.
 Assuming that the tool will totally replace the smart test engineers is incorrect.
For some applications, manual testing may still be better. The tool may not be
capable of doing all types of testing. Unrealistic expectations from the tool are
one of the major risks.
6.5 Does your Organization Need Tools?
Does your organization require an automated testing tool? This question can be very
easily answered, if you spend some time and analyze the existing scenario in your
organization:
 Are your customers happy with the software delivered by you? If they are
unhappy and you get many reports on the bugs detected, the testing process needs
to be improved a lot. Certainly, you need to consider the option of using a testing
tool. The amount of effort and money you will be spending on corrective
maintenance will be much more than the cost of buying the testing tools.
 If your customers are happy with the software you have delivered, find out the
effort, time and money spent on the testing phase. The productivity of the people
can be increased many fold by using the tools. The test engineers can do a more
productive work in generating the test cases, rather than unproductive data entry
work by giving manual inputs.
 How many testing engineers are leaving your organization? If the manpower
attrition rate is very high, then the most likely reason is that they were getting
bored by doing repetitive things. Testing tools remove the manual work and the
test engineers will enjoy the testing process.
  Using manual testing, you can never bring out a quality product if performance
testing is a part of the requirements. If performance testing has to be done on your
software, tools come in handy.
 If your organization believes in a process-oriented approach to testing, testing
tools will be of immense use.
 If your project teams are located at different places, a web-based management
tool will be very effective for an efficient management of the testing process.
6.6 Selecting Tools
Once you decide to use testing tools, you need to make a choice based on the following
criteria:
 What types of testing have to be done on the software? Invariably, most of the
application software packages need to be tested for functionality. As the software
is likely to be modified, regression testing is also a must. Hence, you need to get
functional/regression testing tools.
 If your software is a C/S application or a web application, you may need to do
load testing. In such cases, you need to use a performance testing tool as well.
 Some vendors integrate testing management tools along with the above tools.
Alternatively, some vendors supply a separate module at additional cost for
testing process management.
 Once the types of testing tools required are decided, you need to obtain the tool
for the environment in which the software runs. Your application may be running
only in Windows, or only in Unix (or its variants such as Linux, Solaris etc.).
Sometimes you may have to run the software in different platforms. In such cases,
you need to check whether the testing tool supports such environments.
 Testing tool vendors also give tools that support testing for proprietary software
packages such as Siebel, SAP etc.
 If you need to test the source code as well, you need to buy the source code
testing tools.
 If you working on a very large software development project, tracking the bugs is
a major issue. Bug tracking tools need to be used in such a case.
 If your organization is keen on implementing the process-oriented testing, testing
process management tools are a must. If the project teams are at different places, a
web-enabled testing tool will be of great use.
In addition to the technical aspects, the manager needs to consider the following aspects:
 Whether the tool vendor has a local presence in your country or city.
 Whether the vendor will provide enough support after purchase of the tools. The
support should be in terms of providing the upgrades, rectifying any bugs in the
software etc.
 Whether the vendor will provide training to your employees on the tools.
 What is the cost of the tools?
  What is the cost of yearly upgrades? Some vendors charge exorbitantly for yearly
upgrades.
 What are the licensing terms? Is the license valid per site or per system? Is the
license renewable yearly?
 Is there a provision for this tool for integration with tools of other vendors?
6.7 Introducing the Tools in the Testing Process
In some organizations, when the management comes to know about the tools and some
success stories, then the management will get excited and spend lot of money to buy the
tools. Later on, the management will realize that the tools are not being effectively used
and all the money is a waste.
It is very important for the management to follow a systematic procedure for introducing
a tool in the organization, as shown in Figure 8.4.

Figure 8.4: Process of introducing a tool in the organization

  You need to assess the present testing process and find out the strengths and
weaknesses. Metrics such as how much effort/money is being spent on the
product after it is delivered to the customer, how many bugs were reported by the
customer and the severity of these bugs, how many test engineers are leaving the
organization etc., will reflect how good or how bad your testing process is.
 Depending on the project requirements, identify the types of tools required for
your organization.
 Evaluate the different commercially available tools as well as open source tools
and select the required tools.
 Using the selected tools, carry out a pilot project. Identify the criteria for
evaluating the effectiveness of the tools.
 If the pilot project is successful, introduce the tools for other projects. If the pilot
project is not successful, then analyze the need for another pilot project.
Code of Ethics for Software Professionals
Human Ethics
Every human being has certain responsibilities towards the society and the surrounding
environment. As good citizens of the world, we all have to contribute our might to make
the world a better place to live in. As human beings, we have to follow certain principles
to achieve this. Our responsibilities include doing well for the society and following the
rules and regulations set by the government for one's country's growth, prosperity and
security. While doing so, you may encounter conflicts—as to what is 'good' and what is
‘bad'. We hear a number of episodes wherein individuals fight rules and regulations---it is
such people, who create history and also contribute to the growth of the profession. As an
example, you may feel that the regulations framed by governments are not correct (for
instance the regulation that encryption software cannot be exported). If you have a strong
conviction that it is not correct, you can fight against it. Ethical issues are highly
subjective and one has to be guided by one's conscience.
9.2 Professional Ethics
A professional---doctor, or engineer or chartered accountant--has further obligations to
the society because professionals play a greater role in designing the future for the rest of
the society. Every professional has to adhere to a 'code of ethics'—the guidelines to be
followed while discharging one's duties as a professional.
IEEE, the largest professional body of electrical and electronics engineers, framed the
code of ethics, given in Frame 9.1. Every member of this professional body is expected to
follow this code of ethics.
We, the members of the IEEE, in recognition of the importance of our technologies in
affecting the quality of life throughout the world, and in accepting a personal obligation
to our profession, its members and the communities we serve, do hereby commit
ourselves to the highest ethical and professional conduct and agree:
 To accept responsibility in making engineering decisions consistent with safety,
health and welfare of the public, and to disclose promptly factors that might
endanger the public or the environment;
  To avoid real or perceived conflicts of interest whenever possible, and to disclose
them to the affected parties when they do exist;
 To be honest and realistic in stating claims or estimates based on available data;
 To reject bribery in all its forms;
 To improve the understanding of technology, its appropriate application and
potential consequences;
 To maintain and improve our technical competence and to undertake
technological tasks for others only if qualified by training or experience, or after
full disclosure of pertinent limitations;
 To seek, accept, and offer honest criticism of technical work, to acknowledge and
correct errors, and to credit properly the contribution of others;
 To treat fairly all persons regardless of such factors as race, religion, gender,
disability, age or national origin;
 To avoid injuring others, their property, reputation, or employment by false or
malicious action;
 To assist colleagues and co-workers in their professional development and to
support them in following this code of ethics.
Frame 9.1: IEEE Code of Ethics © 1999 IEEE. Reprinted with permission.

9.3 Ethical Issues in Software Engineering

With the influence of computers on all walks of life and the role of software in all the
systems, software professionals have the power to do good or bad to the society. As
responsible human beings and as professionals, we need to use the knowledge and skills
for the benefit of the society. Every software professional has to follow a code of ethics
[Gottenbarn 1997] keeping in view the importance of quality software development and
the ill effects of defective software. The quality of software will affect the society and
human life---the ill effects of defective software in such systems as medical equipment,
transportation systems, nuclear plants, banking etc., are not difficult to imagine.

Figure 9.1 Obligations of a Software Professional

As shown in Figure 9.1, every software professional has obligations to
 Society
 Self
 Profession
 Product
 Employer
 Client
 Colleagues
These obligations have to be fulfilled by every person as
 A human being
 A professional
 A software engineering professional
While discharging one's duties, sometimes there may be a conflict between the
obligations to different entities. Consider the following examples:
 At the place of work, you may be constrained to violate copyright laws. What
would you do?
 The employer (or the manager to whom you report) insists on violating
intellectual property rights by asking you to copy software developed at some
other organization. Would you accept to do it or not?
 The employer insists on delivering software to the client in spite of the fact that
there are some known defects. You insist on informing the client about the
defects, your employer says no. What stand do you take? If the software has to be
used in the intensive care unit of a hospital, would you accept?
 A colleague of yours is passing the confidential information of your organization
to an outsider. Will you be silent or inform your superiors?
The answers to these questions (and many more such questions which we encounter
during our careers) depend on whether we promote our self-interest or accept what the
manager / employer says; or as professionals with ethical values, use our judgment to do
what we think is RIGHT-irrespective of the consequences.
9.4 Code of Ethics for Software Professionals
Ethical issues have no Boolean (yes/no) answer. You have to use your own judgment and
do what you feel is right. Professional bodies have formulated code of ethics, a set of
guidelines, which can be used by professionals to make judgments.
Association for Computing Machinery (ACM) and IEEE-Computer Society Joint Task
Force on Software Engineering Ethics and Professional Practices (SEEPP) recommended
Software Engineering Code of Ethics and Professional Practice (Version 5.2) and it was
approved by ACM and IEEE CS as the standard for teaching and practicing software
engineering. The complete code of ethics and professional practices is reprinted below.
[Computer October 1999].
9.4.1 Software Engineering Code of Ethics and Professional Practice
Copyright © 1999 by the Institute of Electrical and Electronics Engineers, Inc., and the
Association for Computing Machinery, Inc.
Short Version: Preamble
The short version of the code summarizes aspirations at a high level of abstraction; the
clauses that are included in the full version give examples and details of how these
aspirations change the way we act as software engineering professionals. Without the
aspirations, the details can become legalistic and tedious; without the details, the
aspirations can become high-sounding but empty; together, the aspirations and the details
form a cohesive code.
Software engineers shall commit themselves to making the analysis, specifications,
design, development, testing, and maintenance of software a beneficial and respected
profession. In accordance with their commitment to the health, safety, and welfare of the
public, software engineers shall adhere to the following eight Principles:
 Public: Software engineers shall act consistently with the public interest.
 Client and Employer: Software engineers shall act in a manner that is in the best
interests of their client and employer, consistent with the public interest.
 Product: Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
 Judgment: Software engineers shall maintain integrity and independence in their
professional judgment.
 Management: Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and
maintenance.
 Profession: Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
 Colleagues: Software engineers shall be fair to and supportive of their colleagues.
 Self: Software engineers shall participate in lifelong learning regarding the
practice of their profession and shall promote an ethical approach to the practice
of profession.
Full Version: Preamble
Computers have a central and growing role in commerce, industry, government,
medicine, education, entertainment, and society at large. Software engineers are those
who contribute, by direct participation or by teaching, to the analysis, specification
design, development, certification, maintenance, and testing of software systems.
Because of their roles in developing software systems, software engineers have
significant opportunities to do good or cause harm, to enable others to do good or cause
harm, or to influence others to do good or cause harm. To ensure, as much as possible,
that their efforts will be used for good, software engineers must commit themselves to
making software engineering a beneficial and respected profession. In accordance with
that commitment, software engineers shall adhere to the following Code of Ethics and
Professional Practice.
The Code contains eight Principles related to the behavior of and decisions made by
professional software engineers, including practitioners, educators, managers,
supervisors, and policy makers, as well as trainees and students of the profession. The
Principles identify the ethically responsible relationships in which individuals, groups,
and organizations participate and the primary obligations within these relationships. The
Clauses of each Principle are illustrations of some of the obligations included in these
relationships. These obligations are founded in the software engineer's humanity, in
special care owed to people affected by the work of software engineers, and in the unique
elements of the practice of software engineering. The Code prescribes these as
obligations of anyone claiming to be or aspiring to be a software engineer.
Ethical tensions can best be addressed by thoughtful consideration of fundamental
principles, rather than blind reliance on detailed regulations. These Principles should
influence software engineers to consider broadly who is affected by their work; to
examine if they and their colleagues are treating other human beings with due respect; to
consider how the public, if reasonably well informed, would view their decision; to
analyze how the least empowered will be affected by their decisions, and to consider
whether their acts would be judged worthy of the ideal professional working as a
software engineer. In all these judgments concern for the health, safety and welfare of the
public is primary; that is, the "Public Interest" is central to this Code.
The Code is not simply for adjudicating the nature of questionable acts; it also has an
important educational function. As this Code expresses the consensus of the profession
on ethical issues, it is a means to educate both the public and aspiring professionals about
the ethical obligations of all software engineers.
Principles
Principle 1: Public
Software engineers shall act consistently with the public interest. In particular, software
engineers shall, as appropriate:
 Accept full responsibility for their own work.
 Moderate the interests of the software engineer, the employer, the client, and the
users with the public good.
 Approve software only if they have a well-founded belief that it is safe, meets
specifications, passes appropriate tests, and does not diminish quality of life,
diminish privacy, or harm the environment. The ultimate effect of the work
should be to the public good.
 Disclose to appropriate persons or authorities any actual or potential danger to the
user, the public, or the environment, that they reasonably believe to be associated
with software or related documents.
 Cooperate in efforts to address matters of grave public concern caused by
software, its installation, maintenance, support, or documentation.
 Be fair and avoid deception in all statements, particularly public ones, concerning
software or related documents, methods and tools.
 Consider issues of physical disabilities, allocation of resources, economic
disadvantage, and other factors that can diminish access to the benefits of
software.
  Be encouraged to volunteer professional skills to good causes and contribute to
public education concerning the discipline.
Principle 2: Client and Employer
Software engineers shall act in a manner that is in the best interests of their client and
employer, consistent with the public interest. In particular, software engineers shall, as
appropriate:
 Provide service in their areas of competence, being honest and forthright about
any limitations of their experience and education.
 Not knowingly use software that is obtained or retained either illegally or
unethically.
 Use the property of a client or employer only in ways properly authorized, and
with the client’s or employer's knowledge and consent.
 Ensure that any document upon which they rely has been approved, when
required, by someone authorized to approve it.
 Keep private and confidential information gained in their professional work,
where such confidentiality is consistent with the public interest and consistent
with the law.
 Identify, document, collect evidence, and report to the client or the employer
promptly if, in their opinion, a project is likely to fail, to prove too expensive, to
violate intellectual property law, or otherwise to be problematic.
 Identify, document, and report significant issues of social concern, of which they
are aware, in software or related documents, to the employer or the client.
 Accept no outside work detrimental to the work they perform for their primary
employer.
 Promote no interest adverse to their employer or client, unless a higher ethical
concern is being compromised; in that case, inform the employer or another
appropriate authority of the ethical concern.

Principle 3: Product
Software engineers shall ensure that their products and related modifications meet the
highest professional standards possible. In particular, software engineers shall, as
appropriate:
 Strive for high quality, acceptable cost, and a reasonable schedule, ensuring
significant tradeoffs are clear to and accepted by the employer and the client, and
are available for consideration by the user and the public.
 Ensure proper and achievable goals and objectives for any project on which they
work or propose.
 Identify, define, and address ethical, economic, cultural, legal, and environmental
issues related to work projects.
 Ensure that they are qualified for any project on which they work or propose to
work, by an appropriate combination of education and training, and experience,
  Ensure an appropriate method is used for any project on which they work or
propose to work.
 Work to follow professional standards, when available, that are most appropriate
for the task at hand, departing from these only when ethically or technically
justified.
 Strive to fully understand the specifications for software on which they work.
 Ensure that the specifications for software on which they work have been well
documented, satisfy the users' requirements, and have the appropriate approval.
 Ensure realistic quantitative estimates of cost, scheduling, personnel, quality, and
outcomes on any project on which they work or propose to work and provide an
uncertainty assessment of these estimates.
 Ensure adequate testing, debugging, and review of software and related document
on which they work.
 Ensure adequate documentation, including significant problems discovered and
solutions adopted, for any project on which they work.
 Work to develop software and related documents that respect the privacy of those
who will be affected by that software.
 Be careful to use only accurate data derived by ethical and lawful means, and use
it only in ways properly authorized.
 Maintain the integrity of data, being sensitive to outdated or flawed occurrences
 . Treat all forms of software maintenance with the same professionalism as new
development.
Principle 4: Judgment
Software engineers shall maintain integrity and independence in their professional
judgment. In particular, software engineers shall, as appropriate:
 Temper all technical judgments by the need to support and maintain human
values.
 Only endorse documents either prepared under their supervision or within their
areas of competence and with which they are in agreement.
 Maintain professional objectivity with respect to any software or related
document they are asked to evaluate.
 Not engage in deceptive financial practices such as bribery. double billing, or
other improper financial practices.
 Disclose to all concerned parties those conflicts of interest that cannot reasonably
be avoided or escaped.
 Refuse to participate, as members or advisors, in a private, governmental, or
professional body concerned with software-related issues in which they, their
employers, or their clients have undisclosed potential conflicts of interest.
Principle 5: Management
Software engineering managers and leaders shall subscribe to and promote an ethical
approach to the management of software development and maintenance.
In particular, those managing or leading software engineers shall, as appropriate:
 Ensure good management for any project on which they work, including effective
procedures for promotion of quality and reduction of risk.
 Ensure that software engineers are informed of standards before being held to
them.
 Ensure that the software engineers know the employer's policies and procedures
for protecting passwords, files and information that is confidential to the employer
or confidential to others.
 Assign work only after taking into account appropriate contributions of education
and experience tempered with a desire to further that education and experience.
 Ensure realistic quantitative estimates of cost, scheduling, personnel, quality, and
outcomes on any project on which they work or propose to work, and provide an
uncertainty assessment of these estimates.
 Attract potential software engineers only by full and accurate description of the
conditions of employment.
 Offer fair and just remuneration.
 Not unjustly prevent someone from taking a position for which that person is
suitably qualified.
 Ensure that there is a fair agreement concerning ownership of any software,
processes, research, writing, or other intellectual property to which a software
engineer has contributed.
 Provide for due process in hearing charges of violation of an employer's policy or
of this Code.
 Not ask a software engineer to do anything inconsistent with this Code.
 Not punish anyone for expressing ethical concerns about a project.

Principle 6: Profession
Software engineers shall advance the integrity and reputation of the profession consistent
with the public interest. In particular, software engineers shall, as appropriate:
 Help develop an organizational environment favorable to acting ethically.
 Promote public knowledge of software engineering.
 Extend software engineering knowledge by appropriate participation in
professional organizations, meetings, and publications.
 Support, as a member of a profession, other software engineers striving to follow
this Code.
 Not promote their own interest at the expense of the profession, client, or
employer.
 Obey all laws governing their work, unless, in exceptional circumstances, such
compliance is inconsistent with the public interest.
  Be accurate in stating the characteristics of software on which they work,
avoiding not only false claims but also claims that might reasonably be supposed
to be speculative, vacuous, deceptive, misleading, or doubtful.
 Take responsibility for detecting, correcting, and reporting errors in software and
associated documents on which they work.
 Ensure that clients, employers, and supervisors know of the software engineer's
commitment to this Code of Ethics, and the subsequent ramifications of such
commitment.
 Avoid association with businesses and organizations which are in conflict with
this code.
 Recognize that violations of this Code are inconsistent with being a professional
software engineer.
 Express concerns to the people involved when significant violations of this Code
are detected unless this is impossible, counterproductive, or dangerous.
 Report significant violations of this Code to appropriate authorities when it is
clear that consultation with people involved in these significant violations is
impossible, counterproductive, or dangerous.
Principle 7: Colleagues
Software engineers shall be fair to and supportive of their colleagues. In particular,
software engineers shall, as appropriate:
 Encourage colleagues to adhere to this Code.
 Assist colleagues in professional development.
 Credit fully the work of others and refrain from taking undue credit.
 Review the work of others in an objective, candid, and properly documented way.
 Give a fair hearing to the opinions, concerns, or complaints of a colleague.
 Assist colleagues in being fully aware of current standard work practices
including policies and procedures for protecting passwords, files, and other
confidential information, and security measures in general.
 Not unfairly intervene in the career of any colleague; however, concern for the
employer, the client, or public interest may compel software engineers, in good
faith, to question the competence of a colleague.
 In situations outside of their own areas of competence, call upon the opinions of
other professionals who have competence in that area.
Principle 8: SELF
Software engineers shall participate in lifelong learning regarding the practice of their
professional and shall promote an ethical approach to the practice of the profession. In
particular, software engineers shall continually endeavor to:
 Further their knowledge of development in the analysis, specification, design,
development, maintenance, and testing of software and related documents,
together with the management of the development process.
  Improve their ability to create safe, reliable, and useful quality software at
reasonable cost and within a reasonable time.
 Improve their ability to produce accurate, informative, and well-written
documentation
 Improve their understanding of the software and related documents on which they
work and of the environment in which they will be used.
 Improve their knowledge of relevant standards and the law governing the
software and related documents on which they work.
 Improve their knowledge of this Code, its interpretation, and its application to
their work.
 Not give unfair treatment to anyone because of any irrelevant prejudices.
 Not influence others to undertake any action that involves a breach of this Code.
 Recognize that personal violations of this Code are inconsistent with being a
professional software engineer.
If each and every software engineer follows this code of ethics and professional practice,
it can be ensured that the project execution will be smooth and every project will be great
success.
9.5 Ethical Issues: Right versus Wrong
While pursuing a career in software engineering, we all encounter situations in which
there may not be right/wrong answer for a particular question. In such cases, you should
always use you own judgment to decide what is right and what is wrong but that
judgment should be based on realistic reasoning and with adequate background
information. For instance, there are professionals who feel that working in defense
organizations particularly in projects for destroying mankind is wrong: but many of those
who work on such projects are proud of their contributions for the defense of their
countries. These are two different viewpoints-it is not correct to say that one is right and
the other is wrong. You have to decide for yourself.
The broad guidelines as given in the code of ethics are to ensure that no damage is
done to human life and society at large for the sake of personal advancement. Every
software professional's main objective must be to improve the quality of life.
Everywhere, money, power and fame drive human beings. To achieve their personal
goals, the ethics are set aside resulting in corruption, crime and unhealthy social life.
Professionals, who have a great role to play to make the world a better place to live, need
to follow the code of ethics. As software becomes the lifeline of many critical systems,
the software professionals have a great responsibility so that the society respects the
software profession. It is not enough to have technical competence; one has to have social
consciousness and contribute to improve the quality of life through ethical behavior.