Page 267 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 13: Testing

• Should be accurate and tests what it is intended to test. Notes
• No unnecessary steps should be included in it.
• It should be reusable.
• It should be traceable to requirements.
• It should be compliant to regulations.
• It should be independent i.e. we should be able to execute it in any order without any
dependency on other test cases.
• It should be simple and clear, any tester should be able to understand it by reading once.
• Now keeping in mind these characteristics we can write good and effective test cases.
13.3.2 Type of Test Case

A formal written test case can be divided into three main parts:
Information

Information consists of general information about the test case such as a case identifier, case
creator info, test case version, formal name of the test case, purpose or brief description of the
test case and test case dependencies. It should also include specific hardware and software
requirements (if any) and setup or configuration requirements.

Activities
This part consists of the actual test case activities such as the environment that should exist
during testing, activities to be done at the initialization of the test, activities to be done after
test case is performed and step by step actions to be done while testing and the input data that
is to be supplied for testing.
Results
Results are the outcomes of a performed test case. Result data consists of information about
expected results, which is the criteria necessary for the program to pass the test and the actual
recorded results.
13.3.3 Criteria
As a software organization grows and becomes more sophisticated by technology upgrades, it
recognizes the need for Business Analysts and Quality Assurance to support their Information
System functions. Often the practice of software changes released to the QA team is a matter of
informal presentment. This presentment at best includes lists of modules, functional or design
changes and timelines for moving the changes into production. We witness the roots of most test
organizations planted firmly and integrated in the development department. This commonalty or
kinship with the development organization often leads to biasness as the organization grows. The
development of formal test organizations requires a formal interface with development teams.
This interfacing serves as the Entry Criteria for the test organization. In addition, the output from
the test organization can be labelled as Exit Criteria. The quality and effectiveness of software
testing is primarily determined by the quality of the test processes used. The identification of
Entry and Exit criteria in software testing are a critical step in further improving the test process.

Entry Criteria
Entry Criteria for testing is defined as “Specific conditions or ongoing activities that must be
present before a process can begin”. In the Systems Development Life Cycle it also specifies which
entry criteria are required at each phase. Additionally, it is also important to define the time
interval or required amount of lead time that an entry criteria item is available to the process.

LOVELY PROFESSIONAL UNIVERSITY 261