DEV Community: PerfectQA Testing Company

How to Do IoT Test Automation: A 7-Step Process

PerfectQA Testing Company — Thu, 20 Aug 2026 06:01:04 +0000

IoT testing involves more than checking whether a device works. Connected products depend on hardware, firmware, networks, cloud services, and applications working together. Without a structured approach, automation can quickly become difficult to maintain and may miss important device-specific failures.

A practical IoT test automation process can be organized into seven steps.

1. Map the Device and Firmware Matrix

Start by identifying the hardware revisions, firmware versions, and network conditions that need to be tested. This gives the team a clear view of the environments the product must support.

Testing only one device or firmware version can leave important compatibility issues undetected.

2. Decide What to Automate First

Not every test needs to be automated immediately. Begin with stable and repeatable interfaces, such as API contracts and protocol validation, before moving into more complex device and application scenarios.

Some activities, including initial hardware setup and physical usability checks, may still require manual testing.

3. Set Up the Test Environment

A strong IoT test environment usually combines simulated devices with real hardware.

Simulators provide the scale needed for fleet-level testing and allow teams to reproduce network conditions such as latency or packet loss. Real devices are important for validating physical behavior that simulations cannot fully reproduce.

4. Assemble the Automation Framework

Build the framework around the major components of the IoT system. Device simulation, protocol handling, API validation, CI/CD integration, and test reporting should work together as one pipeline.

A modular framework also makes it easier to replace or improve individual components as the product evolves.

5. Write Device-Aware Assertions

This is one of the most important steps in IoT automation. A successful API response does not always mean the device completed the requested action.

For example, receiving an HTTP 200 response for a print request only confirms that the server accepted the request. The test should verify the actual device status or completion event.

6. Connect Tests to CI/CD

Automation becomes much more valuable when tests run automatically with development changes. Firmware updates can trigger device and protocol tests, while application changes can trigger relevant API and application suites.

Nightly runs can cover the broader device and firmware matrix.

7. Turn Field Failures Into Regression Tests

Real-world failures provide valuable test scenarios. When a device disconnects, fails after a power cycle, or behaves unexpectedly under certain network conditions, reproduce that scenario and add it to the automated suite.

This keeps the test suite growing around actual product risks rather than only planned test cases.

Conclusion

IoT test automation works best when it is built as a continuous process rather than a one-time automation project. Mapping the device matrix, prioritizing stable tests, combining simulation with real hardware, and connecting automation to CI/CD creates a stronger foundation for reliable testing.

Most importantly, field failures should feed back into the suite so that once a problem is fixed, the same issue is less likely to return.

Salesforce API Connection Testing: A Practical Troubleshooting Guide

PerfectQA Testing Company — Wed, 12 Aug 2026 13:27:09 +0000

A successful Salesforce login proves only that authentication worked. A usable API connection also needs to reach the correct org, use a valid instance URL, access the required objects, and perform the operations your integration depends on.
The safest way to test a connection is to move from a harmless authenticated request to resource-level access, then test write operations only when the integration actually needs them.

What You Need Before Testing the Connection

Start with the Salesforce org you intend to test, an API user with the required access, and an OAuth configuration for authentication. Salesforce uses OAuth access tokens to authorise API requests, with current documentation directing new integrations toward External Client Apps for OAuth configuration.
You should also know which Salesforce API your integration uses and which objects or resources it needs. A connection that reaches one endpoint may still fail when it tries to access an object the authenticated user cannot use.
Use a supported Salesforce API version throughout the test. Salesforce currently supports Platform API versions 31.0 through 67.0; REST requests made against retired versions return 410 GONE.

Step 1: Authenticate and Capture the Instance URL

OAuth authentication returns an access token to send with subsequent Salesforce API requests. In Postman, the token details also show the instance_url associated with the org you authenticated against. Salesforce's Trailhead instructions tell users to copy this value and use it as the endpoint for later requests, since it identifies the environment your requests should reach. Reusing a hardcoded endpoint from another sandbox, Developer Edition org, or production environment can send the request to the wrong place.
At this stage, an authentication failure usually points to the OAuth configuration, credentials, login settings, or application access, not the business logic of the request itself.

