DEV Community: PerfectQA Testing Company

What Should a VAPT Certificate Contain?

PerfectQA Testing Company — Tue, 15 Sep 2026 13:04:39 +0000

A VAPT certificate should clearly show what was tested, when the assessment was completed, and which system or application the certificate applies to. This article covers the key details a reliable VAPT certificate should contain.

Organisation or Application Name

The certificate should clearly identify the company, product, website, application, API, or system that was tested.

This avoids confusion, especially when a business operates multiple applications or environments.
The name should match the actual scope of the assessment.

Tested Scope

The scope is one of the most important parts of a VAPT certificate.
It should clearly mention what was included in the security assessment, such as:
Web application
Mobile application
API
Server
Network
Cloud infrastructure
A certificate that only says "VAPT completed" without identifying the tested scope provides very little useful information.
For a broader understanding of certification, validity, and verification, you can read this detailed VAPT certificate guide.

Testing Dates

The certificate should mention when the assessment was conducted.
This helps the reader understand how recent the security testing is.
Testing dates are important because applications change frequently. New releases, architecture changes, integrations, or configuration updates can introduce new security risks after the assessment is completed.

Tested Environment

A good VAPT certificate should identify the environment that was assessed.
This may include:
Production
Staging
UAT
Test environment

This matters because testing a staging environment does not automatically mean the production environment has been assessed.
The certificate should make this distinction clear.

Application or Build Version

Where possible, the certificate should include the version or build that was tested.

This is especially important for frequently updated applications.
If a company receives a certificate for version 2.1 but has already released version 3.0 with major changes, the certificate may no longer accurately represent the current application.

Assessment and Closure Status

The certificate should indicate whether the security assessment was completed and whether identified vulnerabilities were addressed.

Depending on the provider, this may include information about:
Assessment completion
Retesting
Vulnerability closure
Remaining accepted risks
A certificate should not create the impression that no vulnerabilities ever existed. Its purpose is to show the status of the defined assessment.

Certificate or Reference Number

A unique certificate number or reference ID makes the document easier to verify and track.

This is useful for customers, auditors, procurement teams, and internal security teams that may need to confirm the certificate with the issuing provider.

Issuing Security Provider

The certificate should clearly name the company or security provider that conducted the assessment.

It should also contain enough information to identify the issuer.
A certificate without a clear issuing organisation is difficult to verify and may raise questions during security reviews.

Authorised Signature

An authorised signature, digital approval, or equivalent verification can help confirm that the certificate was formally issued.

The exact format can differ between providers, but the certificate should clearly indicate who approved or issued it.

Final Thoughts

A useful VAPT certificate should do more than state that testing was completed.

It should clearly identify the tested system, scope, environment, dates, version, assessment status, issuing provider, and verification details.

The more specific the certificate is, the easier it becomes for customers and security reviewers to understand exactly what was tested and what the certificate actually represents.

VAPT Cost by Asset Type: Web, API, Mobile, Network and Cloud

PerfectQA Testing Company — Fri, 11 Sep 2026 09:31:32 +0000

VAPT cost changes depending on what needs to be tested. A web application, API, mobile app, corporate network, and cloud environment each have different attack surfaces, security controls, and testing requirements.

That is why comparing VAPT prices without first defining the asset type can lead to misleading estimates.

Why Asset Type Affects VAPT Cost

Each type of digital asset exposes different security risks.
A web application may contain login systems, forms, payment workflows, and administrative panels. An API may expose hundreds of endpoints.

A mobile application can involve local device storage as well as backend services. Networks introduce servers, ports, firewalls, and internal systems, while cloud environments add identity permissions, storage configurations, and infrastructure controls.

The amount of testing required changes accordingly.
VAPT providers therefore evaluate the type of asset, its size, complexity, authentication requirements, and available documentation before determining the scope and price.

Web Application VAPT Cost

Web application VAPT is commonly used to assess customer portals, SaaS platforms, ecommerce websites, internal dashboards, and other browser-based applications.

The cost depends heavily on the size and functionality of the application.

A small application with a login, dashboard, and a few forms requires less testing than a platform containing payments, file uploads, account management, multiple integrations, and complex business workflows.

