FAQ & Troubleshooting

Common questions and the issues you’ll most likely hit in your first week.

← Back to overview · 🇩🇪 Deutsch · ← Credential Management · Writing Your First TestCase →

Installation

Installation fails with 401 Unauthorized

Cause: npm doesn’t have a valid License Key to authenticate against the proxy registry.

Diagnosis:

echo $CC_LICENSE_KEY

If the output is empty, the env var isn’t set. Re-run the export from Quickstart Step 4 (or Step 3, if you’re still in the same terminal session as the bootstrap command).

If the var is set but install still fails, check that:

  1. The .npmrc references it correctly (${CC_LICENSE_KEY}, not $CC_LICENSE_KEY)
  2. The key is copied exactly as it appears in the Welcome Email, with no extra whitespace
  3. The trial or subscription behind the key hasn’t expired — see License troubleshooting

Installation fails with 404 Not Found

Cause: the package name is misspelled, or the proxy registry doesn’t recognize your license yet.

Checklist:

  1. Is the package name spelled exactly @meintest/cc-testframework (lowercase meintest)?
  2. Did the Welcome Email’s License Key finish activating? New keys can take a minute to propagate to the proxy registry.

If the name is correct and you still get 404, contact support@itsbusiness.ch with your License Key’s associated email address.

Installation fails with 404 or DEPLOYMENT_NOT_FOUND after it used to work

Cause: your project’s pm/.npmrc still targets the retired proxy host, cc-testframework-landing.vercel.app — it was replaced by itsbusiness.vercel.app and no longer resolves. This only affects a project scaffolded before the change; a fresh scaffold already uses the current host.

Fix: open pm/.npmrc and update both lines to the current host:

@meintest:registry=https://itsbusiness.vercel.app/api/tmgmt/npm/
//itsbusiness.vercel.app/api/tmgmt/npm/:_authToken=${CC_LICENSE_KEY}

Then retry npm install from inside pm/.

Installation hangs forever

If npm install (inside pm/) hangs after “Downloading X% complete”, this is usually a network issue with the Windows-WSL/Devcontainer file system (slow small-file I/O). Workaround, run from inside pm/:

# Cancel (Ctrl+C), clear, retry with verbose logging
rm -rf node_modules package-lock.json
npm install --verbose

If it still hangs, try installing from outside any WSL/Docker layer first to verify network/auth, then move into the containerized environment.

How do I manage or cancel my subscription?

Run:

npx cc-testframework billing

It reads your CC_LICENSE_KEY, requests a short-lived, personal link to the self-service billing portal, prints it, and (when run in an interactive terminal) opens it in your browser. There you can update your payment method, download invoices, or cancel the subscription.

  • Add --no-open to only print the URL (e.g. on a headless server), or --json for machine-readable output.
  • If you’re on a trial or a key without an active subscription, the command reports that there’s nothing to manage — contact sales@itsbusiness.ch to start a subscription.
  • The portal link is bound to your subscription and expires quickly; no payment details ever pass through the framework.

How do I upgrade my trial to a paid plan?

Run:

npx cc-testframework upgrade

It reads your CC_LICENSE_KEY, checks whether the license is an upgradeable trial, and if so prints (and, in an interactive terminal, opens) the pricing page. You complete the purchase there; a new paid license key is then emailed to you — set it as CC_LICENSE_KEY.

  • Add --no-open to only print the URL, or --json for machine-readable output.
  • If the key is already on a paid subscription, the command points you at npx cc-testframework billing instead. Perpetual or manually-issued keys have no self-service upgrade — contact sales@itsbusiness.ch.

Setup and configuration

Do I really need the three layers (Controls / TestSteps / Cases)?

For >10 TestCases sharing similar UI patterns: yes, the layers pay off in maintainability.

For 1-3 quick smoke tests: no, you can write a single TC_Smoke.spec.ts and call Core’s Action / Check directly. The framework doesn’t enforce the layers, it provides them as the productive default.

Can I use page.locator() directly inside a TestCase?

Technically yes, but it defeats the architecture. Direct page.locator() calls inside TestCases:

  • Hide UI implementation details in test scenarios
  • Make UI refactors painful (every TestCase touching the changed element must be updated)
  • Defeat readability (“locate this CSS selector” vs “click the Submit button in the Login dialog”)

If you find yourself doing this often, it’s a signal that a Control or TestStep is missing.

My tsconfig.json shows red errors after copying the template