Step 2: Send a Low-Risk Connection Request

A read-only request gives you a cleaner first connection test than immediately creating or updating data:
GET/services/data/vXX.X/limits
Salesforce recommends the Limits resource as an easy way to test an authentication token, and its own Postman Trailhead exercise uses this same GET Limits call as its quick connection test, expecting a 200 OK response.
A successful response confirms the token is valid, the org is reachable, and the request can access the REST API. It does not confirm the integration has permission to use every object or operation it needs; that's the next step.

Step 3: Test the Salesforce Resources Your Integration Uses

Authentication alone doesn't prove an integration can reach Accounts, Contacts, Opportunities, custom objects, or other resources involved in its workflow.
A useful next step is an object-level request such as:
GET /services/data/vXX.X/sobjects/Account/describe
The Describe resource returns metadata for the selected object, including its fields and relationships. Replace Account with the actual standard or custom object your integration uses, rather than relying only on tutorial examples.
From there, send a small SOQL query or retrieve a known test record to check whether the authenticated user can access the data the integration expects. Salesforce's Query resource supports SOQL requests against data available to the org and user. Once basic object access is confirmed, broader CRUD scenarios, request validation, negative tests, and response assertions are covered in more depth in this Salesforce API testing guide.

Step 4: Test Write Access Only When You Need It

Create, update, and delete requests should come after basic connectivity and read access have worked.
For an integration that writes Salesforce data, use a controlled record in a sandbox or other appropriate test environment: create the record, capture its returned ID, retrieve it to inspect the saved values, update it if the workflow requires that, and remove the test data afterward.
Salesforce's sObject REST resources support creating, retrieving, updating, and deleting individual records. Keeping these operations separate from the initial connection check makes troubleshooting easier, since you already know authentication and basic API access are working.

What Different API Failures Usually Mean

The HTTP response helps narrow down which part of the connection needs attention.
400 Bad Request: The request itself is invalid or contains data Salesforce cannot process. Inspect the endpoint, IDs, parameters, and request body.
401 Unauthorized: The OAuth token or session is invalid or expired. Obtain a valid token before retrying.
403 Forbidden: Salesforce received the request but refused access. User permissions or access to the requested resource may be the problem.
404 Not Found: The requested resource cannot be found or has been removed. Review the resource path, object name, record ID, and endpoint.
410 Gone: The requested REST resource or API version has been retired. Move the integration to a currently supported version.
The response body matters as much as the status code. Salesforce includes error information that can identify the affected resource or field, so avoid troubleshooting from the HTTP code alone.

Keep Sandbox and Production Connections Separate

Tokens, instance URLs, users, permissions, and data all belong to the Salesforce org where authentication occurred. A token obtained for a sandbox should stay with that sandbox configuration rather than being mixed into production requests.
Environment variables in Postman or your automation framework are a simple way to separate credentials, instance URLs, API versions, and test data between environments. Salesforce's own Postman guidance uses environment-specific login and instance URL values for this reason.

Conclusion

A useful Salesforce API connection test goes beyond one successful response. Authenticate first, send a harmless request such as GET Limits, test access to the actual Salesforce objects your integration needs, and add write operations only when the workflow requires them. This sequence makes failures easier to isolate before the integration moves into broader functional or regression testing.

How to Keep Selenium Tests From Becoming Flaky

PerfectQA Testing Company — Thu, 06 Aug 2026 08:47:52 +0000

A flaky Selenium test is one that passes and fails inconsistently without any change to the code being tested. Run it ten times and it might fail twice for no clear reason. Over time, these random failures quietly erode trust in test automation teams and start ignoring red builds, re-running suites "just in case," or disabling tests altogether instead of trusting the results.

What Causes Flaky Tests in Selenium?

Most flakiness traces back to a handful of recurring issues. Timing and synchronization problems top the list tests interact with elements before the page has finished loading.

