0% found this document useful (0 votes)
8 views9 pages

Unit 2 1

The document discusses equivalence class testing as a technique to reduce the number of test cases needed to test software. It describes how to identify valid and invalid input classes, select representative test cases, consider boundary values and combinations of inputs, document and execute test cases, and iterate the testing process.

Uploaded by

Shilpa Gowda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views9 pages

Unit 2 1

The document discusses equivalence class testing as a technique to reduce the number of test cases needed to test software. It describes how to identify valid and invalid input classes, select representative test cases, consider boundary values and combinations of inputs, document and execute test cases, and iterate the testing process.

Uploaded by

Shilpa Gowda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

Unit-2 Software Testing GTET

Equivalence class testing


• Equivalence class testing is a technique used in software testing to group
inputs or conditions into classes that are considered equivalent or likely to
produce similar results.
• The goal is to reduce the number of test cases needed to effectively test the
software while still covering a wide range of scenarios.
• Start by identifying different classes of input data or conditions.
• For example, if you're testing a login form, you might have classes like
valid usernames, valid passwords, invalid usernames, and invalid
passwords.
• Choose one or more representative values from each equivalence class.

Advantages of equivalence class testing


1. Efficiency: It reduces the number of test cases needed while still ensuring
comprehensive coverage.
2. Simplicity: Simplifies the testing process by focusing on representative
values rather than testing every possible input.
3. Time-saving: Saves time by avoiding redundant tests, making testing
faster and more manageable.
4. Clarity: Helps testers and developers understand what inputs are being
tested and why, improving clarity in the testing process.

Types of equivalence class testing


1) Weak Normal Equivalence Class Testing.
2) Strong Normal Equivalence Class Testing.
3) Weak Robust Equivalence Class Testing.
4) Strong Robust Equivalence Class Testing.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Weak Normal Vs Strong Normal Equivalence Class Testing


Weak Normal Strong Normal

• In weak normal equivalence • Strong normal equivalence


class testing, only valid class testing also considers
equivalence classes are invalid equivalence classes in
considered. addition to valid ones.
• Each valid equivalence class is • It includes both valid and
represented by one test case. invalid equivalence classes in
• This technique aims to ensure the test cases.
that the system behaves correctly • Test cases are designed to verify
with valid inputs. how the system handles both
• It doesn't consider invalid or valid and invalid inputs.
boundary values. • It provides more thorough
• Easy to set up and run because coverage compared to weak
it's basic. normal equivalence class
• Doesn't explore tricky situations testing.
or wrong inputs. • Each type of input might have
• Doesn't take much time or effort multiple tests to check
to do. everything.
• It tests only valid inputs, making • improving the robustness of the
it quicker to design, execute, and software.
maintain. • Needs more time and effort
because it's more thorough and
detailed.
• It helps identify potential
weaknesses in the system by
testing its ability to handle
unexpected inputs.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Weak Robust Vs Strong Robust Equivalence Class Testing


Weak Robust Strong Robust
• In Weak Robust Equivalence Class • In Strong Robust Equivalence
Testing, test cases are designed to Class Testing, test cases are
include one invalid input value designed to include multiple
along with valid input values. • invalid input values along with
valid input values.
Weak testing catches surface-level
• Strong testing uncovers deeper
errors. • Weak testing aims to find
issues.
basic bugs. • Weak testing requires
• Strong testing aims to identify
fewer test cases.
potential implementation.
• Weak testing is simpler and
• Strong testing needs more test
quicker to implement.
cases to cover various scenarios.
• Weak testing reduce the impact • Strong testing is more complex and
basic risks. time-consuming.
• Weak testing checks how software • Strong testing reduce the impact
handles straightforward errors. more complex risks.
• Weak testing provides basic level • Strong testing assesses how
of confidence or certainty in the software handles a wider range of
quality, reliability. errors.
• Strong testing offers higher level of
confidence or certainty in the
quality, reliability of software
robustness.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Equivalence class testing


• Is a software testing technique that aims to reduce the number of test cases
by grouping input data into classes.
• where each class represents a set of valid or invalid inputs that should
produce similar results.

Guidelines for equivalence class testing


Identify input classes:

• Analyse the input parameters of the system under test and identify different
sets or ranges of input values that should produce the same behaviour.

Determine valid and invalid classes: • Divide the input classes into
two categories: valid and invalid.
• Valid equivalence classes represent inputs that the system should accept
and process correctly, while invalid equivalence classes represent inputs
that the system should reject or handle with error.

Select representative values:

• Choose representative values from each equivalence class to serve as test


cases.
• For example, if an input class represents ages between 18 and 65 for a
voting application, select values like 20, 35, and 60 to test.
Cover boundary values:

• Pay special attention to boundary values, which are the minimum and
maximum values for each input class.
• Test cases using these boundary values are more likely to expose errors
since boundaries are often where systems behave differently.

Consider combinations:

• If the system's behaviour depends on combinations of inputs, create test


cases that cover various combinations of equivalence classes.
• Use techniques like pairwise testing to ensure adequate coverage without
an excessive number of test cases.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Document test cases:

