-
Notifications
You must be signed in to change notification settings - Fork 15
Creating and maintaining E2E tests
This page is designed to explain and guide testers and developers on how to approach writing and maintaining E2E tests effectively.
- What are End-to-end Tests?
- Gather Requirements
- Add Tests in Azure Test Plan
- Writing E2E Tests
- Test Maintenance
"End-to-end testing is a technique that tests the entire software product from beginning to end to ensure the application flow behaves as expected. It defines the product’s system dependencies and ensures all integrated pieces work together as expected.
The main purpose of End-to-end (E2E) testing is to test from the end user’s experience by simulating real user scenarios and validating the system under test and its components for integration and data integrity."
To make the process of writing and maintaining test scenarios and automation scripts hassle-free, we should follow a specific process to ensure tests are written in the correct language and format.
Each test suite should be based on a set of requirements that ensures the quality of the feature. These requirements can be:
- Written by the product owner as acceptance criteria.
- Based on designs (e.g., Figma).
Once the requirements are clear, decide on the number of tests for both positive and negative scenarios, and write down the test titles.
Actions:
- Check with the product owner for acceptance criteria.
- List the titles of test cases that will cover the feature.
Before you start adding tests in Azure Test Plan, ensure that the relevant test suite is created within the test plan. You can create a test suite by:
- Clicking the three dots next to the relevant suite (if it already exists).
- Selecting “New Suite” > “Static Suite”.
- Giving it an appropriate name.

There are two modes for adding tests in Azure Test Plan:
- “Grid” Mode: Best for adding multiple tests at once.


- “New Test Case” Mode: Ideal for adding individual tests one at a time.

When adding test cases, ensure the following:
- Titles: Keep the title relevant and self-explanatory.
- Language: Write test scenarios in Gherkin language. This makes them more translatable to code and easier for testers to execute manually.
- State: Mark the test case as “Draft” when work is in progress and “Ready” when finalized for execution or automation.
- Tags: Always add relevant tags related to the feature or project.
- General Tags:
to be automated
,automated
,api
,k6
,manual
. - Project Tags:
Portalicious
,safaricom
,intersolve
, etc.
If an E2E test is going to be automated and relates to Portalicious, use tags like to be automated
and Portalicious
. Once automated, update the tag to automated
.

Example of tagging for k6 test:

- If adding test cases directly in Azure Test Plan, formatting issues are rare.
- If copying from external sources, such as a document with a dark background:
- Paste the content into a plain-text editor (e.g., Word, Pages).
- Remove any background colors.
- Adjust the text color for readability on both light and dark backgrounds (e.g., use blue like
#1175FF
).
When possible link test cases to relevant PBIs, Tasks, or Bugs.
You can do so in two different ways:
- From the test case: Attach the PBI under the “Tests” field.

- From the PBI: Attach the test case under “Tested by”.

This helps testers understand which tests to work on during feature implementation.
Most readers of this guide are likely familiar with writing automated tests. You can find more information here. However, one crucial point to emphasize is adding relevant Test IDs to test titles.
Why Add Test IDs?
- Makes it easier to locate and edit tests.
- Simplifies validation of scenarios in case of test failures.
- Facilitates generating test reports in Azure Test Plan.
test('[27493] Navigate to programme', async ({ page }) => {
const homePage = new HomePage(page);
await test.step('Should open PAs for registration', async () => {
await homePage.navigateToProgramme(NLRCProgram.titlePortal.en);
});
});
Keeping tests up-to-date is essential for a well-functioning testing process.
- Open the correct test suite.
- Open the test case.
- Edit the content as needed and save it.
- If a test case is no longer relevant:
- Delete it from the test suite.
- If automated, create a PR to remove the corresponding E2E test script.
- Select queries
- Work item type "Test Case" or "Test suite"
- Add additional clauses
- "Run query"
