Test case development presentation done by Hrushikesh Wakhle. Importance of Test Cases, How and Why to develop Test cases.

2. Test Case DevelopmentTest Case Development
Team:Team:
Hrushikesh WakhleHrushikesh Wakhle
Kiran HoleKiran Hole
Rashmi BinzadeRashmi Binzade
Unnati PatelUnnati Patel

3. AgendaAgenda
 Test Design
 The Four step process
 Test Cases
 Types of Test Cases
 Test Case Categories
 Bad Vs. Good Test Cases
 Guidelines
 Test Case Development Techniques
 Which Test Cases to Automate?
 Test Coverage
 Requirement Traceability Matrix (RTM)

4. 4
Test Design
 Test Design aims at documenting “How” to do testing.
 Ensure that all requirements are met in the application.
Steps for Test Design

5. 5
Test Design (Cont.)
 Test design should start the moment the requirements have been approved and
baselined.
 In case of functionality testing (Black box testing), it is necessary for team
members to acquire knowledge of functionality of application before team starts with
Test Design activity.
 Test Design Specification Template : (IEEE 829-1998)
 Features to be Tested
 Testing approach
 Test identification
 Test environment
 Overall Pass/Fail criteria

6. 6
Test Scenario
 Test scenarios are the high level classification of test requirement grouped depending on
the functionality of a module or what need to test at high level.
 One liner statements which tell us about what to test (Best practice).
 A test scenario has many test cases associated with it.
 How to identify Test scenarios?
1) From Use cases
2) Functionality breakdown
3) Using state transition technique.
 It’s more about thinking and discussing details while in Test Cases its about Documenting
details.
 Importance : It’s important when time is less and most of the team members can agree /
understand the details from one-liner scenario.

7. 7
Test Scenario Template

8. 8
The Four step process
I) Analyze the Test Basis
 Study the test basis which is anything by which
you can base your test e.g. business process, test
requirements, User guide, design specs or
interview business owner.
 Evaluate testability, assess the risks & prioritize.
 Example: Online order will be processed on
the next working day. Payment must be made by
standard credit card. order will be mailed within 2
days. If a partial order must be sent the customer
will be notified & can return their order within 30
days for full refund.
II) Prioritize
- Always done WITH Business Analyst
Business :
- How important this process is for business
- If this process fails then what are customers going
to do.
Complex:
- Does it take lots of screens to get through this
process?
- Does it integrate with other app?
Failure:
- Is this a process that may fail when I am going to
test it? If yes then its impact.
- What's the anticipated failure rate?

9. 9
III) Identify the Test Conditions
 Can be many conditions for each
Function/process.
 Include:
 high level conditions (very useful for business)
 low level conditions (will not used that frequently)
 Example :
These are three Test condition:
Place an order on a weekdays.
Place an order on a weekend.
Return a partial order.

10. 10
IV) Design Test Cases
 Prioritize test cases :
Preconditions
Inputs
Outputs
Expected Result
Specified the Test Cases

11. 11
What is test case?
 A test case is a document, which has a set of test data, preconditions, expected
results and Actual results, developed for a particular test scenario in order to verify
any requirement.
 Test Case acts as the starting point for the test execution, and after applying a set of
input Test Data, the application has a definitive outcome.
 Five required elements of a Test Case:
 ID – unique identifier of a test case
 Objective / steps / Test Data – what you need to do
 Expected result – what you are supposed to get from application
 Actual Result – What output actually application provides after testing
 Status – Pass/fail

12. 12
Types of Test Cases
 Test Cases categories:
Positive Test Cases
Negative Test Cases
Test Case Types comes under these categories:
Functional Test Cases
Performance Test Cases
Security Test Cases
Integration Test Cases
Database Test Cases
Usability Test Cases
Acceptance Test Cases
Happy Path Test Cases

13. 13
Test Case Categories
 Positive Test Cases:
 Performed on the system by providing the valid
data as input.
 Checks whether an application behaves as expected
with the positive input.
 Negative Test Cases:
 Performed on the system by providing invalid data
as input.
 Checks whether an application behaves as expected
with the negative input.
 This is to test the application that does not do
anything that it is not supposed to do so.

14. 14
Test Case
 Inputs:
 Through the UI
 From interfacing systems or devices
 Files
 Databases
 State
 Environment.
 Outputs:
 To UI
 To interfacing systems or devices
 Files
 Databases
 State
 Response time.

