Software

Testing

Instructor: Syed Areeb Jafri

AGENDA

01 Test Documentation

02 Test Scenario v Test Case v Use Case

03 Test Cases Development

Discussion
Document Type Description
- Definition: A high-level document outlining the organization's testing philosophy and principles.
- Purpose: Ensures a standardized and consistent testing approach across the organization. Aligns
testing objectives with business goals.
Test Policy - Key Components:
- Testing goals and objectives
- Principles and methodology
- Alignment with business processes and quality standards.
- Definition: A high-level document outlining the overall testing approach for the project.
- Purpose: Defines testing scope, objectives, methods, and tools. Ensures that testing efforts are
aligned with project goals.
Test Strategy - Key Components:
- Risk analysis and mitigation plan
- Test levels (unit, integration, system, acceptance)
- Testing tools and environments.
- Definition: A detailed document that outlines the testing activities, schedule, and resources.
- Purpose: Provides a roadmap for the testing process and ensures all stakeholders are aligned.
- Key Components:
Test Plan - Test scope (what will and won’t be tested)
- Resources (people, tools, environments)
- Schedule and milestones
- Entry and exit criteria
- Test deliverables.
Document Type Description
- Definition: A document that links test cases to specific requirements to ensure full coverage.
Requirements - Purpose: Tracks the implementation and validation of each requirement during testing, ensuring no
requirement is missed.
Traceability - Key Components:
Matrix (RTM) - Mapping of requirements to test cases
- Status tracking for each requirement
- Traceability across testing phases.
- Definition: A high-level description of an event or functionality that will be tested.

- Purpose: Ensures the complete functionality of a system is covered by testing multiple scenarios.
Test Scenario - Key Components:
- Broad description of test objectives
- Coverage of key functionality or workflows
- Alignment with user stories or business processes.
- Definition: A detailed description of the steps to test a specific feature or functionality.

- Purpose: Verifies that the system behaves as expected under certain conditions.
- Key Components:
Test Case - Preconditions (setup needed before executing the test)
- Test inputs and execution steps
- Expected and actual results
- Postconditions (state after test execution).
Document Type Description
- Definition: The data used to execute a test case, ensuring realistic conditions during testing.
- Purpose: Validates that the software functions correctly with real-world data inputs.
- Key Components:
Test Data - Input data required for tests
- Data variations to test different scenarios
- Test data sources (databases, mock data).
- Definition: A document that records any defect found during testing, along with detailed information.
- Purpose: Provides a clear record of flaws in the system to be fixed.
- Key Components:
- Defect ID and summary
Defect Report - Steps to reproduce
- Severity and priority
- Expected vs. actual results
- Attachments (screenshots, logs).
- Definition: A high-level document summarizing the results of the testing efforts.
- Purpose: Provides stakeholders with a clear picture of testing outcomes and the system’s quality.
- Key Components:
Test Summary - Overview of executed tests
Report - Pass/fail rates
- Defects summary
- Risk and issue assessment
- Conclusion and recommendations.
 Aspect Test Scenario Test Case Use Case
A description of how a user interacts with a
A high-level description of a situation or A detailed, step-by-step description to verify a system to achieve a specific goal or accomplish a
Definition functionality that needs to be tested. specific functionality or feature in the system. task.
Ensures the full coverage of a functionality or Describes how the system will be used by end
workflow by testing various situations and user Verifies the expected behavior of the system users to meet their goals, usually from a user
Purpose flows. under defined conditions. perspective.

High-level; focuses on what to test, without Low-level; focuses on how to test, specifying the Medium-level; focuses on how a system will be
Level of Detail getting into specific steps. exact steps, inputs, and expected outcomes. used from an end-user's perspective.

Test inputs
Preconditions Actor (user or external system)
Test objective Execution steps Preconditions
Coverage of key functionality Expected result Main flow and alternate flow
Components High-level description of interactions Actual result Postconditions
Focuses on specific features or functionalities
Focuses on the business scenarios or user within the system to ensure they work as Focuses on how the user will interact with the
Focus Area workflows that need to be validated. intended. system to accomplish their goal.
Actor: User
Steps: Enter valid username, enter valid Goal: Log into the system
Verify the login functionality with valid and invalid password, click login. Main Flow: User enters credentials and clicks
Example credentials. Expected result: Successful login. login.
Business analysts, product owners, and
QA engineers, test managers, and developers to QA engineers, test analysts, and testers during developers during requirement gathering and
Who Uses It ensure all key business scenarios are covered. the actual test execution phase. system design.

Provides coverage for multiple possible test cases, Produces detailed results, including pass/fail Helps define requirements and expectations for
Output ensuring the scenario is fully validated. status, for each specific case tested. system behavior from a user's perspective.

