# Creating Values

DoesQA allows you to pass data between steps, reuse results, and create flexible, data-driven tests. You can create and update values at various points during a test, depending on how and when the data is available.

## Ways to Create Values

Values can be created or updated in several ways:

### Test Level

Set values when configuring a test. These values are accessible across the entire test and are useful for static inputs like environment settings, usernames, or flags.

{% content-ref url="../test-steps/data/set-value" %}
[set-value](https://docs.does.qa/test-steps/data/set-value)
{% endcontent-ref %}

{% content-ref url="../test-steps/data/alias-value" %}
[alias-value](https://docs.does.qa/test-steps/data/alias-value)
{% endcontent-ref %}

### Store Element Nodes

Use any of the following nodes to extract and store data from the page during test execution:

* **Store Element Text** – Stores the visible text of an element
* **Store Element HTML** – Stores the full HTML content of an element
* **Store Element Value** – Stores the `value` property of an input element
* **Store Element Attribute** – Stores a specific attribute from an element (e.g. `href`, `src`, `data-*`)
* **Store Element Count** – Stores the number of elements matching a selector

{% content-ref url="../test-steps/data" %}
[data](https://docs.does.qa/test-steps/data)
{% endcontent-ref %}

These nodes are useful for capturing dynamic content such as order numbers, field values, attributes, or counting repeated elements like product tiles or list items.

### Value Store

Use the Value Store to manually define or update values. 

Supported data types:

* **Strings** – `"Hello, world!"`
* **Numbers** – `42`, `3.14`
* **Booleans** – `true`, `false`
* **Objects** – `{ "id": 123, "name": "Sample" }`

### Webhook Trigger

You can start a test run via a webhook and pass in values as part of the request body. These values can either:

* Create new values for use during the test
* Overwrite existing values defined at the test level

This is useful when starting tests from external systems like CI/CD pipelines, internal tools, or backend workflows.