logo[мetahunt]
> Djinni

Automation QA Engineer

Upwind
company:Product
javaselenideseleniumrest-apiawsazuregoogle cloudlinuxjira
kubernetesterraformcloudformationsqlci/cd
domainCyberSec
> full description

Java · Selenide · AWS / Azure / GCP · Kubernetes · Terraform · Runtime Threat Detection
 

About the role

Upwind is a runtime-powered cloud security platform. We protect customers' cloud environments across AWS, Azure, and GCP — from the moment an account is onboarded, through vulnerability and image scanning, CSPM and compliance, identity and inventory correctness, all the way to runtime threat detection.
 

You will own quality for a set of product areas end to end: writing and running the manual test plans, building and maintaining the UI automation that keeps them from regressing, and being the person who finds the problem before a customer does. You sit inside a feature squad next to the backend and frontend owners, not downstream of them.
 

This is a hands-on role with a real learning curve on the cloud-security domain. We expect you to grow into it, and we will support that.
 

What you'll actually do

Manual testing & test design

  • Build test plans for new features — onboarding flows, dashboards, scanners, integrations — and turn them into structured, prioritized test cases (P0/P1/P2) with clear preconditions, steps, and exit criteria.
  • Run feature-level manual QA cycles: validate acceptance criteria against the PRD, verify each functional requirement, sign off before go-live.
  • Run regression and retest sweeps ahead of releases, and verify fixes on dev before they move forward.
     

Bug reporting

  • File bugs that engineers can act on immediately: summary, exact reproduction steps, expected vs actual, impact, environment, and evidence (HTTP requests/responses, Terraform or Helm output, console links, screenshots).
  • Triage bug clusters by root cause and link related issues, rather than filing ten tickets for one underlying defect.
  • Escalate customer-impacting findings clearly — especially anything that blocks onboarding or produces silent data inconsistency.
     

Automation

  • Write and maintain WebUI automated tests in Java + Selenide, extending an existing framework: new test cases, page objects, helpers, test data.
  • Grow automation coverage for the areas you test manually, so that manual effort shifts toward exploratory and new-feature work.
  • Keep the suite healthy — investigate failures, distinguish real defects from flakiness, and fix the flaky ones.
  • Push testability into the product: drive stable data-testid selectors and other conventions instead of depending on CSS classes, DOM structure, or text.
     

Cloud & hands-on environment work

  • Set up and tear down test environments yourself: onboard AWS accounts and organizations via CloudFormation and Terraform, onboard Azure tenants and GCP projects, and verify off-boarding actually cleans up.
  • Deploy and validate our sensors — the Upwind Operator on EKS via Helm, and host agents on EC2 instances.
  • Generate realistic QA workloads and verify the platform detects and displays them correctly.
  • Cross-check what the UI shows against the underlying data — backing stores, exports, and reports — to catch cases where the UI and reality disagree.
     

Collaboration

  • Work daily with backend and frontend engineers, product managers, and designers inside feature working groups (Slack channels, Figma, Confluence).
  • Keep test plans, test cases, and results documented in Jira and Confluence so anyone can pick up the state of a feature.
     

What we're looking for

Must have

  • Commercial experience in software QA covering both manual and automated testing.
  • Java — confident enough to read, extend, and debug an existing test codebase.
  • Hands-on experience with UI test automation (Selenide, Selenium, or a similar WebUI framework). Selenide specifically is a plus, but transferable experience is fine.
  • Solid test design fundamentals: equivalence classes, boundary values, negative testing, prioritization, and knowing what not to test.
  • Comfort with REST APIs and browser devtools — reading requests, responses, status codes, and payloads to pinpoint whether a bug is frontend, backend, or data.
  • Working knowledge of at least one major cloud provider (AWS, Azure, or GCP) — you can navigate a console, understand IAM basics, and follow an onboarding flow.
  • Basic Linux and CLI comfort: SSH, systemctl, log reading, running install scripts.
  • Git, and experience working in a Jira-based workflow.
  • English sufficient for daily written and spoken work with a distributed team.
     

Nice to have

  • Kubernetes fundamentals — enough to run kubectl, install a Helm chart, and read pod logs.
  • Terraform or CloudFormation exposure.
  • Background or genuine interest in cybersecurity: vulnerabilities and CVEs, CSPM, IAM, threat detection.
  • SQL or experience querying a data store (e.g. OpenSearch) to verify data independently of the UI.
  • CI/CD experience — running suites in a pipeline, reading build failures.
  • Experience testing in regulated or compliance-driven environments (FedRAMP, SOC 2, or similar).
     

What matters most to us

  • Curiosity about why something broke, not just that it broke. The best bugs on our board come with a diagnosis attached.
  • Ownership. You set up your own environments, you chase the answer, you follow the fix through to verification.
  • Precision in writing. A vague bug report costs the team a day; a good one saves it.
  • Willingness to learn cloud security fast. You don't need to arrive an expert — you do need to want to become one.

     

What you'll learn here

Real depth in cloud security across all three major providers, hands-on Kubernetes and infrastructure-as-code, a mature Java automation stack, and what it takes to ship a security platform trusted with production cloud environments.