Data Driven Testing in ContextQA: Reusable Elements, Profiles, and Environments

Session 3 of the ContextQA training moves past basic recording and into the building blocks that keep a real test suite stable and easy to maintain. The session walks through creating Jira tickets from a run, using reusable elements, setting up data driven testing, working with environments, and finally grouping everything into test suites and scheduled test plans. The thread running through all of it is simple. Plan your test cases so that a change in one place does not force you to rework everything.

This is an intermediate session. It assumes you already know how to log in, open the dashboard, and record a basic test case. If you are new, start with the earlier sessions first.

Recap: test cases, runs, and run details

The session opens with a quick recap of the dashboard. Inside a test case you see the test steps, with screenshots captured automatically for each step. Each test case has a run history. When a run passes, ContextQA shows the recorded video and the trace viewer, and it also shows where self-healing kicked in, which is one of the AI capabilities worth knowing about.

Open the run details to see the execution history, then open a specific execution to see what passed, what failed, and the logs. You can review network logs for the run. If a step fails, ContextQA tells you which step failed and where it could not verify, along with the error. This level of detail matters because as a tester you are the front face to the client, and you need to explain clearly where a problem is and why.

Connecting Jira and creating tickets

ContextQA can link with Jira so you can raise a bug or create a matching test case without leaving your run. Set up the connection once, then create tickets from any test case.

1. Open the settings icon and click on plugins.
2. Select the Jira plugin.
3. Enter the account URL, the username, and the API token, then save.
4. Go to the test case and choose the Jira option.
5. ContextQA writes the steps for the selected project. Open the advanced options to add a label, such as login.
6. Set the priority, for example high, then save to create the bug in Jira.

The ticket is created in Jira with all of the steps and the label you chose. There are two things you can link with Jira from a test case. You can create a bug, and you can create a matching test case.

Feature coverage and visibility through labels

Because every test case carries a label, ContextQA can show coverage by feature. Pick a label like login and you can see the related requirements, the test cases already created for it, and what the coverage looks like for that feature. Anyone can navigate from a requirement to its test cases and on to the individual steps.

This is the visibility that the session keeps returning to. ContextQA gives you the context of a bug, what the issue is and the evidence behind it, and it gives the company a picture of what has been tested for each feature. When a developer is working on login, they can see every scenario that needs to pass, which brings clarity for developers and product managers alike.

As you create everything within ContextQA and in Jira, you get a high level summary of the requirements, the test cases, and the test coverage for a feature, all linked together.

The browser extension: hover steps and locators

Some pages depend on hover behavior, where a class only appears when the mouse is over an element. Recording a hover normally adds a lot of noise to your steps. To handle this, ContextQA lets you add a hover step from the extension. It inserts a step beneath the current one with the correct locator, so you do not have to stop and restart recording, and the test case will not fail for a missing hover.

The extension also helps with locators directly. Right click an item and choose the ContextQA find locator option to see the XPath and other selectors. This is handy for debugging and for understanding how an element is identified before you save it.

Reusable elements

Elements are the saved locators, also called page objects, that your test cases point to. ContextQA treats them as a low code and no code abstraction, so you do not have to manage raw XPath. If a button stops working, you re-record or edit that one element rather than every test case that uses it.

A smart way to use elements is to build them while developers are still working. The session suggests this flow.

1. Write your test cases in plain English, for example click on search, enter a value, press enter.
2. Add the elements you will need. Give each one a name, such as global search, and a screen name.
3. If the developer has not finished, save a placeholder value for the locator so the structure is in place.
4. When the real locator is ready, open the element and update the value. Nothing else has to change.

With placeholders in place, you can run a test case immediately. If a locator is wrong, the run fails on that step and tells you the element was not found and to record the step again. The point is that you match the pace of development. You do the planning and the structure now, and when the team is ready you only re-record the selectors, nothing more.

Data driven testing with test data profiles

Data driven testing runs one test case against many sets of data, such as correct username with wrong password, wrong username with correct password, and so on. Instead of repeating the work many times, you store the data once and loop over it.

1. Create a test data profile and give it a name.
2. Add rows and columns for the values you want, for example a username column with several users.
3. In the test case, add a loop over the profile, from the first row to the last.
4. In the relevant step, select the parameter so the value is pulled from the profile rather than typed in.

When you run it, the test case executes once for each row and validates every combination. You can reorder steps if the loop and the parameter steps need to sit in a different order. Support for uploading data from a spreadsheet is planned and will follow customer requirements.

Environments, test suites, and test plans

Environments are another way to avoid hard coded values, but they hold settings rather than test data. A common case is when several people run the same test case with their own credentials. Create an environment, add the username and password, and save it. In a test step, instead of typing a password, pull it from the environment variable. When you run the test case, you choose which environment to use.

A test suite is simply a group of related test cases. Create a suite, search for the test cases you want, for example all of the login cases, select them, and save. Suites let you run one feature at a time, so developers are not waiting on thousands of cases when only twenty or thirty are relevant.

A test plan brings it all together. It runs one or more suites against the devices and environments your customer asked for.

1. Create a test plan and name it, for example a login module plan.
2. Add a test suite, then check the box to open the device window.
3. Select the browsers and devices, for example Firefox and Safari, and name each configuration.
4. On the next step, choose the environment to run against.
5. Create the plan, and optionally set a schedule so it runs overnight or at a set time.

The results appear under the run results, grouped by test plan. A standalone test case or suite runs under the default plan on Chrome, while a test plan runs against everything you selected and shows a separate pass or fail for each browser. Because the plan runs on ContextQA infrastructure, you get your own pipeline with scheduling and environments, without setting up or maintaining test machines yourself.

Next steps

After this session you have the core skills to take on a web application project in ContextQA. Practice is the assignment. Set up the Jira plugin and raise a ticket from a run. Build a few reusable elements with placeholders. Create a data profile and loop a test case over it. Add an environment, group cases into a suite, and run a small test plan across two browsers.

Two topics are held for a later session, mobile application testing and a deeper look at test plans, scheduling, and CI and CD integration. Once those are covered you will have a complete view of the tool. For now, work through the steps above against a real website and bring your questions to the next session.