OMNO · Technical questions and ideal answers

• A unified merchant integration coordinates provider selection and processing
• Verify normalization, configuration and financial effects across provider attempts.

Pitfall: Assuming every PSP has identical semantics.

Full explanation.

• Authorization approves or reserves under the contract, capture requests collection and settlement is a later financial stage
• Test each boundary and its own evidence.

Pitfall: Calling an authorization response settled funds.

Full explanation.

• A payment is a business operation while an attempt represents one provider interaction
• Correlate provider references and effects without treating every attempt as a new purchase.

Pitfall: An ambiguous transaction ID with no system/grain.

Full explanation.

• The outcome is unknown, not definitely declined
• Reconcile the original reference and follow the supported retry/fallback policy before another financial attempt.

Pitfall: Blindly retry through another PSP.

Full explanation.

• Cover eligibility, priority/conflicts, no-match and controlled config versions
• Simulate allowed failure/fallback classes and preserve attempt identity.

Pitfall: Only test one happy-path eligible provider.

Full explanation.

• Prefer controlled configuration/seed when available and an agreed statistical strategy for random behavior
• Small samples do not guarantee an exact distribution.

Pitfall: Expecting one payment per provider from two random requests.

Full explanation.

• No, the backend must enforce a scoped key/payload/retention contract
• Test same operation, mismatched payload, concurrency and one effect.

Pitfall: Assuming provider and orchestration keys share one dedupe boundary.

Full explanation.

• Check eligible state, positive amount, remaining balance and cumulative total
• Add concurrent requests, duplicate submission and final effect verification.

Pitfall: Only validating each request against a stale client-side balance.

Full explanation.

• No, authentication/challenge and payment authorization are distinct stages
• Test approved sandbox challenge outcomes, cancellation, timeout and truthful return state.

Pitfall: A completed browser challenge guarantees captured money.

Full explanation.

• Use the actual currency/scale contract with safe integer minor units or defined decimal arithmetic
• Test precision, overflow, limits and currency-specific grouping.

Pitfall: All currencies have two decimal places.

Full explanation.

• Duplicate financial effects, uncertain outcomes, invalid routing, permissions and inconsistent callbacks
• Prioritize by actual business impact and observed architecture.

Pitfall: Treating provider success text as the entire oracle.

Full explanation.

• It proves an observed display in that exercised browser state
• Final service/provider/ledger evidence needs appropriate separate validation.

Pitfall: A heading proves the customer's funds settled.

Full explanation.

• Ask whether submission occurred, which errors qualify, retry limits and late-result policy
• Turn answers into shared examples and explicit acceptance observations.

Pitfall: Inventing a universal provider failure policy.

Full explanation.

• Partitions group inputs expected to behave similarly, boundaries target transition points
• For a limit L test relevant sides and exact inclusivity in the correct minor unit.

Pitfall: Using an arbitrary decimal offset without understanding scale.

Full explanation.

• Severity describes impact while priority schedules work
• Financial integrity may be serious even if occurrence is rare.

Pitfall: Automatically equating frequency with business impact.

Full explanation.

• Exact build/environment, owned data/config, steps and actual versus agreed expected behavior
• Include sanitized IDs, timestamps and correlated evidence.

Pitfall: A screenshot without the operation identity or expected rule.

Full explanation.

• Documented status, runtime shape, permissions, business rules and effects
• Cover boundaries, negative states, duplicates and cleanup.

Pitfall: Only checking response.ok().

Full explanation.

• 401 generally concerns absent/invalid authentication, 403 forbidden action and 404 absent/concealed resource
• Follow the actual security policy and test cross-merchant behavior.

Pitfall: Token presence proves authorization.

Full explanation.

• The request is accepted under the contract, not necessarily completed
• Observe a supported terminal business state and resulting effects separately.

Pitfall: Comparing a transport code directly with CAPTURED.

Full explanation.

• It acknowledges reception/ingestion under a contract, not every later processing step
• Verify durable handoff, eventual state, correlation and recovery.

Pitfall: Acknowledge before any durable record then assume no events can be lost.

Full explanation.

• Replay identical event IDs and equivalent business facts with different IDs
• Wait for the delivery-processing barrier and verify one intended effect.

Pitfall: One early count of one proves no later duplicate.

Full explanation.

• Deliver controlled older/newer events around the same payment and attempt
• Assert documented sequence/state rules prevent illegal regression.

Pitfall: Assuming network order equals business order.

Full explanation.

• Use the provider's documented supported signing/verification protocol with approved test secrets
• Include raw-body changes, stale/replayed payloads and no forbidden effects.

Pitfall: Inventing one generic HMAC implementation for all PSPs.

Full explanation.

• Mocks isolate assumed responses, contracts validate interface expectations and real sandbox checks exercise deployed integration
• Choose complementary evidence by risk.

Pitfall: Calling a route mock proof of PSP or DB correctness.

