Drixen Umvali
Drixen Umvali
Test case consulting
Svobody Ave, 8, Lviv, Ukraine
About Drixen Umvali

Quality through
structured testing

Drixen Umvali works with software teams that need precise, repeatable test case design — not generic checklists. The specifics of what gets tested, how, and under what conditions are never left to assumption.

8+
years active
340+
projects delivered
14
testing specialists

Background

Where the practice came from

Drixen Umvali started in 2017 when a group of testers noticed a recurring gap: development teams were writing test cases reactively, after defects appeared, rather than as a deliberate design activity. The consultancy formed specifically to address that gap, not as a broad QA shop, but as specialists in the structure and logic of test case construction.

The work covers the full arc from requirement analysis to execution reporting. A typical engagement involves reviewing what conditions need to be tested, designing cases that isolate variables cleanly, and validating that the execution process produces findings that can actually be acted on. The output is documentation that holds up under audit and under pressure.

Operating remotely from Lviv, the team has worked with clients from Kharkiv to Uzhhorod, adapting the same structured methodology to projects of different sizes and technical stacks. The geography never changes the standard of work.

The team

Specialists, not generalists

Each person on the team was hired for a specific competency in the test case lifecycle — nobody here covers everything loosely.

Bohdan Starytsia — Lead Test Architect

Bohdan Starytsia

Lead Test Architect

Bohdan joined in 2018 after five years writing test strategies for fintech platforms. His focus is the logical structure of test suites — how cases relate to each other, where coverage overlaps, and where gaps hide. He reviews every major test plan before it goes to the client.

Oksana Hryniv — Execution Lead

Oksana Hryniv

Execution Lead

Oversees test run management and defect classification. Oksana built the execution reporting templates now used across all client engagements.

8+
avg. years
per specialist
Core team depth

Every senior consultant has worked in-house before joining — they've been on both sides of the review table.

How the work happens

Four phases, one standard

The methodology doesn't change by client size. What changes is the scope. Each phase produces a specific artefact that the next phase depends on.

Test execution environment and workflow documentation
01

Requirement mapping

Every requirement is tagged with the testing conditions it implies. Ambiguous requirements get flagged before a single test case is written.

02

Case design

Cases are written to boundary conditions, equivalence partitions, and negative paths. Each case specifies preconditions, steps, and expected results in non-negotiable detail.

03

Execution and logging

Runs are logged against the defined cases, not improvised. Deviations from expected results are classified and linked back to the relevant requirement.

04

Reporting and handoff

Findings are documented in a format the development team can act on without a debrief call. Coverage gaps and untested paths are explicitly noted, not silently omitted.

Detailed test case documentation and review process

What remote delivery actually looks like

Clients don't get a video call and a shared spreadsheet. Each engagement runs on documented handoff points — requirement artefacts are reviewed asynchronously, test case drafts go through a structured review round, and execution reports are delivered in a fixed format that doesn't require interpretation.

  • Asynchronous review cycles with written feedback trails
  • Fixed artefact formats — no client-specific reinvention each time
  • Execution logs linked to individual test cases, not aggregated
  • Final reports structured for both technical and non-technical stakeholders

A specific image of what good looks like

A well-written test case reads like a precise instruction, not a vague intention. When someone who didn't write it runs it six months later, the result should be the same. That repeatability is the standard Drixen Umvali holds its output to.

Professional testing documentation and quality assurance workflow