Quality Assurance is often associated with software testing itself, nothing more. In practice, quality assurance should encompass so much more than just testing. A key component of quality assurance is the practice of writing test cases, which are essential for ensuring software products work as intended and that all parties on on the same page as to what is being developed and tested.
Today we’ll cover the basics of test cases, from why they are important to how to write them effectively.
What Are Test Cases?
Test cases are written sets of conditions, variables, and expected results designed to confirm software functionality. They act as scripts for QA testing and help product and development teams ensure acceptance criteria are covered during testing.
Test cases are often first seen during new feature shaping, where the QA team will take the user scenarios developed by the product team and build out the steps taken for each scenario.
Quite often, time is not taken to write test cases because QA has not been pulled upstream and is not given the time to write test cases or test cases are deemed unnecessary because the user scenario acceptance criteria should be enough for QA and Dev to know what the expected user behavior is.
Why Are Test Cases Important?
Test cases have multiple benefits: they document what has been tested, ensure comprehensive test coverage, and keep stakeholders informed about what is being tested. Additionally, they serve as a communication tool between teams, facilitate efficient problem-solving, and contribute to product quality.
What Do Test Cases Do?
Ensure Comprehensive Testing: Test cases provide a step-by-step guide for testing, ensuring that each tester follows the same process. They verify coverage of all functionality and help prevent missed requirements.
Provide Clear Documentation: Test cases offer a written record of what will be tested and what has been tested. This clarity improves communication among product, development, and customer service teams, allowing for better tracking of potential issues in production.
Facilitate Communication: By clearly outlining QA's understanding of product requirements and user interactions, test cases foster collaboration between developers, testers, and product teams. Reviewing test cases often raises questions that may have been missed during planning, helping to align all parties.
Enhance Quality Assurance: Test cases ensure a consistent testing process, guiding testers on what and how to test. They also help identify potential issues before development begins, and document requirement coverage, allowing for quick identification of missing elements that could lead to defects.
Support Maintenance and Updates: A well-documented database of test cases enables the creation of regression test scripts, ensuring consistent and up-to-date regression testing.
Who Benefits from Well-Written Test Cases?
Testers: Clear test case instructions reduce ambiguity and errors in testing.
Developers: Test cases provide insights into edge cases and enable faster bug-fixing through detailed reports and a deeper understanding of issues.
Product Managers: Test cases offer assurance that requirements are met, facilitating better feature coverage and risk management.
Clients and Stakeholders: Test cases ensure a higher product quality and increased confidence in the products’ stability.
Customer Support: Test case documentation allows for better identification of customer issues, distinguishing bugs from configuration problems.
New Team Members: Onboarding becomes more accessible for new team members as test cases help them quickly understand the application and its functionality.
Components of a Good Test Case:
Test Description: A brief summary of the test case's purpose.
Preconditions: Any conditions that must be met before executing the test case.
Test Steps: A detailed, step-by-step guide to executing the test case.
Test Data: Any necessary input data for the test case.
Expected Result: The anticipated outcome of the test case.
Actual Result: The observed outcome after executing the test case.
Test Case Status: Indicates whether the test case passed, failed, or requires further investigation.
Best Practices for Writing Effective Test Cases
Single Test Goal: Each test case should focus on a single requirement that directly maps to the acceptance criteria of the story.
Clarity: Ensure that each step in a test case is clear enough for anyone in the team to follow, including new team members.
No Duplicate Steps: Avoid redundancy between test cases in terms of steps or validations.
Sub-Test Cases: Abstract common steps or navigations into separate sub-test cases and reference them in the main test cases.
Single Pass/Fail Reason: Each test case should pass or fail for a single reason, aligning with the primary objective.
Assumptions and Conditions: Document any assumptions, preconditions, and postconditions relevant to the test case.
Provide Test Data: Supply necessary test data within the test case description or specific test case steps.
Ensure Test Coverage: Include both functional and non-functional coverage.
Maintain Consistency: Use a standard syntax for all test cases. Here at LyonQA, we recommend Gherkin for its readable format and easy automation integration.
Regular Reviews and Updates: Update your test case database with additional coverage as the application evolves and remove outdated coverage.
Recommended Syntax:
We recommend using Gherkin, a structured and human-readable format for specifying test scenarios. In Test Driven Development the Arrange Act Assert syntax is often used, we recommend Gherkin with it’s Given When Then syntax as Gherkin is easier for the non-developer to understand, and shares keywords with BDD automation frameworks, ensuring automating manual test cases is frictionless.
As noted, Gherkin uses "Given," "When," "Then," and “And” keywords to structure test cases:
Given: Sets the system in a familiar state before user interaction.
When: Defines the user's actions. Multiple "When" statements can be included.
Then: Specifies the outcome after the "When" step. Multiple "Then" statements can be used.
And: Defines additional action steps or outcomes. While you can have multiple And statements within a test case, we recommend limiting the use of And
When writing test cases, we recommend using a format that defines the feature, testing scenario, test case, and test steps. For example:
Test Suite (Feature) | Test Scenario | Test Case | Actions | Results |
Login Functionality | Log in with valid email and password | As a user I can successfully log in to my account | ||
Given I am on the login page | ||||
And I’ve entered a valid email in the field | ||||
When I select the Continue button | ||||
Then I see a password field appear | ||||
And I see a Continue with password button appeared | ||||
When I’ve entered a valid password | ||||
And I select the Continue with password button | ||||
Then I see I am logged into my account |
Conclusion
In this post, we explored the importance of well-written test cases in the software development process, as well as how to write them.
Test cases not only ensure comprehensive testing and clear documentation but also facilitate communication between teams and enhance overall product quality. They do so by providing a structured approach to testing, they enable QA professionals to consistently deliver reliable and high-quality testing.
While some teams may skip writing test cases due to time constraints, investing in this process offers numerous long-term advantages for the entire organization. Even starting with high-priority scenarios can lead to improved testing outcomes and a better understanding of the application's functionality.
Incorporating well-documented test cases into a QA strategy will ultimately contribute to more successful product launches, increased customer satisfaction, and a more efficient and collaborative development process.
Comments