Quality Assurance Engineer

Copenhagen, on site. Permanent, full time. Junior or mid level. Reporting to the Engineering Manager, Platform & Quality. Pharma communication is slow for a good reason. Every claim needs a reference, every asset needs approval, and every market has its own rules. We think the software that wins in this industry treats those rules as part of the product rather than something to work around, and that is what we build. Anthill builds the software pharmaceutical companies use to create, approve and run their digital communication. At some of the world's largest pharma companies, commercial and medical teams rely on our products to produce and distribute regulated content. We're around 70 people, headquartered in Copenhagen, with four products: Activator, Arcane, Amplify and Anthill Cloud. Our products are already delivering GenAI-powered capabilities to Enterprise customers around the world. We're growing fast, and it's a good time to join. In our Copenhagen office, engineers, designers, product people and strategists all sit in the same room. We're 15+ nationalities, so English is the official and everyday language in the office and in the codebase. We are hiring a QA engineer into our Platform & Quality team. We hire at junior or mid level and will fit the role to the person we meet. Why the role exists Our products are multi-tenant. A release reaches every connected client at the same moment. Your job is to produce the evidence that a release is safe, by testing on both of our DAM connectors, Aprimo and Veeva Vault. What you will actually work on You decide what is worth testing and in what order. You write those tests as scenarios in Gherkin, plain Given, When and Then text, which run on the automation framework our engineers maintain in Playwright. Your ranking decides what gets automated next. If you write automation yourself, you take your own scenarios through to running tests rather than handing them over. By hand, you test what needs human judgement: negative paths, complex flows and exploratory sessions. That starts once the developer has checked the change against its acceptance criteria. Test cases live in Jira with Xray, and automated results in Allure. In your first year you will:

• Own testing for your product areas end to end, from test planning through defect logging to post-release verification.
• Rank what is worth testing in your areas, author and maintain the scenarios for them, and agree with the automation engineers what is automated and what stays manual.
• Test every release candidate before it reaches production.
• Run structured exploratory sessions that find what a fixed script would not.
• Trace every defect that reaches production to its cause, and turn the answer into the next scenarios.
• Work directly with our QA automation engineers and with the developers who wrote the change you are testing.

Our users are medical and marketing teams inside large pharmaceutical companies. They work under regulatory constraints and they will find a defect we let through. That is a good constraint to test against. How we test and release We work in two-week iterations, and testing runs inside them rather than as a phase at the end. We follow the test pyramid, unit then API then end to end then manual, and automate only what matters to the business. Releases move through four environments: DEV, QA, STG and PROD, each with its own quality bar. The release decision rests on QA's sign-off, and QA signs off only when all of this is true, on both connectors:

• The automated regression suite has run, and every failure is traced to a cause: a product defect, a broken test or an environment problem.
• The essential manual tests pass.
• The planned exploratory testing is done.

Known defects can still ship, but only if a named person accepts them. The release runbook, not memory, is the source of truth for how we run a release. What we are looking for At every level:

• Manual testing of a real product: planning, execution and defect triage, rather than running a script somebody else owns.
• A sense of what matters most to test, and the nerve to say what you would leave out.
• Exploratory technique, and the judgement to know where to point it without a test plan.
• Comfort writing new scenarios, not only reading them.
• Experience keeping test cases in a test management tool.
• The ability to hold a position with a developer, and to change it when the argument against you is better.
• Working English. Danish is not required.

At mid level we also expect:

• Release testing experience: you have tested a product before it reached customers, not only the tickets that went into it.
• Judgement on defect severity and on what should block a release, and the composure to be the named tester on a gate.
• A working grasp of the test pyramid.

Useful, not required:

• Hands-on exposure to writing automated tests in any framework, Playwright, Selenium, Cypress or Cucumber. The framework matters less than having written a test that runs.
• Enough TypeScript or JavaScript to write a step definition, not only trace one, and basic Git.
• Experience with regulated customers.

What we offer

• A permanent Danish employment contract, pension and health insurance.
• A salary set from our salary bands, the same way for everyone at the same level. Where you land in the range depends on your experience and skills, and on pay equity with colleagues at that level.
• Five days a week in our Copenhagen office, with two work from home days a month as the default. We are on site because most of what engineers learn from each other happens in conversation at someone's desk.
• Colleagues who have shipped software into pharma and know how demanding that audience is.
• Clients whose problems are specific and constrained, which is more interesting than it sounds.
• Occasional office dogs, who expect to be petted.

Alex Berliner leads Platform & Quality and would be your manager. Questions about the role can go to him on LinkedIn. Applying If you can recognise yourself in just some of these requirements or skills and simply want to learn the rest, we would love to receive your application. We offer an open environment with freedom under responsibility, where you have the opportunity to grow professionally. Apply through LinkedIn, or get in touch directly if you would rather have a conversation before a formal application. We read everything ourselves. Your CV does not need a photo, your age or anything else that is not about your work. If there is a repository, a component library, a test plan, a bug report you are proud of, a design document or a postmortem that tells us more than a cover letter would, send that too. We review applications as they arrive. Where the role has a closing date, it is stated at the top of the ad. Otherwise the role stays open until we find the right person. We only work with recruitment and search firms under a written agreement, and we do not pay fees for candidates we did not ask for. Please do not send CVs to the hiring manager.