How can a manual tester understand an automation tester, and vice versa?

When we go abroad for vacation or meet a foreigner on the street who doesn’t speak Russian but is trying to ask, “Where is the restroom? How do I get to…”, we wonder how to explain things to them in Russian in a way they would understand.
I asked myself a similar question when trying to explain something to a colleague using SQL while they were working with Java. The main goal of my work was to create a quality test model. Without it, there would be no proper regression testing later on.
I started by building a framework filling it with test cases. We held a meeting where we discussed priority of positive and negative test cases briefly. When developing the test scenarios, I used the incremental model, but as practice showed, this approach also required an iterative method. For example, it is like having the outline of the Mona Lisa first, then adding colors, painting the background, and so on.
It’s better to maintain the checklist in Excel format to add columns, write notes, and more. And let’s not forget that, as we take on the role of Leonardo da Vinci, we use different colors and get creative.
I am a manager by profession specializating in Production Management. My motivator is the Theory of Constraints (TOC) methodology, which focuses on identifying and managing the key constraint of a system to determine the efficiency of the entire system as a whole:

• Buffer (reserve) — drum (rhythm) — rope (WIP constraint)

• The Critical Chain Method.

During development, I imagined myself as a little person who could only tie their shoelaces when the first person in the chain (the Project Manager) started doing so. Then with a drumroll… the PM moves to the end of the chain to see the results of the automated tests: 9/9, 8/9, 9/9 passed. There’s result stability — let’s move on.
I agree that the work doubled, but we managed. My colleague, who has Java knowledge, motivated me to study the language. This reduced meeting times to 15-30 minutes.

Here’s a list of internal communication rules between my Java specialist colleague and me, which I recommend:

1. Don’t hide information from colleagues. It’s better to calculate risks and plan ahead rather than deal with everything when it’s on fire.

2. Keep your promises. Your word is your reputation, and respect for you depends on it. It’s helpful to put yourself in others’ shoes and ask, “If this were done to me, how would I react?” It’s a sobering thought.

3. Be ready to listen.

4. Don’t tell others what to do. If you don’t like how they do it, try giving constructive feedback. But if the problem is constant, maybe it’s not about the people.

5. Don’t compare. Everyone has different starting points, niches, and audiences. Statements like “But she did that, he did this, and I wasn’t invited there” leads nowhere. Compare yourself only with yourself: six months ago, three months ago, a month ago – and now. You’re on your path; others are on theirs! Focus only on yourself.

6. If you don’t understand, ask. Most problems stem from a lack of information. We start to overthink, doubt, and get angry at ourselves and those around us. Sometimes we just have different conceptual frameworks, logic, and thinking methods. That’s normal – we’re all different. So let’s just communicate! If something’s unclear, ask; if it causes concern, discuss it.

Now, let’s dive deeper…

My Action model describes the actions a user can take with the product, so I constantly updated the set of manual test cases sprint by sprint, checking all the tasks that went to production. According to best practices, test cases should be built in 7-9 steps.

My Assert model describes the system’s reactions and the user’s results. Here the speed should be like driving into a town — no more than 60 km/h. Let’s remember that there are kids with scooters and bicycles, and the older Kafka functionality, barely handles processing millions of messages. This is when meetings become more frequent – the honeymoon phase, romance, albeit online. It’s still nice to receive a bouquet from a colleague with words like “precise” and “great”.

After such meetings, we maintain a calendar where we mark meetings and add smiley faces with themes like “needs improvement,” “to do,” “think about…,” and so on.

With this understanding, we can create links between test cases for a complete test scenario:

• High priority: positive test cases.

• Medium priority: role-playing test cases, where different roles can be tried, not just what’s written in the requirements.

• Low priority: negative test cases.

Analytical thinking is needed here, as these test cases are the most challenging. This is where the romance ends, and real work begins.

The monitoring of automated test launches can be visualized in a diagram.