Testing may include areas such as authentication, session handling, input validation, access control, business logic, sensitive data exposure, and server-side vulnerabilities.

User roles also affect the scope. If an application has administrator, customer, vendor, and employee accounts, testers need to examine how permissions work between those roles.
More functionality generally means more test scenarios and greater manual effort.

API VAPT Cost

APIs often require a different approach because the attack surface is based on endpoints rather than visible pages.
An API assessment may involve authentication, authorization, request parameters, response data, rate limits, tokens, HTTP methods, and access between users.

The number of endpoints is therefore an important pricing factor.
Testing an API with 20 endpoints is significantly different from assessing a platform containing hundreds of endpoints spread across several services.

The complexity of those endpoints matters as well. APIs handling payments, personal information, administrative functions, or sensitive business data normally require deeper testing.

Documentation such as Swagger or OpenAPI files can also help define the scope before testing begins.

For a broader breakdown of these pricing variables, the full guide on VAPT testing cost explains how scope, complexity, asset type, and testing depth influence the final quote.

Mobile Application VAPT Cost

Mobile VAPT typically involves more than simply testing what appears on the phone screen.

A mobile application can include the Android or iOS application itself, backend APIs, authentication mechanisms, local storage, permissions, encryption, and communication with external services.

Testing may examine whether sensitive data is stored insecurely on the device, whether API requests are adequately protected, and whether authentication or authorization controls can be bypassed.
The required platforms also matter.

Testing only an Android application has a different scope from testing separate Android and iOS versions. If both apps use different functionality or platform-specific components, additional testing may be required.

Mobile VAPT pricing therefore depends on the application architecture rather than just the number of screens.

Network VAPT Cost

Network VAPT focuses on systems such as servers, IP addresses, routers, firewalls, VPNs, and exposed network services.

Pricing is often influenced by the number of IP addresses, devices, network segments, or systems included in the assessment.
There is also an important difference between external and internal network testing.

External assessments examine systems that can be reached from outside the organisation. Internal assessments look at what an attacker or compromised user might access after gaining entry to the internal network.

An organisation with a handful of internet-facing systems will usually have a smaller scope than a company operating multiple offices, servers, network segments, and internal services.
The number of assets and depth of testing therefore have a direct effect on cost.

Cloud VAPT Cost

Cloud security assessments can involve AWS, Microsoft Azure, Google Cloud, or other hosted environments.

The testing scope may include virtual machines, storage services, databases, APIs, networking rules, identity management, access permissions, and cloud configurations.

Cloud environments can become complicated because security depends not only on applications but also on how infrastructure and permissions are configured.

For example, testers may need to examine public storage exposure, excessive user privileges, insecure security groups, weak access policies, exposed services, and incorrect cloud configurations.

An environment with a few cloud resources will naturally require less effort than a large infrastructure containing multiple accounts, environments, applications, and services.

One Application Can Include Multiple Asset Types

Modern systems rarely fit neatly into one category. SaaS platform might include a web application, mobile app, API layer, cloud infrastructure, and internal administrative systems.
In this situation, the VAPT scope may combine several assessments.

This is one reason a simple request for a "VAPT price" is difficult to answer without understanding the underlying architecture.

The provider first needs to know exactly which components are included and how deeply each one should be tested.

What to Define Before Requesting a VAPT Quote

Before comparing VAPT providers, create a clear inventory of the assets you want assessed.

For a web application, identify major modules and user roles. For APIs, document the number of endpoints. For mobile applications, specify Android, iOS, or both. For networks, identify IP ranges and systems.

For cloud environments, define the accounts, services, and infrastructure that should be included.
A clear scope reduces pricing confusion and makes quotes easier to compare.

Final Thoughts

VAPT cost depends heavily on the asset being assessed.
Web applications are influenced by functionality and user roles. API pricing depends heavily on endpoint count and complexity.

Mobile testing can involve both the application and its backend services. Network VAPT depends on systems and IP ranges, while cloud assessments may require reviewing infrastructure, permissions, and configurations.

Instead of looking for one standard VAPT price, first define the assets that need testing. Once the scope is clear, it becomes much easier to understand the effort required and compare VAPT quotes accurately.

