ECAP437
SOFTWARE ENGINEERING
PRACTICES PRACTICES
Ashwani Kumar
Assistant Professor
Learning
Outcomes
After this Lecture, you will be able to learn
• Test case
• Test case template
Test case
• The test case a group of conditions under which a tester
determines whether a software application is working as
per the customer's requirements or not
• A Test Case contains test steps, test data, precondition,
post condition developed for specific test scenario to
verify any requirement
Test case
• A test case is a set of instructions on “HOW” to validate a
particular test objective/target, which when followed will
tell us if the expected behaviour of the system is satisfied
or not.
Why test cases?
• To require consistency in the test case execution
• To make sure a better test coverage
• It depends on the process rather than on a person
• To avoid training for every new test engineer on the
product
To make sure a better test coverage
• We should cover all possible scenarios and document it,
so that we need not remember all the scenarios again and
again.
It depends on the process rather than on a person
• A test engineer has tested an application during the first
release, second release, and left the company at the time
of third release
• If the person is not there for the third release, it becomes
difficult for the new person. Hence all the derived values
are documented so that it can be used in the future.
To avoid giving training for every new test
engineer on the product
• When the test engineer leaves, he/she leaves with a lot of
knowledge and scenarios.
• Those scenarios should be documented so that the new
test engineer can test with the given scenarios and also
can write the new scenarios.
Best Practice for writing Test Case
• Test Cases need to be simple and transparent
• Create Test Case with End User in Mind
• Avoid test case repetition
• Do not assume
• Ensure 100% Coverage
• Test Cases must be identifiable
Best Practice for writing Test Case
• Implement Testing Techniques
• Self-cleaning
• Repeatable and self-standing
• Peer Review.
Test Cases need to be simple and transparent
• Create test cases that are as simple as possible. They must
be clear and concise as the author of the test case may not
execute them.
• Use assertive language like go to the home page, enter
data, click on this and so on
Create Test Case with End User in Mind
• The ultimate goal of any software project is to create test
cases that meet customer requirements and is easy to use
and operate.
• A tester must create test cases keeping in mind the end
user perspective
Avoid test case repetition
• Do not repeat test cases. If a test case is needed for
executing some other test case, call the test case by its
test case id in the pre-condition column
Do not Assume
• Do not assume functionality and features of your
software application while preparing test case. Stick to
the Specification Documents
Ensure 100% Coverage
• Make sure you write test cases to check all software
requirements mentioned in the specification document.
• Use Traceability Matrix to ensure no functions/
conditions is left untested.
Test Cases must be identifiable
• Name the test case id such that they are identified easily
while tracking defects or identifying a software
requirement at a later stage.
Implement Testing Techniques
• Boundary Value Analysis (BVA): As the name suggests
it's the technique that defines the testing of boundaries for
a specified range of values.
• Equivalence Partition (EP): This technique partitions
the range into equal parts/groups that tend to have the
same behavior.
Implement Testing Techniques
• State Transition Technique: This method is used when
software behavior changes from one state to another
following particular action.
• Error Guessing Technique: This is
guessing/anticipating the error that may arise while doing
manual testing. This is not a formal method and takes
advantages of a tester's experience with the application
Self-cleaning
• The test case you create must return the Test
Environment to the pre-test state and should not render
the test environment unusable. This is especially true for
configuration testing.
Repeatable and self-standing and Peer Review
• The test case should generate the same results every time
no matter who tests it
• After creating test cases, get them reviewed by your
colleagues. Your peers can uncover defects in your test
case design, which you may easily miss.
Types of test cases
• Functionality Test Cases
• User Interface Test Cases
• Performance Test Cases
• Integration Test Cases
Types of test cases
• Usability Test Cases
• Database Test Cases
• Security Test Cases
• User Acceptance Test Cases
Functionality Test Cases
• Functionality test cases are used to discover if an
application’s interface works with the rest of the system
and its users. The tests identify the success or failure of
functions that the software is expected to perform.
User Interface Test Cases
• User interface test cases are used to verify that specific
pieces of the Graphical User Interface (GUI) look and
work as expected.
• These types of test cases can be used to identify cosmetic
inconsistencies, grammar and spelling errors, links, and
any other elements the user interacts with or sees.
Performance Test Cases
• Performance test cases validate response times and
overall effectiveness of an application.
• After executing an action, how long does it take for the
system to respond? Performance test cases should have a
very clear set of success criteria.
Integration Test Cases
• Integration test cases are meant to determine how
different modules interact with each other.
• The main purpose with integration test cases are to ensure
interfaces between the different modules are working
properly.
Usability Test Cases
• Usability test cases can often be referred to as “tasks” or
“scenarios”. Rather than providing detailed step-by-step
instructions to execute the test, the tester is presented
with a high level scenario or task to complete.
Database Test Cases
• Test cases for database testing examine what’s happening
behind the scenes.
• Database tests are used to verify the developer has
written the code in a way that stores and handles data in a
consistent, safe manner
Security Test Cases
• Security test cases help ensure the application restricts
actions and permissions wherever necessary.
• These test cases are written to protect data when and
where it needs to be safeguarded.
User Acceptance Test Cases
• User acceptance test cases, or “UAT” test cases, help the
team test the user acceptance testing environment.
• These test cases should be broad, covering all areas of the
application.
Test case Advantages
• Test cases ensure good test coverage
• Help improve the quality of software,
• Decreases the maintenance and software support costs
• Help verify that the software meets the end user requirements
• Allows the tester to think thoroughly and approach the tests
from as many angles as possible
• Test cases are reusable for the future – anyone can reference
them and execute the test.
Test case template
• A test case template is a document containing an
organized list of test cases for different test scenarios that
check whether or not the software has the intended
functionality.
• It is well-designed document for developing and better
understanding of the test case data for a particular test
case scenario
Test case template fields
• Test case ID Test Priority
• Name of the Module Test Designed by
• Date of test designed Test Executed by
• Date of the Test Execution Name or Test Title
• Description of Test Pre-condition
Test case template fields
• Dependencies Test Steps
• Test Data Expected Results
• Post-Condition Actual Result
• Status (Fail/Pass) Notes
Test case template example
Test Case Test Case Summary Expected Results Remarks
ID Name
<unique id <short name to <brief summary of this test case> <brief explanation of what the <any additional
to identify identify the test expected results of this test case remarks>
the test case> should be>
case>
Test case template example
Test Case ID TC_Functionality_01
Description
Module
Prepared By [Link] Date
Prepar
ed
Reviewed / Updated Date
Review
ed
Tested By [Link] Date
Tested
Test Activities
Sl. No. Step Description Expected Actual Results
Results
Test Data Sets
Data Type Data Set 1 Data Data Set 3
Set 2
Test Case Result
That’s all for now…