Dynamic elements and unstable locators (like auto-generated IDs or layout-dependent XPath) break easily when the DOM shifts slightly. Shared test data and test-order dependency cause tests to pass or fail depending on what ran before them.

Environment differences between browser or WebDriver versions between CI and local machines introduce inconsistency, and running suites in parallel can create race conditions that only show up under load. Network latency or unstable third-party services add another layer of unpredictability outside the test's control.

How to Avoid Flaky Tests in Selenium

Fixing flaky tests comes down to a handful of deliberate habits rather than one silver-bullet fix. Follow these steps to build a Selenium suite that behaves the same way every time it runs.

Step 1: Use Explicit Waits, Not Fixed Delays

Thread.sleep() is one of the most common causes of flaky tests because it waits a fixed amount of time regardless of what the page is actually doing, too short and the element isn't ready, too long and the suite slows down unnecessarily.

Explicit waits (like WebDriverWait combined with ExpectedConditions) instead wait for a specific condition visibility, clickability, or presence before proceeding.
Avoid mixing implicit and explicit waits in the same test, since Selenium's behavior when both are set becomes unpredictable.

Step 2: Use Stable, Unique Locators

Locators tied to page layout, such as absolute XPath, break the moment a developer tweaks the markup. Prefer unique IDs or dedicated data-test attributes that don't change with styling or structure.

Keeping locators separate from test logic (in a page object or constant file) also makes them easier to update in one place when the UI does change.

Stable locators are especially important in Selenium functional testing, where tests must repeatedly validate user-facing features across different builds.

Step 3: Keep Tests Independent

Each test should set up its own data and state rather than relying on a previous test having run first. Test-order dependency is a common source of flakiness in CI, where execution order isn't always guaranteed. Clean up any data a test creates so it doesn't affect later runs.

Step 4: Handle Dynamic Elements Properly

Wait for AJAX calls, loading spinners, or animations to finish before interacting with an element. Locate elements as close as possible to the moment you interact with them, rather than storing a reference early and reusing it this reduces StaleElementReferenceException errors when the DOM re-renders.

Step 5: Keep Environments Consistent

Mismatched browser and WebDriver versions between local machines and CI pipelines are a frequent, easily overlooked cause of flakiness. Pin versions where possible, and keep test data and external dependencies (like staging APIs) as consistent as the environment itself.

Step 6: Use Retries as a Signal, Not a Fix

Retrying a failed test can help confirm whether a failure is truly intermittent, but retries should never be used to mask an unresolved problem. Log failures with screenshots and stack traces so patterns become visible over time. A test that only passes on retry is telling you something worth investigating, not something to ignore.

Flaky Tests vs. Brittle Tests

Flaky and brittle tests are often used interchangeably, but they point to different problems with different fixes. Knowing which one you're dealing with saves time chasing the wrong root cause.

Flaky Test

Behavior: Passes and fails inconsistently
Trigger: No code changes needed to see it fail
Root cause: Usually timing or environment issues
Fix approach: Stabilize waits, environment, test isolation

Brittle Test

Behavior: Fails consistently and predictably
Trigger: Fails whenever the application changes
Root cause: Usually an overly specific locator or tight coupling to implementation
Fix approach: Loosen locators, decouple from implementation details

Conclusion

Flaky Selenium tests are rarely caused by one single issue; they're usually the result of timing gaps, unstable locators, and tests that aren't truly independent. Explicit waits, stable locators, and isolated test design fix the underlying problems rather than papering over them with retries. A reliable suite is one the team can actually trust.

FAQs

1. What is the main cause of flaky Selenium tests?

Timing and synchronization issues interacting with elements before the page or its content has fully loaded.

2. How do explicit waits reduce Selenium test failures?

They pause execution only until a specific condition is met, instead of a fixed delay, so tests proceed exactly when the element is ready.

3. Should flaky Selenium tests be retried?

Retries can help confirm a failure is intermittent, but they shouldn't replace fixing the actual root cause.