15. 15
Test case of Login module
 Check Login box below:

16. 16
Bad Test Cases

17. 17
Good Test Case

18. Guidelines for better Test Cases
 Test Cases steps should be as detailed as
possible and should not be written at high
level.
 Writing detailed test steps is very
important considering the fact that the same
person who wrote the test cases may not
always execute the same test cases.
 If the test cases are not very detailed then
the person who executes the test case for the
first time will not be able to validate the
system thoroughly as he/she might have not
gone through the requirements and will test
only as per the test case steps.
 Ensure that all positive scenarios and
negative scenarios are covered.
Language:
 Write in simple and easy to understand
language.
 Use active voice: Do this, do that.
 Use exact and consistent names (of
forms, fields, etc).
 Remove conditional words.
Characteristics of a good test case:
 Accurate: Exacts the purpose.
 Economical: No unnecessary steps or
words.
 Traceable: Capable of being traced to
requirements.
 Repeatable: Can be used to perform
the test over and over.
 Reusable: Can be reused if necessary.

19. 19
Guidelines (cont.)
 It is very important for a Tester to draft good and complete test cases as it shows
how comprehensively a test engineer has understood the application requirements.
 Do’s and Don’ts to write effective test cases with little efforts and save a lot of time.
Do’s:
Identify and draft test cases for each unit or component or module
Write test cases with all the mandatory fields such as test case ID, priority,
description, execution steps, expected result and actual result
Focus on functional as well as UI aspects
Write execution steps in points so that the steps are clearly readable
Clearly identify the expected results for each test case
Design the test cases as per the workflow of the application

20. 20
Guidelines (cont.)
Don’ts:
Do not write repetitive UI test cases. This will lead to high maintenance since UI will
evolve over time.
Do not concentrate on negative paths for user acceptance test cases if the business
requirements clearly indicate the application behavior and usage by the business users.
Do not fail to get the test cases reviewed by individual module owners of the
development team. This will enable the entire team to be in the same line.
Do not leave any functionality uncovered in the test cases until and unless it is
specified in the test plan.
Do not write test cases on assumptions. If the requirement is not clear ask
development team/business analyst.
Do not write test cases on error messages based on assumptions. Document error
message validation test cases if the exact error message to be displayed is given in the
requirements.

21. 21
Test Case (cont.)
 Construction of Test Cases also helps in:
Finding issues or gaps in the requirements.
Technical design itself.
Make tester to think through different possible Positive and Negative
scenarios.
It is test cases against which tester will verify the application is working as
expected.
Number of test cases to be created depends on the size, complexity and type
of testing being performed.
Gives an approach, Description, Pre-conditions to achieve the expected
result
Useful while writing Traceability Matrix.

22. 22
Test Data
 Test data is the data that is used while testing of an application.
 In order to test a software application you need to enter some data for testing most
of the features. Any such specifically identified data which is used in tests is known as
test data.
 Effectiveness of Test Cases is depends on the use of correct Test Data while testing.
 Two types :
 Positive Test Data.
 Negative Test Data.
 Test data can be made available in two ways:
 Simulated - Data derived by considering Requirements.
 Provided by client- data copied from Live DB [e.g. csv file].

23. 23
Test Data (Cont.)
 Always verify the test data before re-using in regression testing.
 Design test data considering following categories:
 No data
 Valid data set
 Invalid data set
 Illegal data format
 Boundary Condition data set
 It is not possible to check test case with all data values, Testers need to ensure all
possible combination is covered so following techniques used:
 Equivalence Class Partitioning [ECP]
 Boundary Value Analysis [BVA]

24. 24
Test Case Development Techniques
 Boundary testing
 Equivalence classes
 Decision tables
 State transition diagrams
 Risk Analysis
Test Case Development Techniques are :

25. 25
Equivalence Class Partition
- It’s a black box test design technique.
Principle: test cases should be designed to cover
data of each partition at least once.
Problem: The circle accepts only Positive input
values ranging from 1-10 only .
Steps:
1)I) Identify equivalence classes, the input values
which are treated the same by the software divide
into 3 different class :
1) Valid class
2) Invalid Class
II) Create a test case for each equivalence class.
 III) While testing, use a single data from each
