Quality Assurance at Vinted Go Lockers


At Vinted the teams are structured in different ways. We have a unified organisational hierarchy across the company, but once we get to a team level, everything changes. Teams are free to organise themselves as they please. This is a story of how the Quality Assurance role in the Stardust team - the one responsible for the launch of the locker network - evolved.

First Months

Vinted Go Lockers began as a start-up company within company, with a limited number of team members, fast-paced delivery, and constantly changing requirements. We agreed that we would start with a Minimum Viable Product (MVP). This product development concept involved creating a simplified version of lockers, the Vinted Go Ops app, and Admin software, with the minimum essential features. We also decided to implement a manual testing process at the beginning.

The main benefits of manual testing were:

  • it was easy to adapt to constantly changing requirements;
  • the small scope of testing could be easily covered by manual testing;
  • manual testing provided quick feedback to the development team and other stakeholders, which allowed for rapid iteration and improvement;
  • no additional monitoring or maintenance was needed;
  • flexibility: software could be tested in various ways and environments;
  • we could check that the product was user-friendly by testing the software manually. A strong emphasis was placed on the user experience, which is critical for a company in the first stages of operations.

To ensure a successful product launch, we developed a manual testing plan, where the testing scope, strategy, resources, testing schedule, and risks were described.

Transition to Maturity

As the product grew, the product complexity grew as well. The transition from manual to automated testing became increasingly necessary for our development team. One of the main benefits of automated testing is the increased efficiency and speed of the testing process. Automated tests can be run much faster than manual tests. They can also be run as often as needed, reducing the risk of human error, and ensuring that the tests are consistent and easily repeatable. This leads to more reliable, accurate results and can help identify issues earlier in the development process; reducing the time and cost of fixing those issues later on. However, transitioning from manual to automated testing is not always straightforward. One of the main challenges is the investment required to create and maintain the automated tests. There’s also a need for specialised skills, such as programming and test automation expertise. Additionally, the complexity of software can make it difficult to automate certain types of tests, particularly those which require complex user interactions, or rely on third-party software functionality.

Stardust team’s transition from manual to automated testing was gradual:

  • Our QA engineers analysed Vinted’s existing test automation solutions, organised several meetings and workshops with Vinted test automation experts and developers, in order to better understand existing automation tools, techniques and best practices. For better maintenance and consistency, selecting tools which were already used within Vinted was one of the main priorities for VCarrier Admin automation.
  • The team analysed what parts of software could be covered by automated tests and which ones should remain manual. The decision was based on several main points such as:
    • business criticality - most critical functionality tests need to be covered first to ensure that these areas are thoroughly tested and defects are found as soon as possible;
    • repeatability - tests which need to be run many times should be considered for automated testing;
    • complexity - this should be taken into account when planning to automate tests. Not all tests can be automated. Points which need to be taken into consideration: how much time and effort will be needed in order to automate the test? Will results always be stable? Will third-party integrations be needed, and how could they influence the test results? Sometimes it’s not feasible to automate such tests;
    • maintenance - test automation maintenance is inescapable. Therefore automated tests need to be easy to maintain to ensure that software testing is as effective as possible.

Gradual implementation of automated testing minimises disruptions and gives the team time to learn and adjust to the new process.


We work on all the systems that are used by our customers, drivers, and sorting centre employees. Naturally, the most important part of the shipping process is the locker that holds the parcels before they’re picked up by a customer or a driver. The lockers are provided by a third-party company called ‘Bloq.it’, and the software is developed by them as well. As the communication between Vinted Go Lockers and Bloqit takes place online, QA is responsible for moderating the meetings, checking the task statuses which are on the board, and managing the front-end releases to the Production environment. After the release has been made, the board should be cleaned, the release cycle closed and new Future release preparation should be created. QA is also in charge of creating new tickets for Bloq.it, setting priorities and due dates. When changes are made, they should always be covered by acceptance testing. This is done by Stardust QA, which also provides the developing company with testing feedback. We’re planning to change this in the near future, by launching a front-end locker solution that is developed and designed in-house.