Testing SAML and OIDC Flows in SSO Applications

PerfectQA Testing Company — Thu, 03 Sep 2026 12:00:24 +0000

SSO applications often rely on SAML or OpenID Connect to move identity information between systems. Testing these flows means checking more than whether a user reaches the application after signing in.

Why the Protocol Matters

SAML and OIDC both support Single Sign-On, but they handle authentication differently. That difference affects what testers need to observe.
SAML commonly uses XML-based assertions passed between an Identity Provider and a Service Provider. OIDC works on top of OAuth 2.0 and usually relies on JSON Web Tokens, scopes, claims, and redirect URIs.

Start with the Authentication Journey

Before testing protocol details, testers should understand the complete login path.
A user may open an application, get redirected to the Identity Provider, authenticate, and then return with identity information. The application uses that information to create a session and decide what the user can access.
The basic journey may look smooth in the browser, but failures can happen at several points. A redirect may be incorrect, a token may be expired, or the application may receive the wrong user attributes.
A practical SSO testing process should therefore cover both the visible user journey and the protocol-level exchange happening behind it.

Testing SAML Authentication Flows

When an application uses SAML, testers need to pay attention to the assertion returned by the Identity Provider.

The assertion carries information about the authenticated user and may include attributes used by the application for access decisions. Testing should confirm that the assertion reaches the intended Service Provider and contains the expected values.

The signature should also be checked because the Service Provider needs to trust that the assertion came from the expected Identity Provider.

Expiry is another important area. An old assertion should not continue working after its allowed time window. Audience restrictions also matter because an assertion created for one application should not be accepted by another application.
Certificate changes can create additional failures. If the Identity Provider replaces a certificate, the Service Provider must still be configured correctly or authentication can stop working.

Testing OIDC Authentication Flows

OIDC requires a different focus.
After authentication, the Identity Provider may return an ID token containing claims about the user. The application can use those claims to identify the user and create a session.

Testers should carefully check that the token contains the expected issuer, audience, expiry, and user claims. A token intended for another client should not be accepted.

Redirect URIs also deserve attention. OIDC clients normally allow only approved redirect destinations. An incorrect or unregistered URI should fail instead of sending authentication data to an unexpected location.

Scopes and claims should match the application's needs. Asking for unnecessary scopes can expose more information than required, while missing scopes may prevent the application from receiving data needed for access decisions.

Check Role and Attribute Mapping

Authentication success does not automatically mean the correct user access has been created.

SAML attributes and OIDC claims may be mapped to roles inside the application. A manager, administrator, and standard employee could all authenticate successfully while receiving different permissions.

Testing should confirm that each identity receives the correct role. Missing, incorrect, or unexpected attributes should not silently result in elevated access.

This matters when user permissions depend heavily on groups or Identity Provider assignments.

Test Expired and Invalid Data

Successful paths are only part of SSO testing.
A SAML assertion with an invalid signature should be rejected. The same applies to an expired assertion or one with the wrong audience.

For OIDC, expired tokens, invalid issuers, incorrect audiences, malformed tokens, and missing claims should be handled safely.
The application should not create a session when the identity information cannot be trusted.

These tests reveal whether the implementation validates authentication data properly or simply assumes any returned response is legitimate.

Observe Session and Logout Behaviour

Protocol testing should also include what happens after authentication.

The application may maintain its own session while the Identity Provider maintains another. These sessions can expire at different times.

A user might remain authenticated with the Identity Provider while being logged out of the application, or the opposite can happen.

Logout behaviour should match the intended design. Testers should check whether logging out ends only the local session or also affects other SSO-connected applications.

SAML and OIDC Need Different Test Depth

SAML and OIDC solve similar authentication problems, but they do not create identical testing requirements.

SAML testing focuses on assertions, signatures, certificates, attributes, and audience rules. OIDC testing places more attention on tokens, claims, scopes, issuers, audiences, and redirect URIs.

The strongest SSO testing approach understands these differences instead of treating every login flow the same. When protocol behaviour, sessions, permissions, redirects, and failure conditions are tested together, teams get a clearer picture of whether authentication works securely across connected applications.

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.