class.
 Advantage:
1. To reduce the number of test cases to a necessary
minimum.
2. To select correct test cases to cover all possible
scenarios.

26. 26
Boundary value testing
 It’s a black box test design technique in which
test cases are designed based on boundary values.
 Each input is tested at both ends of its valid
range(s) and just outside its valid range(s).
 Formula : (Low - 1, Low, High, High +
1)
 The focus is on one requirement at a time
 Can be combined across multiple requirements
– all valid minimums together, all valid
maximums together;
 Invalid values should not be combined.
 Limitations:
Does not work well for Boolean & Logical
variables.
Focus much on boundary & gives less attention
to other data scenarios.

27. 27
Decision table
 A good way to deal with a combination of inputs, which produce
different results.
 Also referred to as a 'cause-effect’ table.
 It helps reduce test effort in verifying each and every combinations
of test data, at the same time ensuring complete coverage
 Decision tables provide a systematic way of stating complex business
rules, which is useful for developers as well as for testers.

28. Decision table Example
Example: Let's consider the behavior of Flight
Button for different combinations of Fly From &
Fly To.
Rule 1:When destination for both Fly From &
Fly To are not set the Flight Icon is disabled. So
register values False.
Rule 2: When Fly From is set but Fly to is not
set, Flight button is disabled. So register True for
Fly from and the rest of the entries are false.
Rule 3: When Fly From is Not set but Fly to is
set, Flight button is disabled. So register True for
Fly from and the rest of the entries are false.
Rule 4: only when Fly to and Fly from
destinations are set, Flights button is enabled and
you make the corresponding entry in the decision
table.

29. 29
State transition diagrams
State transition: A transition between
two states of a component or system.
Identify a finite number of states the
model execution goes through
Create a state transition diagram
showing how the model transitions from
one state to the other
Assess the model accuracy by analyzing
the conditions under which a state change
occurs

30. 30
Risk Analysis :
 Who: PM, Tech Support, Sales, Engineers,
Testers.
 When: (design)/coding/testing stage(s).
 Why:
 It helps us choose the best test techniques
 It helps us define the extent of testing to be
carried out
 The higher the risk, the more focus given
 It allows for the prioritization of the testing
 Attempt to find the critical defects as early as
possible
 Are there any non-testing activities that can be
employed to reduce risk? e.g. provide training to
inexperienced personnel

31. 31
Which Test Cases to Automate?
 Test cases to be automated can be selected using the
following criterion :
High Risk - Business Critical test cases
Test cases that are executed repeatedly
Test Cases that are very tedious or difficult to perform
manually
Test Cases which are time consuming
The following category of test cases are not suitable for
automation:
Test Cases that are newly designed and not executed
manually atleast once
Test Cases for which the requirements are changing
frequently
Test cases which are executed on ad-hoc basis

32. 32
Test Coverage
 Measures the amount of testing performed by a set of test.
 100% coverage does NOT mean 100% tested.
 Benefit of Test coverage measurement:
It creates additional test cases to increase coverage
It helps in finding requirements that not exercised by a set of test cases
It helps in determining a quantitative measure of code coverage, which
indirectly measure the quality of the application or product.
 Drawback : it measures coverage of what has been written, i.e. the
requirements itself; it cannot cover the requirements that has not been
written.

33. 33
Requirement Traceability Matrix
(RTM)
 This is the document that connects the requirements to the test cases.
 The connection or mapping of the requirements to test cases is many-many.
 This means that one requirement is tested by one or more test cases.
Conversely, it is possible to have one test case addressing one or more
requirements.
 Allows two-way mapping between requirements and test cases :
 From a requirement to a functional specification to specific tests which
exercise the requirements
 From each test case back to the requirement and functional specifications
 A traceability matrix finds two applications:
 To identify and track the functional coverage of a test
 To identify which test cases must be exercised or updated when a system
evolves

34. 34
RTM Template

35. 35
Summary
 Deciding test cases during planning is the most important aspect of testing.
 At each testing, test cases should be specified, reviewed & then executed.
 There are many test case design methods that can be used if suitable.
 Selecting the right method makes it easier to detect faults.
 Coverage measured, test cases enhanced using coverage data.

36. 36
Q & A

37. Thank You!Thank You!
Software testers succeed where others fail.