Relation to A Test Case is derived from a test scenario or a A Use Case can give rise to several test scenarios
Others A Test Scenario can contain multiple test cases. use case. or test cases.
Best Practices for writing good
Test Cases
1. Test Cases need to be simple and transparent: 7. Implement Testing Techniques
Create test cases that are as simple as possible. They must be clear and It’s not possible to check every possible condition in your software
concise as the author of the test case may not execute them. application. Software Testing techniques help you select a few test
Use assertive language like go to the home page, enter data, click on cases with the maximum possibility of finding a defect.
this and so on. This makes the understanding the test steps easy and • Boundary Value Analysis (BVA): As the name suggests it’s the
tests execution faster. technique that defines the testing of boundaries for a specified
2. Create Test Case with End User in Mind range of values.
• Equivalence Partition (EP): This technique partitions the range
The ultimate goal of any software project is to create test cases that
into equal parts/groups that tend to have the same behavior.
meet customer requirements and is easy to use and operate. A tester • State Transition Technique: This method is used when software
must create test cases keeping in mind the end user perspective behavior changes from one state to another following particular
action.
• Error Guessing Technique: This is guessing/anticipating the error
3. Avoid test case repetition. that may arise while doing manual testing. This is not a formal
Do not repeat test cases. If a test case is needed for executing some other method and takes advantages of a tester’s experience with the
test case, call the test case by its test case id in the pre-condition column application
4. Do not Assume
Do not assume functionality and features of your software application 8. Self-cleaning
while preparing test case. Stick to the Specification Documents. The test case you create must return the Test Environment to the
5. Ensure 100% Coverage
pre-test state and should not render the test environment
Make sure you write test cases to check all software requirements
unusable. This is especially true for configuration testing.
mentioned in the specification document. Use Traceability Matrix to
9. Repeatable and self-standing
ensure no functions/conditions is left untested. The test case should generate the same results every time no
6. Test Cases must be identifiable. matter who tests it
Name the test case id such that they are identified easily while tracking 10. Peer Review.
defects or identifying a software requirement at a later stage. 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.
While drafting a test case to include the following information
• The description of what requirement is being tested
• The explanation of how the system will be tested
• The test setup like a version of an application under test, software, data files, operating system, hardware, security access, physical or logical date,
time of day, prerequisites such as other tests and any other setup information pertinent to the requirements being tested
• Inputs and outputs or actions and expected results
• Any proofs or attachments
• Use active case language
• Test Case should not be more than 15 steps
• An automated test script is commented with inputs, purpose and expected results
• The setup offers an alternative to pre-requisite tests
• With other tests, it should be an incorrect business scenario order

Test Case Management Tools

Test management tools are the automation tools that help to manage and maintain the Test Cases. Main Features of a test case management tool are
1. For documenting Test Cases: With tools, you can expedite Test Case creation with use of templates
2. Execute the Test Case and Record the results: Test Case can be executed through the tools and results obtained can be easily recorded.
3. Automate the Defect Tracking: Failed tests are automatically linked to the bug tracker, which in turn can be assigned to the developers and can be tracked
by email notifications.
4. Traceability: Requirements, Test cases, Execution of Test cases are all interlinked through the tools, and each case can be traced to each other to check test
coverage.
5. Protecting Test Cases: Test cases should be reusable and should be protected from being lost or corrupted due to poor version control. Test Case
Management Tools offer features like
• Naming and numbering conventions
• Versioning
• Read-only storage
• Controlled access
• Off-site backup
Best practice to Achieve Test Documentation
• QA team needs to be involved in the initial phase of the project so that Test Documentation is created in parallel.
• Don’t just create and leave the document, but update whenever required.
• Use version control to manage and track your documents.
• Try to document what is needed for you to understand your work and what you will need to produce to your stakeholders.
• You should use a standard template for documentation like excel sheet or doc file.
• Store all your project related documents at a single location. It should be accessible to every team member for reference as well as to
update when needed.
• Not providing enough detail is also a common mistake while creating a test document.
Advantages of Test Documentation Disadvantages of Test Documentation
• The main reason behind creating test documentation is to either • The cost of the documentation may surpass its value as it is very
reduce or remove any uncertainties about the testing activities. time-consuming.
Helps you to remove ambiguity which often arises when it comes • Many times, it is written by people who can’t write well or who
to the allocation of tasks. don’t know the material.
• Documentation not only offers a systematic approach to software • Keeping track of changes requested by the client and updating
testing, but it also acts as training material to freshers in the corresponding documents is tiring.
software testing process. • Poor documentation directly reflects the quality of the product as
• It is also a good marketing & sales strategy to showcase Test a misunderstanding between the client and the organization can
Documentation to exhibit a mature testing process. occur.
• Test documentation helps you to offer a quality product to the
client within specific time limits.
• In Software Engineering, Test Documentation also helps to
configure or set-up the program through the configuration
document and operator manuals.
• Test documentation helps you to improve transparency with the
client.