Why do we need state-transition diagram?
When testing focuses on a particular object states (for example, states of a ticket in an ticket booking application), a good practice is to draw a diagram of all the possible states and transitions between them, before starting writing tests. It could save testers from missing some transitions.

After diagram creation, it is time to start creating users' scenarios. We mostly are talking here about scenarios, not tests (i.e. paths from point A to point B without focusing on edge cases).

What typical mistakes could testers do in a state-transition diagram?
- To miss cycled arrows (where an action doesn't change the state)
- To miss start and finish (like here in this video). Without them, a tester doesn't know where to stop and where is the entry point.

In this workshop, students combined knowledge about every single test design method and tried to use them on a real task from a real interview.

If you get a task description for your interview or pre-interview check, this is what is expected from you in test design methods perspective:

- What test design methods are used and how?
- What test design methods cannot be used and why?
- Any non-functional testing that can be applied for the task? What tools to use and how?
- And the most crucial, and often missed: your answer should have a strict clear structure, both in the pre-interview check and directly on the interview.

The automation workshops are not for teaching students how to write on Java or use Selenium/TestNG or something, but to show them as future manual testers, what automation teams do and how to use scripts to make QA life easier. That's why we accept any errors and even AI help in writing their first scripts on Postman.

The exercise you see here, includes 2 steps:
- Look at the Java code (with mentor's detailed explanations and help)
- Try to write the same using Postman snippers.

At the end, they will not be automated testers, but will have some impression about the automation approach.

It is important for the tester to understand the difference between the methodologies in order to choose the right direction and work, taking into account the characteristics of his character, habits and individual speed of thinking. A Waterfall or hybrid model is more suitable for solid people who are not used to rushing, and Agile is more suitable for "sprinters" who love drive.

To choose between Agile and Waterfall is not always easy. There are plenty of parameters that should be taken into consideration. For example, a fixed budget is not for Agile, but flexible changes are not about Waterfall.

And of course it is hard for the freshers to define an appropriate approach, having no experience with any of them. But we try to at least get a surface impression about the difference between 2 approaches and ability to separate them in the future interviews, when an employer will talk about the methodology they have in the company.

Why is setting up a local repository and linking it to a remote important?

In QA work, version control is essential for managing test scripts, automation code, or documentation. Setting up a local repository and linking it to a remote (e.g., on GitHub or GitLab) allows you to collaborate with your team, track changes, and ensure your work is safely stored. This is a common task in real-world QA workflows, where you’ll frequently push updates to shared repositories or pull the latest changes from teammates.

What typical mistakes do students make when setting up and linking repositories?
- Forgetting to set the upstream branch with the -u flag during the first git push (e.g., git push -u origin main). This causes Git to not recognize the default remote branch, leading to errors or confusion, exactly as happened in this video.
- Not initializing the local repository with git init before attempting to add or commit files, resulting in “not a Git repository” errors.
- Incorrectly specifying the remote URL when running git remote add, which prevents a successful connection to the remote repository.

Why is building Docker images important?

In QA engineering, Docker is widely used to create consistent, reproducible environments for testing applications. Building Docker images from source code ensures that your testing environment mirrors production, reducing discrepancies and enabling reliable test results. This skill is critical for QA engineers working on CI/CD pipelines, where containers are built and deployed regularly to test new features or bug fixes. Mastering this process prepares you for real-world workflows where containerization streamlines testing and deployment.

What typical mistakes do students make when building Docker images?
- Incorrectly specifying the path to the Dockerfile in the docker build command. As seen in the video, students often forget to include the correct path (e.g., . for the current directory) or fail to navigate to the directory containing the Dockerfile before running the command, leading to “file not found” errors.
- Not cloning the GitHub repository properly or failing to verify that the Dockerfile exists in the downloaded source code directory.
- Overlooking the need to include a trailing . in the docker build command when the Dockerfile is in the current directory, causing the build to fail.

It was a complicated but fruitful internship for our group. Guys not only had got a lot of practice of testing challenging application with contemporary technologies like AI and no-SQL, but also drastically improved their soft skills working in an Agile environment. They also learned to communicate with developers, other testers, and product owner. I wish all of them the fastest employment!