Separate from production
The sandbox runs the change without affecting operational systems.
Sandboxes and QA
Test the software before merging
DevSense runs changes in an environment separate from production. Review the result, inspect the tests and check how it works before merging.
The video could not be played. Try opening it again.
Ready to review the result
DevSense sets up your private test environment
DevSense deploys and configures a private environment so you can test changes before merging them (sandbox).
Your team defines the intent, reviews the requirement and accepts delivery. During technical preparation, intervention is limited to infrastructure, network, billing or system blockers that need the relevant owner.
Test environments
An environment for each change
Each change has its own sandbox. Your team opens it in the browser from the platform and explores the result before deciding whether to merge.
Private, with role-based access
Only you and your authorized groups can view and access the test environment. DevSense enforces role-based access control (RBAC).
Available for review
The environment remains available after execution and is released when no longer in use.
QA process
How each change is validated
Assess software behavior against the approved acceptance criteria, with visible results and supporting evidence.
Acceptance criteria
The business outcomes agreed for the change.
Functional behavior
Results for the application interfaces included in scope.
Access requirements
Checks for the identities and permissions required by the project.
Test evidence
Results and supporting information for delivery assessment.
Test types
Web, API, database and command line
A project can combine several test types. Select an option to see what is validated and how the result is checked.
Web applications
Test workflows in a real browser
Navigates screens, fills in forms and checks visible behavior. When scope requires it, uses different identities to verify roles and access between users.
- What it checks
- Navigation, actions, results and permissions based on the change criteria.
- What you can review
- Check results, screenshots and available session recordings.
- Sign in
- Follow the workflow
- Check the result
Services and endpoints
Check responses and the effects of each operation
Sends requests to the project's API and compares results with expectations. It can check authorized and anonymous access, boundaries between users and repeated operations, according to the defined scope.
- What it checks
- Method, status code, headers, content and resulting changes.
- What you can review
- Requests, responses and observations supporting each result.
- Send the request
- Observe the response
- Verify its effects
Data and persistence
Verify data and its constraints
Queries and modifies data in the test environment when the scenario requires it. Checks that operations produce the expected state and constraints reject invalid data.
- What it checks
- Integrity, relationships, uniqueness, required values and migrations within scope.
- What you can review
- Executed queries, observed results and consistency checks.
- Prepare test data
- Perform the operation
- Verify integrity
Command-line tools
Test commands, output and repeated execution
Runs the commands and options defined in the scenario. Checks successful results and error responses; when required, verifies that repeating an operation does not duplicate its effects.
- What it checks
- Arguments, options, exit code and standard output or error messages.
- What you can review
- Executed commands and results to compare against expectations.
- Run the command
- Collect output and errors
- Compare the result
QA in the platform
Choose what to validate and follow the test
Choose the scenarios and interfaces to check. Follow the validation live or run it in the background, then review its results.
Test access
Authentication and permissions during testing
DevSense prepares test authentication using the project’s authorized identities and access. It can validate multiple users and roles when the requirement calls for it.
Login form
Username and password sign-in for the web application.
Bearer token
Access through a token associated with the test identity.
API key
Authenticated requests using the key and mechanism defined by your service.
JWT
Sign-in against the authentication service and use of the returned token.
Delivery integrity
Tests run on the version being delivered
The evidence corresponds to the software delivered, so your team can assess the result and approve integration.
Defects and external conditions
What DevSense resolves and when your team intervenes
When testing reveals a software defect, DevSense investigates, corrects and checks again. Your team does not have to direct each repair.
If a test account or access to an external service is missing, DevSense requests that prerequisite. A test that could not run remains pending; it is not marked as passed.
How work continuesTest not completed
The record preserves the result and cause.
What prevents progress?
Software defect
DevSense corrects
Investigates the implementation and repeats review and tests.
External access or resource
The owner enables access
Provides the access or resource DevSense cannot obtain.
Evaluate DevSense in your organization
Review the platform with a representative project and agreed acceptance criteria.