Full explanation.

• Always a Promise, including Promise
• A thrown exception becomes rejection and await obtains fulfillment or throws.

Pitfall: Expecting a synchronous bare value from async.

Full explanation.

• get returns Promise, so await the response before its synchronous status method
• json returns another Promise and needs a separate await.

Pitfall: Casting the Promise to any to silence the error.

Full explanation.

• Not with ordinary APIResponse behavior unless failure settings require it
• Assert the status as well as handling transport rejection.

Pitfall: Catch-only tests silently accept returned server errors.

Full explanation.

• Independent operations that can overlap safely and within capacity
• Dependent create/read calls must be sequenced by validated returned ID.

Pitfall: Concurrent POST and GET needing the created ID.

Full explanation.

• No, other requests can continue after one rejects
• Inspect partial effects and use contract-supported recovery instead of assuming rollback.

Pitfall: Treating concurrency as a database transaction.

Full explanation.

• forEach returns undefined and ignores callback Promises
• Use for-of for sequence or await Promise.all(map) for independent bounded work.

Pitfall: The test finishes while important callbacks still run.

Full explanation.

• When every independent outcome matters for complete reporting
• Inspect each result and fail required operations explicitly.

Pitfall: All-settled output makes all failures harmless.

Full explanation.

• It prevents rebinding the variable, not mutating its object
• Spread copies shallowly so nested data can still be shared.

Pitfall: Shared nested fixture data leaks between tests.

Full explanation.

• unknown requires narrowing and any bypasses checking
• A type assertion changes compiler belief but does not validate network JSON.

Pitfall: body as Payment proves runtime schema.

Full explanation.

• Filter the intended business states and group by compatible currency/scale
• Use safe integer or specified decimal arithmetic and check overflow.

Pitfall: Summing currencies or floating values without a contract.

Full explanation.

• An attempt to run teardown after normal success/failure paths, not successful cleanup during outage or process kill
• Preserve the original failure and report cleanup problems too.

Pitfall: A thrown cleanup error masks the real defect.

Full explanation.

• Use the declared precision/format contract and cover normal, zero, invalid, too-precise and oversized inputs
• Separate parsing from whether payment creation allows zero.

Pitfall: Using a two-decimal exercise as every currency's rule.

Full explanation.

• It describes a query, not proof of business state
• Actions apply actionability and locator assertions retry their expected observation.

Pitfall: expect(locator).toBeTruthy validates the UI.

Full explanation.

• They reflect stable accessible semantics where the UI supports them
• Test IDs or stable CSS IDs are valid explicit contracts when appropriate.

Pitfall: Blindly banning CSS or masking ambiguity with first().

Full explanation.

• Applicable actionability such as unique, visible, stable, enabled and receiving events
• Provider/business completion still needs a separate observation.

Pitfall: A successful click proves capture completed.

Full explanation.

• A locator assertion retries live state, while the latter compares one read snapshot
• Await the retrying assertion so failure reaches the runner.

Pitfall: Assuming all expect calls reread the browser.

Full explanation.

• A fast response can occur during the action
• Register by request identity, trigger, await and assert status.

Pitfall: Registering after the event and increasing the wait timeout.

Full explanation.

• No, it mocks matching browser traffic
• APIRequestContext calls are direct HTTP and need separate assumptions/tests.

Pitfall: A browser stub proves actual integration coverage.

Full explanation.

• Create the event Promise before the triggering action
• Await the event and assert the meaningful target/content.

Pitfall: Only inspect a download filename and call totals verified.

Full explanation.

• Cohesive locators and semantic page actions
• Keep business intent/outcome visible and service/DB logic in suitable separate boundaries.

Pitfall: A giant page class owns the whole architecture.

Full explanation.

• It yields the initialized resource to dependents/test and teardown follows
• Dependencies set up first and tear down after dependents.

Pitfall: Cleanup exists only after passing test assertions.

Full explanation.

• Not a longer-lived worker resource on shorter-lived test fixtures
• Create a separately owned API context when worker scope is necessary.

Pitfall: Assuming worker setup runs once globally across shards.

Full explanation.

• No, it saves supported browser state and backend expiry/revocation still applies
• Re-authenticate/refresh through the real supported flow and isolate conflicting accounts.

Pitfall: Rewriting the same expired JSON fixes authentication.

Full explanation.

• Use owned per-test data for conflicting writes and share only proven nonconflicting resources
• Include pipeline/job/worker identity or a real lease for parallel accounts.

Pitfall: Browser contexts isolate every database/routing setting.

Full explanation.

• One payment can match multiple attempts/events and multiply its amount
• Establish grain and pre-aggregate or use EXISTS when only presence matters.

Pitfall: DISTINCT blindly hides an incorrect financial query.

Full explanation.

• Compare source/payment identity with NOT EXISTS or a deliberate outer join
• Allow only documented processing lag using stable windows or barriers.