• Document the selected test cases, including the input values, expected
results, and any additional information necessary for executing the tests.
Execute tests:

• Execute the test cases against the system under test, observing the actual
behaviour and comparing it with the expected results.

Iterate and refine:

• Iterate: If differences or failures are found, iterate on the test cases to refine
them. This might involve adjusting the inputs, adding new test cases, or
modifying existing ones to better represent the equivalence classes.
• Refine: Refine the test cases based on the feedback and observations from
the previous iteration. This may include updating boundary values, adding
edge cases, or adjusting the representation of equivalence classes to
improve test coverage and effectiveness.

Automate where possible:

• Consider automating equivalence class test cases to increase efficiency and


repeatability, especially for regression testing purposes.
Monitor and maintain:

• As the system evolves, continue to monitor and update equivalence class


test cases to ensure they remain relevant and effective in verifying the
system's behaviour.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Decision table testing


• Decision table testing is a software testing technique used to test
system behaviour (how a software system or application responds
and behaves under various conditions or inputs) for different input
combinations.
• It is particularly useful for testing systems that involve complex
business logic or decision-making processes.
decision table has 4 parts

1. Condition Stubs : refer to the decided in advance states or conditions that


are assumed for testing purposes.
2. Action Stubs : They represent the predicted behaviour of the system
under test based on the input conditions provided.
3. Condition Entries : Refer to the various possible combinations of input
conditions that are analysed to determine the corresponding actions or
outcomes.
4. Action Entries : Represent the expected outcomes or actions
corresponding to the various combinations of input conditions specified
in the decision table.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Guidelines in decision table Based Testing


1) Identify Decision Rules: Clearly define the inputs (conditions) and outputs
(actions) of the system. These should represent the different factors that affect the
behaviour of the system and the corresponding actions it should take.
2)Create Decision Tables: Construct decision tables to represent the decision
rules in a tabular format. Decision tables typically have columns representing
input conditions and rows representing different combinations of conditions.
3)Identify Equivalence Classes: Group input conditions into equivalence
classes to ensure comprehensive test coverage. Equivalence classes are sets of
input values that should produce similar results when tested.
4)Generate Test Cases: Generate test cases based on the combinations of input
conditions defined in the decision table. Test cases should cover each combination
of conditions, including boundary values and invalid inputs.
5)Test Prioritization: Determining the order or sequence in which tests are
executed based on their importance.
• Which tests are most likely to uncover software issues or bugs that have a
severe impact on the functionality, usability, performance, or security of a
system?
6)Execute Test Cases: Execute the generated test cases against the system under
test. Record the actual outcomes or actions triggered by each test case for
comparison with the expected outcomes.
7)Analyse Results: Analyse the results of test execution to identify discrepancies
or deviations from expected behaviour. Document any failures or defects
encountered during testing.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Observations in decision table Based Testing


1. Comparison: Check if the system behaves as expected according to the
decision table.
2. Patterns: Look for any repeated behaviors or trends across different
inputs.
3. Edge Cases: situations at the extreme ends or boundaries of what's
expected or typical.
4. Errors: See how the system handles errors or unexpected situations.
5. Performance: Check how fast and efficient the system is under different
conditions.
6. Changes: Watch out for any unintended changes in behavior due to recent
updates.
7. Record: Write down everything you observe for storing information.
8. Understand Why: Figure out why any issues or situations where
unexpected.
9. Learn and Improve: Use what you've observed to make testing better next
time.

Data flow testing


• Data flow testing is a software testing technique that focuses on the flow
of data within a program.
• This technique checks whether a variable is properly defined before
being used.
• This technique aims to test all possible paths that data can take through
the program.
• Data flow testing helps uncover errors related to data manipulation and
flow, which might not be apparent through other testing techniques.

BCA 6th Sem basu.


Unit-2 Software Testing GTET

Slice-Based Testing
• Slice-based testing is a method where instead of testing the entire
software at once, it's divided into smaller parts, called slices, and each
slice is tested individually.
• The software is split into smaller parts or slices, usually based on
functionality or modules.
• Each slice is tested separately to ensure it works correctly on its own.
• This approach makes testing more manageable, speeds up feedback,
allows parallel testing, and improves overall test coverage.
• In essence, slice-based testing simplifies testing by breaking down the
software into smaller, testable units, leading to better quality and
efficiency in the testing process.

Guidelines and Observations for Slice-Based Testing


• Clear Definition: Clearly define slices based on functionality or
modules.
• Independence: Ensure each slice can be tested separately.
• Priority Testing: Start with critical or complex slices to mitigate risks
early.
• Iterative Testing: Test slices incrementally, integrating and retesting as
needed.
• Feedback Loop: Maintain communication between testing and
development teams for prompt issue resolution.
• Automation: Automate testing processes to increase efficiency.
• Integration Testing: Conduct comprehensive integration testing to
validate interactions between slices.
• Traceability: Maintain traceability between slices, tests, and
requirements.
• Adaptability: Monitor progress and adapt strategies based on feedback
and observations.
• Documentation: Document testing processes and results for
knowledge sharing and compliance.

BCA 6th Sem basu.

You might also like