How We Actually Work
Five phases refined across 17 years and engagements in fintech, e-commerce, HR tech, logistics, and more. Each step is grounded in what has repeatedly worked — and what has not.
Phase 1 · Discovery
Understand the Product & Map the Risk
Every engagement starts with the same question: where does a bug cost the most? For a payment integration that is the checkout flow. For an e-commerce platform it is search, cart, and inventory sync. For a regulated environment it is data correctness and audit trails. The first step is a structured review of the stack, the existing test coverage (or lack of it), and the business-critical flows — not a generic checklist, but a read of the actual risk landscape.
- →Requirements and architecture review
- →Risk-based test scope definition
- →Existing coverage gap analysis
- →JIRA / XRay workspace setup and issue structure
- →Alignment on manual vs. automated split
Phase 2 · Test Design
Design Test Cases That Actually Find Bugs
Test design is where most QA processes lose their value — generic happy-path tests that never catch real defects. The approach here is Cucumber BDD for automation-bound scenarios (Given/When/Then tied directly to acceptance criteria) and structured manual cases for exploratory and edge-case coverage. AI-assisted drafting via Test Scribe speeds up the first-pass generation from JIRA tickets without replacing the judgment that goes into review.
- →Cucumber / Gherkin scenarios from JIRA acceptance criteria
- →Manual test case design for edge cases and exploratory coverage
- →AI-assisted first-pass generation with Test Scribe (Ollama or Gemini API)
- →XRay traceability: requirement → test case → execution result
- →Test data strategy — real-world inputs, boundary values, negative paths
Phase 3 · Automation Setup
Build a Framework That the Team Can Own
A framework built from scratch should not require its creator to maintain it forever. Frameworks have been built or rebuilt at CoachHub (NightWatch.js + Cucumber.js), Home24 (Codeception), Cornelsen (Protractor + Mocha), autoTicket (SoapUI + Groovy) and others. The consistent principle: select the right tool for the existing stack, keep the architecture simple enough for the team to extend, and wire it into CI from day one — not as an afterthought.
- →Framework selection matched to the existing tech stack
- →Project structure and coding conventions defined upfront
- →Reusable components: page objects, API clients, data factories
- →GitLab CI or Jenkins pipeline integration from the first commit
- →Parallel execution and test reporting configured before handover
Phase 4 · Execution & Coverage
Run Tests Where It Counts — UI, API, Mobile, Load
Coverage is not a percentage. It is a function of which flows break in production and whether the test suite catches them first. Execution is layered: API tests run fast on every commit, UI tests run on merge requests, performance tests run before releases or campaigns. Mobile coverage via WebdriverIO (iOS and Android) is added when the product ships a native or hybrid app. Load testing with K6, Gatling, or JMeter is scoped to the flows where latency or concurrency failures have real user impact.
- →API end-to-end tests — REST, GraphQL, SOAP, RabbitMQ
- →UI automation — cross-browser, cross-platform
- →Mobile automation — iOS and Android (WebdriverIO / Appium)
- →Performance and load testing — K6, Gatling, JMeter
- →Execution results synced to XRay with pass/fail traceability
Phase 5 · Handover & Continuity
Leave the Team Better Than You Found It
A QA engagement that ends with the team dependent on the consultant has not really succeeded. Knowledge transfer is built in from the start — through documented architecture, in-code comments where decisions are non-obvious, and hands-on training for the engineers who will run and extend the suite. Where a QA team is being built from scratch (CoachHub, About You/Scayle, Seven Senders, Home24), this phase includes hiring criteria, onboarding documentation, and the process definitions that make the team self-sustaining.
- →Framework documentation and runbook
- →Hands-on training sessions for the QA and dev team
- →Test maintenance guidelines and contribution workflow
- →Pipeline monitoring and alerting configuration
- →Hiring criteria and onboarding material (team-building engagements)
Ready to Start Your QA Transformation?
Let's talk through your stack, your risks, and where to start.
Discuss Your Project