Pros of having our own front-end:

  • it makes communication between all team members easier, and feedback on testing results and requested changes is provided on the go, so developers can start making changes as soon as they’re informed;
  • lightweight UI;
  • will use our “Vintedish” architecture (React, Tailwind, Typescript, Vite.js);
  • overall faster development and release cycle.


Sometimes QA needs to test and more deeply analyse the issues that have been found. The Bloq.it Admin software is used in such cases. This software provides a more detailed view of lockers, cells and their usage.


Vinted Go Ops Releases

In the beginning we were using the Firebase App Tester to test the Vinted Go Ops application. QA was downloading the test version of the application and testing it throughly. After releasing the production version to Firebase, drivers and sorting centre employees were able to download it and use it. After evolving and growing further, the Vinted Go Ops application has started being released on Google Play. This has changed our release management process.

Current release process:

  • After the test version is deployed to the Firebase App Tester, QA downloads it to a mobile device and thoroughly tests all the new features.
  • After the new features of the application are tested, and the regression testing of all current features is done and testing is closed, QA is promoting the release and starting to release it to Production:
    • Information about the current release is filled in and the release is published. It takes a few hours for the release to be available in Production for drivers and sorting centre employees through Google Play.

Since the release to the Production environment is done by QA, the number of errors that could appear in the final product is minimised. This also saves developer and QA time and resources, because we eliminate the communication about successful testing from the release cycle process. Release of the application to the Production environment becomes the ownership of QA.

The release cycle is divided into several parts:

  • getting the test version;
  • testing it;
  • releasing to production.

If any bugs are found, they’re passed back to the developer and the process goes back to square one. In this case we’re decreasing the number of defects that could be unintentionally be passed to the Production environment.



After extensive research, it was decided to start writing automation tests for the following software parts:

  • VCarrier Backend (server-side components of a locker, sorting centre and driver application). The backend part is covered by unit and integration tests (API based E2E). Writing integration tests was a Stardust QA initiative. These tests are covered with RSpec. RSpec is a testing framework for Ruby that is designed to make testing simple, readable and maintainable. We agreed that integration tests will be a part of existing code, but separated into a different folder, called ‘request’. Integration tests are run every time a PR is created;
  • VCarrier Admin (web platform for sorting centre employees). Based on Vinted’s best practices, we decided to use TypeScript and Playwright for Admin Web test automation. VCarrier Admin web automated tests are currently running every two hours (between 6am and 6pm).

vcarrier admin

Future Perspective

With automated testing we’re willing to cover all critical business cases. We still do manual testing for locker software, the Vinted Go Ops app and end-to-end (E2E) testing as these tests are difficult or even impossible to automate. There are lots of different systems and moving parts in locker software and end2end testing, it would therefore be difficult to implement them and ensure stability of these automated tests. Nevertheless, more investigation is needed to figure out if it would be feasible to automate these tests. For our manual regression tests, we started using Zephyr Scale - a Jira test management tool that provides a centralised platform for managing tests, tracking progress and analysing results. We’re planning to move all manual regression tests there. Our current focus is to continue writing automated tests for Vcarrier Backend and Admin, as we’ve just recently started the transition from manual to automated testing. Also, as we’re working on a fast-growing project, the number of test cases that have to be covered with automated testing is growing day by day. Looking into the near future, we have big ambitions to start writing automated tests for the Vinted Go Ops application. This application is already big enough to be divided into three big modules: Lockers, Parcels, and Containers. Each module has its own flow and critical business cases that should be working at all times.

Summary and Conclusions

In conclusion, the freedom to choose the right testing approach and tool can have a significant impact on the success of the software development process. And as we’re taking steps to move from manual testing to automated testing, we’re confident that having automated tests will allow the company to scale its network much faster and will equip us to deliver high quality products and services to our end users. But in some cases, manual testing will remain present at all the time.