The template’s @Apps/* path-alias points at pm/2_Apps/* — you (or a scaffolding tool) append one alias set per app on app creation (@App1 → pm/2_Apps/<first-app>/References.ts, @App1Controls/* → .../1_Controls/*, and so on). You need to:

  1. Add or rename these per-app aliases in tsconfig.json to match your actual app folder name
  2. Ensure your pm/2_Apps/<YourApp>/ folder actually exists with the expected sub-structure
  3. Restart your TypeScript-language-server in the IDE after editing tsconfig

Is there a faster way to add a new Web app than renaming _Skeleton by hand?

Yes — npx cc-testframework create-web-app --name <YourApp> --url <your-app-url> copies _Skeleton into a numbered 2_Apps/<N>_<YourApp>/ folder, substitutes the App-name placeholder, adds the matching entry to GlobalConfig.ts’s apps object, and wires the global References.ts barrel with the app’s re-export line, all in one step — Project.<YourApp>.* is importable immediately. The one exception: if your barrel is still the un-activated References.ts.example, that last step is soft-skipped with a printed next-step instead. See Add a New App — Scaffold a Web app automatically with the CLI for the full flag list and an example run. Registering a Windows Desktop app instead? create-desktop-app --name <YourApp> --executable <path> does the same thing for an Appium-Windows AUT — see Scaffold a Desktop app automatically with the CLI.

How do I migrate from the old Git-Submodule setup?

Three steps:

  1. Remove .gitmodules from your repo root.
  2. Delete the local tests/1_Core/ directory — the Core now comes from pm/node_modules via the npm package.
  3. Replace submodule-path imports with package imports: 
    // before
import { Action } from '../1_Core/Internal/Action';
// after
import { Action } from '@meintest/cc-testframework';

    Use a grep -r "1_Core/" tests/ to find all such imports, then a find-replace across the codebase.

How do I know if a newer framework version is still compatible with my environment?

Every release of @meintest/cc-testframework-templates publishes a machine-readable supportMatrix in its manifest.json — the Playwright, Node, Appium, and browser version ranges (plus any shipped-app-gated component, e.g. Outlook/Microsoft 365) that release is tested and supported against. See Scaffold a New App — Checking compatibility before you update for the schema and how to read it before installing.

Usage

My test fails with “browser executable not found”

Playwright needs the browser binary downloaded. Run:

npx playwright install --with-deps chromium

The --with-deps flag installs OS-level dependencies needed on Linux (won’t do anything on macOS/Windows but is harmless).

headless: false doesn’t show a browser on my Linux server

On a headless server (no display), headless: false requires a virtual display (Xvfb) or remote display. Either:

  • Use headless: true in CI/server contexts
  • Or set DISPLAY=:99 and run an Xvfb :99 process before tests

A common pattern is environment-conditional headedness:

headless: process.env.HEADLESS === 'true' || !!process.env.CI,

Tests randomly fail with “element not found”

Usually one of:

  • The page isn’t fully loaded → use AppReady.waitForPageLoad() or waitForNetworkIdle()
  • A modal/loading-spinner is covering the element → wait for it to disappear first
  • The selector matches multiple elements → narrow the locator with the view-prefix ('Login', 'dialog')
  • The test ran faster than the UI rendered the element → switch from page.locator(...).click() to the framework’s Action.click(), which has built-in retry logic

How do I run only one TestCase?

From inside pm/:

npx playwright test 3_Cases/TC_UserCreation.spec.ts

Or with the --grep flag for a partial match:

npx playwright test --grep "UserCreation"

Can I keep the browser open after a test run instead of it closing automatically?

Yes — set CC_DEBUG_SESSION=true (or debugSession: true in .cc-testframework.local.json). The first run then launches the AUT as its own detached process and exits normally; every following run reconnects to that same instance instead of relaunching it, picking up wherever the previous run left off. See Persistent Debug Session for setup, the CLI (npx cc-testframework session status/close), and the Electron caveat. Don’t enable this in CI — the persistent process is a local debugging aid, not a CI setting.

How does the framework know where to find the Appium server for Desktop tests?

For a Desktop AUT (Windows, via Appium), the framework resolves the Appium server URL in three steps, highest priority first: an explicit appiumUrl on that AUT’s entry in GlobalConfig.apps, then the APPIUM_URL environment variable, then a platform-based default — http://localhost:4723 when the test process itself runs natively on Windows, http://host.docker.internal:4723 everywhere else (Linux, macOS, or a container that reaches a separate Windows host running Appium). You only need to set appiumUrl or APPIUM_URL if your Appium server runs somewhere other than what that default assumes — e.g. a remote machine or a device farm. If the server can’t be reached, the error message tells you which of the two setups it detected and what to check first. See API Reference — Section 14.

My Windows machine has a corporate HTTP proxy — do I need to configure anything for Appium?

No manual step needed. Before opening an Appium/WinAppDriver session, the framework adds the resolved Appium hostname to NO_PROXY for the current process if it isn’t already covered — Appium/WinAppDriver traffic is always local (loopback, or a container’s host-loopback address) and should never go through a proxy meant for the rest of your network traffic. This only touches NO_PROXY; your existing HTTP_PROXY/HTTPS_PROXY setup keeps working unchanged for everything else your tests do.

Self-Healing

Nothing happens when a locator fails — is Self-Healing broken?

Self-Healing only activates for a call where a reference screenshot is bound via Core.Inspector.bindReference(refId) with a non-empty refId, and a matching PNG exists at pm/7_Assets/<uid>/<refId>.png (the <uid> you registered via Core.setTestCaseId('tc_<slug>')). Without both, the framework runs in ordinary locator-only mode and a failed locator fails the test exactly as it always did. Check the console for a [SelfHealing] log line — it reports either an attempt or the specific reason it was skipped (missing reference PNG, budget exhausted, no Vision suggestion, etc.). See Self-Healing Locators for the full setup.

Do I need to rewrite all my existing locators to use Core.xpath?

No. Core.xpath is purely additive — raw template-literal strings keep working exactly as before, they’re just not eligible for automatic writeback. Discovery-mode healing (finding a replacement locator at runtime) still works regardless of whether the original locator was tagged; only the writeback step needs the tag to know where to insert the healed locator in your source file.

The console logs “Vision returned no suggestion” — what now?

The Vision model didn’t find a confident match between the reference screenshot and the current UI. The original locator error is re-raised unchanged, so your test fails with its usual diagnostic — Self-Healing degrades gracefully and never masks a real failure with a confusing secondary error.

Where do I get an AI API key for Self-Healing / the Authoring Agent?

Create one in your own Anthropic Console account (BYOK — Bring Your Own Key). The framework never proxies or stores this key anywhere outside your machine. For Self-Healing Vision, it’s read from the provider-agnostic AI_API_KEY environment variable, a key persisted with npx cc-testframework set-ai-key, the legacy ANTHROPIC_API_KEY environment variable, or the OS credential store, checked in that order — see Self-Healing Locators — Cost and BYOK for the full precedence and the cost model. The Custom-Step Authoring Agent (npx cc-testframework author) currently reads ANTHROPIC_API_KEY specifically, either as an environment variable, an interactive prompt, or via Credential Management.

What happens if I edit the same Control file in my IDE while the agent runs writeback?

If a colleague (or another agent run) actively holds a lock on that file through the same coordination protocol, this run skips it entirely — nothing is written, nothing is committed — and .self-healing-report.json records who holds the lock (lockedByHumans). A plain, uncoordinated local edit that no tool has locked is invisible to this protection, though: commit or stash your own changes before running a job with SELF_HEALING_WRITEBACK=true, and pay attention to the reporter’s dirty-working-tree warning if you see one. See Self-Healing Locators — Multi-user coordination for the full lock lifecycle and the SELF_HEALING_AGENT_IDENTITY env-var.

My test run reports a heal, but nothing changed in my Control file — why?

Writeback needs one more thing beyond a successful heal: SelfHealingWritebackReporter actually registered for the run, either via baseConfig auto-wiring (SELF_HEALING_WRITEBACK=true set, and your config spreading baseConfig) or manually. Run npx cc-testframework self-healing status — it checks exactly this, plus your Anthropic API key, git origin reachability, and any active coordination locks, in one pass. See Self-Healing Locators — Diagnosing pipeline issues.

How do I check whether the Self-Healing pipeline is set up correctly?

npx cc-testframework self-healing status runs six health checks (writeback mode, Anthropic API key, agent identity, reporter registration, git origin, ref-lock status) and prints HEALTHY or MISCONFIGURED with the specific reason for every failing check. Pass --format json for the same result as a single parseable object, e.g. for a script that gates a deployment on pipeline health. See Self-Healing Locators — Diagnosing pipeline issues.

How do I clear out queued heals that never got applied?

npx cc-testframework self-healing clear deletes .self-healing-pending.jsonl, after an interactive confirmation. Pass --force in a non-interactive context (CI, a script) — without it, a non-interactive invocation exits with code 2 instead of deleting anything, so an unattended pipeline never silently discards pending heals. See Self-Healing Locators — Clearing the pending-heals queue.

Can I use SelfHealingWritebackReporter alongside my own custom reporters?

Yes — add it to your own reporter[] array, either via the named import (import { SelfHealingWritebackReporter } from '@meintest/cc-testframework') or the dedicated sub-path export (@meintest/cc-testframework/Reporter/SelfHealingWritebackReporter) if your setup doesn’t import the package’s full barrel. See Self-Healing Locators — Registering the reporter manually.

Do I have to keep setting SELF_HEALING_WRITEBACK every session?

No — npx cc-testframework config self-healing enable (plus discovery / set-identity <string> / disable / show) persists the same choices into a project-level .cc-testframework.local.json file, so a new terminal or a switch between shells doesn’t lose your setup. An environment variable, when present, always wins over the file, so an existing export SELF_HEALING_WRITEBACK=... setup keeps working unchanged. One caveat: if your playwright.config.ts relies on baseConfig’s automatic reporter registration (rather than registering the reporter manually), that specific decision still only checks the environment variable, not the config file — see Self-Healing Locators — Persisting the setup across sessions for the full explanation and the two ways to close that gap.

Custom Steps

How do I track Custom Steps that aren’t automated yet?

Run discoverCustomSteps(rootDir) and check the isNotImplemented field on each returned CustomStepDiscovery — true means the step’s body still contains the “not yet automated” placeholder. Pair it with validateCustomStep(discovery) to also catch authoring mistakes (missing stepId, invalid intent, and so on) while you’re at it. See Custom Steps — Discovering and validating Custom Steps for a ready-to-run script; it’s a good candidate for a CI job that reports how many Custom Steps remain pending.

My test-management tool doesn’t have a “Custom” step option — can I still write one?

Yes. The @custom JSDoc convention doesn’t require any particular authoring tool — copy the TS_Custom.ts template into your App’s 2_Steps folder and fill in the tags by hand. See Custom Steps — Writing a Custom Step by hand.

Can I have the framework implement my Custom Steps automatically instead of writing them by hand?

Yes — either call runAuthoringAgent(options) directly (pass your own test root plus a digest of your application’s current UI tree), or run npx cc-testframework author from a terminal, which captures that UI-tree digest for you end-to-end. Both need ANTHROPIC_API_KEY (BYOK, same key as Self-Healing). See Custom Steps — Automated implementation and Custom Steps — Running the agent from the command line for the full setup and a runnable example.

Should I run the CLI with --test <path> or --batch-mode --app <name>?

Default to --test <path> (Runtime mode) — point it at a Test-Case and it runs the whole thing end-to-end, fixing whatever breaks along the way, Custom Steps and already-implemented steps alike, across as many Apps as the Test-Case itself touches. Reach for --batch-mode --app <name> instead when you specifically want to implement every @custom-tagged step in one App’s 2_Steps/ folder in a single pass without running any Test-Case at all — e.g. right after a bulk-authoring session in your test-management tool, before any Test-Case referencing those steps even exists yet. See Custom Steps — Running the agent from the command line for both modes side by side.

What happens when a step that already works starts failing after an app change?

If that step has a Self-Healing reference screenshot bound to it, Self-Healing tries to repair the locator first — see the Self-Healing FAQ entries above. If it doesn’t, and you’re running Runtime mode (--test <path>), the loop still detects and diagnoses the failure and identifies the likely correct element — but it doesn’t yet rewrite the step’s code automatically the way it does for an unimplemented Custom Step. Run the same Test-Case with --dry-run to see what element the agent identified in the report, and apply the change by hand. See the callout in Custom Steps — Runtime mode for the full explanation.

Why did the Authoring Agent skip one of my Custom Steps?

Check the reason field on the matching entry in AuthoringResult.skipped[] — it’s always one of eight fixed values (validation-failed, duplicate-step-id, already-implemented, element-not-found, agent-uncertain, agent-uncertain-underspecified, max-steps-reached, file-locked-by-human), each paired with a human-readable reasonDetail. See Custom Steps — Why a step gets skipped for what each one means and how to resolve it.

The Authoring Agent generated a color-check step that doesn’t compile — what do I do?

That’s a known gap: @property color / @operator equals checks call a Check method the framework doesn’t ship yet. Review the generated assertion and adjust it by hand for now — see the callout in Custom Steps — What gets generated for details. Every other supported @property/@operator combination generates code that runs as-is.

How do I wire the Authoring Agent into my CI pipeline?

Use the CLI’s exit codes: treat 0 as success, 1 as a real failure worth failing the build over, and (batch mode only) 3 as a lock stand-off that’s often worth a retry rather than an alarm (a colleague or another CI job currently holds the write lock on every targeted file — see Self-Healing Locators — Multi-user coordination). Point --report-path at a location your pipeline picks up afterwards, e.g. to post the applied/skipped/error counts (batch mode) or the finalStatus/fixes[] breakdown (Runtime mode) as a PR comment.

What happens if my --test path matches zero test files?

Runtime mode doesn’t silently treat that as success. If Playwright’s own JSON report confirms zero test files were matched — typically a typo in the path — the run prints a warning, adds a kind: 'playwright-0-tests' entry to the report’s credentialIssues array (with the offending pattern), and emits a playwright-0-tests progress event. finalStatus and the exit code are unaffected by this alone, since Playwright itself exits 0 for “0 tests matched” — check credentialIssues even after what otherwise looks like a clean finalStatus: 'passed'. See the callout in Custom Steps — Runtime mode.

How do I make my step descriptions appear in my tester’s language?

Add a same-named catalog file next to the step file, e.g. TS_Main.i18n.json beside TS_Main.ts, keyed by exported step-function name with one entry per locale. This is enough on its own for any external tooling that statically parses the catalog — no framework configuration or runtime change required for that path; a missing catalog, or a missing locale within one, simply falls back to the English text already in your .ts file. Want the framework’s own test run to render the same catalog too? See the next question. Full convention and a runnable example: Step-Description Localization.

Can I see step descriptions in German (or another language) when I run the tests myself?

Yes — set language = 'de' in your project’s pm/2_Apps/1_Global/GlobalConfig.ts, or export the environment variable CC_TESTFRAMEWORK_LOCALE=de before running, and the framework’s own execution — Playwright’s HTML/JSON reports, the console output, and the Self-Healing writeback report — renders the same .i18n.json catalogs live, at the moment each step runs. Steps still using the older description:/logTitle: fields keep rendering in English regardless. See Runtime localization for the full priority chain and what stays English either way.

The validator says my catalog has a placeholder mismatch — what does that mean?

Every locale entry for a given step key must use exactly the same ${paramName} placeholders as the English source template — same names, same count, only the wording and order around them may differ. A missing or extra placeholder breaks the substitution that happens when the text is actually displayed to a tester, so the validator treats it as an error rather than a warning. See Step-Description Localization — The placeholder contract for a valid/invalid example side by side.

Credentials

Where are my credentials stored?

In your operating system’s native credential store — Windows Credential Manager, macOS Keychain, or (on Linux) the Secret Service exposed by your desktop session’s keyring daemon — under the service name cc-testframework. Nothing is written to a .env file or your shell history unless you set an environment variable yourself. See Credential Management for the full mechanism.

How do I rotate a key or token?

Run npx cc-testframework config set <name> again — it overwrites whatever was stored before. There’s no separate “rotate” action needed.

Can I use a different GitHub token per project?

Yes — github-token is project-scoped by default, auto-detected from your current repository’s git remote. Pass --global to config set instead if you’d rather use one token for every project (a common choice for a solo developer). See Credential Management — Project scoping.

Are OAuth Device-Flow tokens supported?

Yes — the gho_ and ghu_ token prefixes are both accepted for github-token, alongside classic and fine-grained Personal Access Tokens. The framework only stores and reads the token; obtaining and refreshing it through an OAuth flow is the responsibility of whatever tool walked you through that flow in the first place. When a token expires, get a fresh one and set it again with config set ... --stdin. See Credential Management — Accepted GitHub token formats.

What happens when my token expires?

The framework treats an expired credential as unusable and fails fast with a credential-related error (exit code 4 for the Authoring Agent CLI) rather than sending a doomed request to the remote service — see Credential Management — Expiry and the grace period. Obtain a fresh token or key and set it again; the framework itself never refreshes one on your behalf.

What’s the difference between the GitHub token prefixes?

Prefix Token kind Accepted for github-token?
ghp_ Personal Access Token (classic) Yes
github_pat_ Fine-grained Personal Access Token Yes
ghs_ GitHub App server-to-server token Yes
gho_ OAuth App / OAuth Device-Flow access token Yes
ghu_ GitHub App user-to-server token Yes
ghr_ Refresh token No — never itself usable for an API call or push, only for exchanging it for a new access token

See Credential Management — Accepted GitHub token formats for the reasoning.

How do I share the password-manager secret with a new team-member?

Share it out-of-band — a 1Password entry, a Slack DM, or your own secrets manager, never a git commit or a plain email. Your colleague then runs npx cc-testframework password init --stdin and pastes it; from that point on their machine can decrypt and add entries in PasswordManager.json like anyone else on the team. See Credential Management — Onboard subsequent team-members.

How do I set up test-credentials in CI?

Set the CC_PASSWORD_MANAGER_SECRET environment variable from your CI provider’s own secrets store (GitHub Actions secrets, Vault, Azure Key Vault, …) — it takes priority over the keychain, so no password init step is needed on the runner. PasswordManager.json itself is already checked into the repo and decrypts as soon as the environment variable is present. See Credential Management — Set up CI.

I’m getting a passwordSecretKey deprecation warning — what should I do?

Move the key from GlobalConfig.ts into the keychain: run npx cc-testframework password init --secret <the-existing-key>, then delete the Core.Constant.passwordSecretKey = ... line and commit. Existing PasswordManager.json files keep decrypting exactly as before — only where the key is stored changes. See Credential Management — Migrate from the legacy passwordSecretKey.

License & support

How do I start a trial?

Go to cc-testframework.itsbusiness.ch and click Request a Demo. Fill in the demo-request form (name, work email, company, use case) and submit. You will receive a confirmation on screen. Once your request has been reviewed — within one business day — you will receive a personalized sign-up link by email. Open that link, complete the sign-up form, and a Welcome Email with your 14-day trial License Key will arrive within a few minutes. No GitHub account is needed at any point. See Quickstart Step 1 for the full flow.

There are two separate emails in the onboarding flow:

  1. The personalized sign-up link — sent after your demo request is reviewed (within one business day). If you haven’t received it after one business day, check your spam folder, then contact sales@itsbusiness.ch with the email address you used in the demo-request form.
  2. The Welcome Email (with your License Key) — sent within a few minutes after you submit the sign-up form. If it doesn’t arrive within 10 minutes, check your spam folder, then contact support@itsbusiness.ch with the email address you used in the sign-up form.

The framework prints “License key not recognized”

The CC_LICENSE_KEY value doesn’t match a known license. Common causes:

  • The key was copy-pasted with a leading or trailing space — paste it again carefully
  • The wrong value is set in the env-var (verify with echo $CC_LICENSE_KEY)

If the key is copied exactly from the Welcome Email and the warning persists, contact support@itsbusiness.ch.

My trial expired — what happens to my tests?

Tests continue to run. The framework does not block execution after trial expiry. A warning appears in the log: [cc-testframework license] License expired. Contact sales@itsbusiness.ch for renewal.

Contact sales@itsbusiness.ch to convert to a paid license. Your CC_LICENSE_KEY stays the same — no project changes are needed.

What does “Open Code License” mean exactly?

After license purchase, you (the licensee) may:

  • Install, use, execute the software in your own environment
  • Modify the source code for internal use and within your own products
  • Integrate it into production environments operated by or for your company

You may not:

  • Redistribute, sublicense, sell, rent, or share the software with third parties
  • Use it to develop a competing product
  • Remove the copyright notices

Full terms in the LICENSE file shipped with each release. For commercial license inquiries, contact sales@itsbusiness.ch.

How do I get support?

For technical issues (installation, test failures, configuration):

  1. Check this documentation first — most issues are covered here
  2. Email support@itsbusiness.ch with:
    • Your company name
    • Framework version (pm/node_modules/@meintest/cc-testframework/package.json → version field)
    • Minimal reproduction (test code, log output)
    • What you’ve already tried

For licensing and billing (trial-to-paid conversion, renewals, invoicing): sales@itsbusiness.ch

For pre-purchase questions about whether the framework fits your needs: sales@itsbusiness.ch — no need to be a customer yet.

Is there a public roadmap?

Roadmap details are discussed under NDA during the sales process. Public docs reflect current capabilities only.

Does the framework support mobile testing?

Currently the framework targets web (Playwright-based) and Windows-desktop testing (via Appium). Mobile (iOS/Android) support is on the roadmap but not yet shipped — ask your sales contact about timing if it’s critical to your project.

📧 Technical issues: support@itsbusiness.ch · Licensing & billing: sales@itsbusiness.ch

itsbusiness AG · Bern · Switzerland