SpaceWeb QA Engineers Hand Autotest Writing to AI: A Working Script in 50 Minutes

Every QA engineer knows this arithmetic: there are more features than hands, releases are on fire, and half the day goes to repetitive test cases and autotest "skeletons." SpaceWeb QA engineer Evgenia Myasnikova, together with R&D lead Vitaly Kireev, set out to find out how much of this routine can honestly be handed to an LLM, and where it simply generates filler that you end up rewriting by hand anyway.

Three tasks for AI and one important choice

The team did not try to automate everything at once. They took three areas: test documentation and data (positive, negative and boundary checks, test plans, checklists), automation scripts, and expanded security and API checks. The principle is simple: the AI produces a draft, and the tester reads, extends and debugs it.

The main practical choice concerned data. Because of sensitive information, the agent was connected to a local Qwen3.8-27B model. An internal assistant was used for documentation and code, and everything ran on the familiar stack: Postman, Python, Pytest and Selenium. If you work with closed-source code and internal API schemas, an external cloud is not required for this kind of work.

For forms, it looks like this. Preconditions, requirements for mandatory fields and validation are loaded into the model, and the output is a table of positive checks, followed by negative ones. For the GitHub/GitLab integration, the AI additionally singled out the most critical scenarios. For the API, the agent was given an example of a valid JSON for creating a VPS and asked to prepare data: minimal and reference requests, boundary values, Cyrillic domains, special characters and invalid cases such as creating a server in a non-existent region.

The output still has to be read carefully, though. In one example, a hostname is labeled "exactly 63 characters," but the string is noticeably longer, and a space has crept into an IPv6 address. For a boundary test this may be intentional, but it is safer to verify such things manually.

An autotest in under an hour

The most telling case is automating mailbox creation in the hosting control panel. The prompt is written step by step and contains everything the person at the screen knows: Pytest, Selenium, Chrome, authorization from conftest.py, exact selectors, password rules (8–20 characters, letters, digits, special characters) and the expected redirect to the review page. The model produced a ready-made test_mail_add.py with comments, explicit waits via WebDriverWait and result checks.

Then the task was made harder: the team asked to parametrize the test for different mailbox names. The result was two tests: test_create_valid_mail_box and test_reject_invalid_mail_box. The positive sets check lengths of 1 and 64 characters, special characters and digits. The negative ones check uppercase letters, spaces, a slash and a length of 65. If one case fails, it is immediately clear which scenario broke.

As for time: about 30 minutes went on the prompt and finding selectors, another 20 on debugging. It is not "press a button and done," but for a routine skeleton the result is good.

The limitations are visible in the code too. In the negative test the AI did not know how the system reacts to an error, so it proposed two options: either the frontend shows an error, or the form is submitted and there is no redirect. The second option was left commented out, and the behavior had to be clarified by a human. In addition, in the positive test a random suffix is appended to names that do not end in a digit. Because of it, the "exactly 64 characters" case turns into a name longer than the limit, so the boundary check effectively breaks. Only a review catches things like this.

IDOR: a start, but no results yet

The third case concerns API security. The task was to check for IDOR in the edit method (JSON-RPC): the service_ref field serves as a direct object identifier, and the server must verify whether the user has rights to it. The agent immediately proposed a basic check: send the same request with another user's service_ref. The team then asked it to write a Requests script that iterates over values from a TXT file containing identifiers of other users' services.

In the available part of the publication, the text breaks off at this step, so there are no final IDOR results here. It would be wrong to draw conclusions about whether the AI found real vulnerabilities.

What to take away in practice

• Give the model structured context: preconditions, the method schema, an example of valid JSON, concrete selectors. The quality of the result depends on the prompt.
• Treat the output as a draft. Check value boundaries, expected error behavior and locators.
• For sensitive data, deploy a local model: SpaceWeb showed that a working scenario is possible with one.
• Start with the routine: test cases, test data, UI test skeletons. That is where the savings are clearest.

The honest conclusion is this: AI does not replace the QA engineer, but it takes over the most mechanical part of the job. Quality control remains with the person who knows how the system should behave.