Pitfall: Equal counts imply the same records exist.

Full explanation.

• Use IS NULL/IS NOT NULL because equality to NULL is unknown
• Be careful with NOT IN containing NULL and WHERE filters on outer joins.

Pitfall: = NULL finds missing values.

Full explanation.

• Use ROW_NUMBER partitioned by payment with deterministic timestamp/ID ordering
• Prefer actual business sequence/version when that defines recency.

Pitfall: MAX(timestamp) alone selects all associated row fields.

Full explanation.

• Parameterized values, approved access and bounded reads
• Understand EXPLAIN cost and that EXPLAIN ANALYZE executes the query.

Pitfall: Read-only means no privacy or production-load risk.

Full explanation.

• Duplicates can occur and business effects need deduplication
• Ordering depends on key/partition/configuration, not a universal global sequence.

Pitfall: The broker makes external ledger effects exactly once automatically.

Full explanation.

• Lockfile install, static checks, risk-focused tests and retained sanitized reports
• Gate critical failures in the actual merge/release process.

Pitfall: Playwright transpilation proves TypeScript type correctness.

Full explanation.

• True permits optional job failure while false makes it fail the pipeline
• Project merge settings must enforce the relevant successful pipeline.

Pitfall: Quietly making a critical payment test optional.

Full explanation.

• Workers execute within one run while shards partition separate runs/jobs
• Their product determines potential concurrency and backend account demand.

Pitfall: Four shards with two workers need only two unique conflicting accounts.

Full explanation.

• Preserve exact environment/data and trace/network/correlation evidence, then test competing hypotheses
• Change one factor and verify the targeted repair under original conditions.

Pitfall: Every timeout is solved by globally increasing timeouts.

Full explanation.

• Fetch updates remote-tracking information without automatically integrating it, commit records local changes and push updates the remote
• Review staged/untracked data before sharing.

Pitfall: A local commit is already deployed to Cloudflare.

Full explanation.

• It proves selected checks passed in that run, not complete requirements coverage or defect detection
• Map assertions to risks and test controlled wrong outcomes.

Pitfall: A high pass rate alone measures business confidence.

Full explanation.

• Expect the agreed concurrency response/async outcome and verify total accepted effects do not exceed the remaining amount
• Client-side eligibility checks alone cannot enforce it.

Pitfall: Only compare HTTP codes and ignore final ledger total.

Full explanation.

• No, another delivery may still be unprocessed
• Wait for a supported processing barrier/watermark and inspect final business effects.

Pitfall: An arbitrary sleep proves all future callbacks are impossible.

Full explanation.

• Assert the relevant status, amount/currency and owned entity, then inject a controlled wrong state to prove the assertion fails
• Keep real integration evidence for provider/ledger behavior.

Pitfall: Counting assertions instead of checking their meaning.

Full explanation.

• Investigate single-session policy and shared account identity using timestamps
• Provision/lease independent accounts across conflicting job/pipeline scopes.

Pitfall: Separate storage-state filenames solve server revocation.

Full explanation.

• No, use the lowest useful layer and retain critical E2E interactions
• Combine API/unit/contract/UI/manual exploration according to the risk.

Pitfall: Pyramid percentages are universal quotas.

Full explanation.

• Explain your genuine interest and ask about hands-on scope, ownership and growth
• Use broad experience without inventing personal motivations or hiding current learning.

Pitfall: Assuming a motivation not supplied by the candidate.

Full explanation.

• Current CV supports development/maintenance for regulatory backoffice and earlier Python automation elsewhere
• Give an actual test and distinguish broad QA tenure from continuous automation years.

Pitfall: Eight-plus QA years means eight-plus Playwright years.

Full explanation.

• Earlier frontend scope included payments/authorization, plus regulatory backend and financial-market work
• Explain what you tested without claiming PSP routing-engine ownership.

Pitfall: Transferable experience is identical to OMNO implementation experience.

Full explanation.

• Use a real symptom, competing hypotheses, correlation/API/SQL evidence and true outcome
• Separate personal actions from developer/team confirmation.

Pitfall: Inventing a metric or production fix for a stronger story.

Full explanation.

• Explain actual Python trade-comparison tests, Allure and Jenkins integration at Exactpro
• State the actual period/scope and current Playwright work separately.

Pitfall: Relabeling Python/Jenkins work as years of GitLab/TS framework ownership.

Full explanation.

• Anchor the discussion to agreed requirements, reproducible financial/user impact and competing evidence
• Present safe alternatives and make residual risk/accountability explicit.

Pitfall: Either silently waive the check or argue only from title.

Full explanation.

• Ask current stack/CI, PSP simulation controls, top integrity risks, ownership and data access
• Propose changes based on actual pain rather than tool preference.

Pitfall: Assuming the JD's example frameworks confirm the deployed stack.

Full explanation.