DEV Community: inDrive.Tech

C4 Models: Architecture From Simple To Complex

inDrive.Tech — Fri, 07 Oct 2022 08:59:44 +0000

Software Architect from inDrive Alexander tells about how to define the architecture in a better way and shares his experience in C4 models usage.

Real life architecture

If you open Wikipedia, you will find there the exact definition of what architecture is. I found out that architecture is the process of creating and drawing certain diagrams, certain buildings, and other structures. People use architecture as a science to simplify complex designs such as bridges or buildings.

In real life, architecture surrounds us everywhere. Even the room you're in right now is part of the architecture. It has windows, doors, and places to sit. And in real life, architecture has many standards. We can rely on standards to define our architecture and share this information with our peers. For example, from building components to who will create this building. The really good part about this architecture is that we can get down to very small details, like how to create this particular wall or how to create this particular room.

Architecture in IT

Paper

When it comes to IT, building an application architecture is like building a building. And in the beginning, we, like real architects, used the traditional way of creating architecture - we drew on plain paper. This method is good in that it improves the creativity used to brainstorm changes in our architecture, but at the same time it is very difficult to maintain.

On paper, it is difficult to capture the standards that are extremely important for any architecture. We have many paths displayed as small blocks connected by lines that were not standards at all. When we are going to fit a lot of details into this picture or understand what is going on at one level or another, it is very problematic. Then we replaced the paper with the draw.io tool at the request of the system administrator.

Draw.io

Draw.io was a nice try. In draw.io, at the beginning, you can draw the desired picture, and then connect the blocks with lines. If we have many components or many connections or relationships between components, then at some point it will be very problematic to set up this diagram. For example, imagine what happens if we want to move a PHP component from a central location to another

If you need to move to a separate data center, it will require a lot of work to update everything. It's very difficult to understand how everything works in general, because we have completed pictures, we have a lot of details and usually we can't present this diagram to non-IT colleagues. If you want to provide this diagram to senior management, obviously they won't understand what's going on in the diagram.

Miro

Another attempt is better. It's a Miro way, let's say. I like Miro because of very cool zooming feature, which is available by default in Miro. We can drill into our parts and see what's happening inside zooming into particular blocks. It's still partially maintained well because if we want to rearrange some parts or create some new components, then you will be required to draw all new lines, adjust the layout.

I guess it's annoying because, at some point in time, I will spend too much time just connecting small parts with each other. At some point, I guess this process will not be maintainable and require some energy from analysts to keep it up to date. Let's see how we can do it in a more standard way. I'm going to present you with a C4 model. This model was designed to simplify the process of designing architecture by describing the picture.

C4 Models

On a very high level, we have this software system definition is used to describe systems in general. Then we have several more layers. Usually, we have more layers, which are containers, components, and the last one is code. On each layer we can define our architecture with more details. It's kind of zooming into our architecture.

How it works

You can see that we have this context in the very top of the picture. If we click or select our central component which is the system, we can read or zoom into the container level where we can see more details which containers are required to run our application. How containers are connected between each other and what our external system is. On level three, we have an even more detailed picture.

For example, different processes running inside our single container can be producers, subscribers, this can be Google, or something like that. On level four, we can have a well-built picture of a particular component with maybe UML diagrams of processes or database models. Okay, let's check what's happening inside. If we are talking about our first layer, which is system context, we are trying to represent our system as a very big block.

Usually, blocks are presented to these boxes and we have links between such boxes. Usually, we describe only systems which are part of our application or system context. In this case, we are looking at some banking systems and we have just a mainframe banking system which stores information about customers account transactions, et cetera. We do not specify any database names, types, MySQL or Oracle, etc.

We don't want to have any technical details on this level, just because we want to make this diagram available for everyone. Every person, even non-technical people should understand what's happening in the system. We can see the banking system uses an email system which is external one and just sends email using this system and stores information about payments in the banking system mainframe.

Obviously, we have a customer who uses our systems and calls our API. Next level is more interesting for us, especially in IT. The community is a container diagram and we can see much more details here on this picture. In the diagram, there is information about containers which are required in order to run our application and we can see that now we have details about protocols. We usually use this information to understand what kind of dependencies, and what kind of protocols are used by this particular system.

C2 levelThis information can help us to understand better requirements of how we can scale our application, how we can deploy this application to a new data center, and this information is most important for us because we have all necessary links, all necessary information about all containers which are required to run the application on this container diagram.

Every container, do not confuse, it's not a docker container, it's a separate application that should be presented on the scheme because we want to understand how every container is connected with our application in order to make it scalable or we can think about how we can protect personal data about our customers. What if we are going on the next level which is C3 and it's a component diagram?

On this level, we can present even more details compared to component diagrams and we can show internal parts of our application. For example, if you are talking about Go applications this can be a dedicated group of goroutines, consumers for Kafka or producers to Kafka. We can show some specific components like HTTP handle or maybe gRPC handle. We can show different protocols as well on this diagram like HTTPS or gRPC between some parts.

We can show integration between controls itself and we can also present some external systems like an email system which is called by email component and we can present information about a database as well. There is information about type. In this case, we are using Oracle database and this diagram presents all necessary information about all blocks. If we go to the last level which is C4, we can drill up to very low-level details, how our component is working and this can be entity relation diagram, this can be email process or activity diagram.

In the the billing service and we have created order, canceled order, and changed order defines it, and how particular containers or components are connected to each other. What I like in this way of describing architecture is that we can go from the very high definition of our application up to very low-level details which is really important in order to make our diagrams easy to read, easy to follow, and here is our current process.

We have this inDrive architecture docs repository and currently, I'm trying to create C1 and C2 levels of all our components, and probably you have already checked it. You can claim it, you can use it with ideas, you can install the PlantUML plugin for your idea and just navigate through all components in real-time by clicking on components and you will drill down from the system context diagram up to internal details.

UX Writer and Copywriter Roles in the Multiverse of Madness

inDrive.Tech — Wed, 07 Sep 2022 10:07:33 +0000

In this article, Lisa, UX writer at inDriver answers the question: ‘Why are there two writers for one product?’

UX writer (UXW) and copywriter (CW) are two different professions. They are often mixed up for one simple reason: these professions have the same work tool — the text.

Leveraging this tool, copywriters create an enchanting universe, while UX writers put things in order there. In this UX-driven universe, it’s impossible to get lost, fail a task, feel puzzled or helpless.

A copywriter and UX writer are not interchangeable: they have different experiences, goals, and workflows. Without one of them, the universe will either lose its beauty and charm, or become inconvenient. Why can’t one specialist write all the texts?

I’m Lisa, a UX writer in the inDriver product team. In this article, I present all the differences between UX writers and copywriters in points and pictures.

Text in the hands of UX writer and copywriter
Goals of the product text and marketing text
Who is responsible for which texts
What are the similarities between UX writers and copywriters
What is the difference between UX writers and copywriters
Collaborative work
If you choose your way to work with texts

Text in the hands of UX writer and copywriter

How the same working tool differs in the hands of different specialists

Concise — Vivid

UXW: UX writing, or product writing, is what a UX writer does. These texts are also called microcopy. There are many of them in IT products, and they help a person reach a goal without drawing attention to the copy. If the microcopy is concise and people don’t specifically focus on it, then it’s not distracting or annoying.

CW: Contrary to the above, copywriting, or marketing texts, should attract attention, highlight the brand, be bright and memorable. People read marketing texts in specific situations, so the marketing copy should be bright, but not intrusive.

Supportive — Separate
UXW: Since UX writing is part of the user experience, it should be supportive. The name of the button should clearly explain where the person will go when they press this button, and the microcopy of the error should suggest what happened and what to do next.

CW: Marketing texts are, most often, independent. For example, slogans are remembered and perceived on their own, without any context: a person may not even remember where they read it.

Consistent — Offbeat

UXW: Consistency in microcopy helps to boost the user experience. A person does not have to read the text, as the consistent structure makes it scannable. The use of the same words for the same entities makes the texts recognizable, so these names don’t have to be memorized.

CW: As an example of marketing texts, slogans must be offbeat, so the reader does not have associations with other firms’ slogans, and the brand’s reputation remains unscathed.

Goals of the product text and marketing text

What goals does the UX writer’s text and the copywriter’s text fulfill

Earn trust — Engage

UXW: The primary goal of UX writing is to earn the trust of a person and ensure retention. A person reads microcopy inside the product, so product texts are calm and informative. As part of the product, it makes people’s lives easier, while being in line with the user experience.

CW: A copywriter, on the other hand, writes a marketing text to engage a person — in a competent manner, with no hype or comparisons with the competition. The latter technique may attract attention, but it also creates an impression that the company wants to stand out at the expense of others, or copy their ideas from the competitors.

Build relationships — Make an impression

UXW: With the help of microcopy, the UX writer builds a long-term relationship with the product users, so they feel they’ve made the right choice, and their first impression was not deceptive.

CW: Most often, people get their first impression about a brand from marketing texts: these texts should encourage people to use the product and remain happy about it.

Respect a personal space — Get an emotional response

UXW: In UX writing, it’s critical to understand the audience and business values, yet the key concept here is empathy. Empathy means respect for a person and their personal space. Since we build long-term relationships with the aid of microcopy, we cannot evoke an emotional response from people throughout our communication: people will simply get tired of it. Sometimes we can see this mistake on button texts. Instead of helping a person quickly navigate onwards, an overly creative UX writer would make a mistake naming the button ‘Wow, what’s next?’

CW: One way to make the right first impression with marketing text is to decide what kind of emotional response we want to get from a person. We find examples in ads: some of them cause sadness, others — tenderness or laughter. All this is an emotional response. For example, a marketing text may appeal to nostalgia or tenderness: ‘Any distance can be overcome when you love.’ Or it can be inspiring: ‘Spend a year so that its results get a million likes.’ The main thing is to know who you are writing for, who will read this text. You also need to know who we want to attract to the product, and what will be the benefit of this audience for the business.

Who is responsible for which texts

Comparable examples of UX writing and copywriting

Header — Slogan

UXW: Microcopy is a small block of text that helps a person to navigate within a product: on a website, in an app, or through any interface. Of course, headers are also considered microcopy. Their goal is to unambiguously reflect the main idea of the content on the page.

CW: The slogans of copywriters are more ambitious: they succinctly reflect the values of the company.

Instruction — Longread

UXW: Instructions by UX writers are well structured and help a person to navigate in a complex or long process: most often, such instructions are stored in an FAQ section.

CW: Copywriters’ longreads are also long text blocks, which, unlike instructions, do not give a person an idea of how to use the product. Instead, they give an idea of how the product will improve their life, boost their social status or self-confidence. Adhering to the goals of a marketing text, longreads will impress and evoke an emotional response.

Onboarding — Presentation

UXW: In a product, onboarding is a brief and structured introduction. Good onboarding doesn’t aim to impress people, bad onboarding is always bewildering or irritating. Sometimes, onboarding is used carelessly, as a copy of other companies’ practices. In fact, a good onboarding should be unique. It should show how this particular product will make a person’s life more comfortable, and what a person can do to gain this comfort by themselves, i.e. how they can turn our product into a tool that makes their lives better.

CW: A marketing presentation highlights the benefits of a product, how we want people to perceive us. Perception doesn’t always match up with reality, yet a professional copywriter isn’t afraid to describe flaws. Using the right words, a copywriter can tell an honest story about a brand and the people who develop it.

What are the similarities between UX writers and copywriters

Points that UX writers and copywriters have in common

Audience and product expertise

Both professions must know their audience: what the clients want and why they come to use the product. Since a UX writer and copywriter write for a brand, they know how the product works. Of course, knowing the audience and the product is crucial not only for these two professions. Anyone who communicates with people through any kind of text should think in these terms.

Experience in writing

The more specialists are immersed in their fields, the more they write and explore, the better they feel and manage the language. The same happens with attention to detail: over time, it becomes easier to pinpoint typos. Anyway, using the tools to check your texts, especially the long ones, is a must.

Collaboration with designers

Since a copywriter creates compelling copy, designing it visually becomes an important task. Designers make it visually engaging. Design also matters in UX texts. For instance, without design buttons just look like unclickable text, causing gaps in the user experience.

What is the difference between UX writers and copywriters

The main differences between the two professions

Reason behind every word — Focus on the taste

UXW: UX writers must understand why this piece of microcopy is the best possible. UX writers are always objective: if the text is regarded to be faulty, the UX writer should have strong counterarguments — or microcopy has to be rewritten.

CW: Copywriters focus on people’s feelings and emotions. They rely on the tastes of the audience and on the team’s opinion. The key questions here are: Is the wording appropriate? What feelings can it evoke in a person? What feelings do we want to evoke in them? If everything matches, the copywriter’s text is ready to be published.

Join the project at the beginning — Join at any stage

UXW: The process of creating a product isn’t complete without UX writing. The earlier UX writers are involved in the process, the less work is spent on changing blocks, screens and entire flows where microcopy isn’t needed, or a completely different format is needed, or a different order is due.

CW: A copywriter joins when the product is already formed, and its advantages are clear and obvious.

Define the tone of voice and style guide — Follows the customer requirements

UXW: UX writers and copywriters have different workflows: UX writers specify the rules and voice of the texts that all texts in the product follow. The same voice is also used on all platforms within the company: support, stores, landing pages, social networks, and so on.

CW: Copywriters’ texts also stick with the brand guidelines, yet their tone of communication is more emotional.

Team workers — Work on their own

UXW: UX writers don’t create the product UX on their own. Microcopy is created directly in the designers’ layouts, the product manager coordinates the process and developers make it work. UX writers need to communicate and exchange opinions with different teams.

CW: Copywriters can work on their own, focusing on the brand voice, and simply provide the complete text to the designer. Of course, teamwork is always better, but not always as necessary as within the product.

Product team — Marketing team
Apparently, product and marketing texts are created by people from two different teams: product and marketing. When copywriters write interface texts, or UX writers create marketing texts, it breaks the entire process: the text stands out where it should hardly be noticed, or understates something that should catch the eye. Don’t fall into this trap. Better show this article to your manager and explain why the company should have at least two different text specialists.

Collaborative work

Since the UX writer works in the product team and the copywriter in the marketing team, they don’t meet each other too often. However, both specialists follow the same tone of voice, focusing on different tones of communication within this voice. In marketing, the tone is rather personal and even bold, in microcopy it’s calm and reassuring.

That being said, a UX writer and a copywriter do have room for cooperation. For instance, in landing page content. Scenario one: the copywriter writes the content for the page according to the ready-made structure and asks the UX writer to proofread the terms and verify the style guide compliance. Scenario two: the UX writer prepares the structure, writes the content and passes it on to the copywriter for slogans and headlines.

Overlaps do happen on different stages and customers do not always understand who should write which text. For example, push notifications can be both promotional and informative. The former are written by copywriters, the latter — by UX writers.

Within the same company, copywriters and UX writers should align to follow the same brand style. Users want consistency. You can’t treat the user as your bestie in a marketing text and communicate with them like a robot in a product text. The brand persona would simply fall apart, and the clients’ trust would be shattered.

The same will happen if a marketing text exaggerates the product’s ease of use. An announcement that the product is accessible in a ‘couple of clicks’ appears confusing for UX writers. It’s simply impossible to shorten the registration process because of the catchy words on the banner.

People encounter marketing texts first, and microcopy second. Inside a company, the process works the other way: from the product to marketing. You need to write slogans about a specific product, and not adjust the product to fit the slogans. Seems obvious, but better keep the workflow right to avoid further screw ups.

How to choose your path

If you wish to understand which profession is in your line, go back to the format and goals of the text. See what texts you like to write more, what works better for you, what kind of thinking you have.

I chose UX, because UX means care. Everything a UX writer does helps a person get familiar with the tech, save their time and effort, and make their life a little easier.

If you want to work with microcopy as a UX writer:

Forget the pay-per-character model: the volume of work a UX writer performs and the amount of texts that go into production do not correlate.
Study the subject matter and useful software: Figma is good for starters, but there’s more to it.
Write and practice on the interfaces that you see daily, pay attention to microcopy and the UX in general.
Be ready to substantiate every little piece of your work: this is one of the key UX writer’s skills.
Be empathic and scrupulous.

The demand for UX writers is surging, yet UX writers still have to defend their right to exist — like copywriters before.

Copywriters dispelled the prejudices about their profession, and marketing texts took their deserved place in business development.

UX writers are also headed in this direction. Businesses are becoming increasingly aware of UX writing and its role as a crucial layer between the customer and the product.

True Product Backlog Refinement: 4 stages to the correct work on features

inDrive.Tech — Fri, 02 Sep 2022 11:26:44 +0000

In this article, Agile Coach from inDriver Ekaterina Kolesnikova will share the experience of conducting PBR without any boring theory about “correct” planning.

When I joined the team, I noticed problems in the Product Backlog Refinement process. I proposed a new scenario for this process and it worked. I’m sure many of the problems I encountered are familiar to you.

Crushing expert opinion. One person spoke on PBR: Tech Lead, Senior, Product Owner or other leader. The rest of the team members remained in quiet agreement, did not express an opinion, were poorly involved and did not understand the task.
We’ll sort it later. Tasks were only specified after the start of the sprint.
Tasks in Jira without a description. There was no documentation or parsing.
No assessment. The sprint planning was chaotic, and the results were difficult to predict.
No product or technical decomposition. They didn’t know what they were doing.

The scenario that I propose is suitable for a product team of eight people. The PBR process itself was divided into four stages:

Stage 0. Get it all done in advance

At least three days, and preferably a week before the PBR, the Product Owner sends information about the features that we would like to start work on. The development team looks over the information, prepares questions and offers solutions in advance. This greatly reduces the meeting time.

At this stage, it becomes clear which tasks are simple, and which will definitely take a lot of time to work out. This helps to better plan the timing of the upcoming PBR. To save time, simple tasks can be graded asynchronously and compared at the meeting. If the team is not new colleagues may come to the same conclusion, and the discussion of such problems takes a maximum of 10 minutes.

Artifacts and feature documentation include:

The user problem we are solving.
A hypothesis to solve this problem.
Results of the research or experiment that support this hypothesis.
The target audience of the feature.
Product metrics we want to influence.
Layouts.
User Story Mapping (USM), Customer Journey Map (СJM).
Keys for conversions (if necessary).
Analytics events to add.
Product decomposition and task description.

It is good practice to have detailed items in the product backlog at least two sprints ahead. This simplifies sprint planning as the Product Owner and Scrum team start planning with a clear, well-analyzed, and accurately evaluated set of user stories.

If the task falls into the sprint without a PBR, the sprint planning stretches in time, raises many questions, requires clarifications and/or leads to inconsistencies.

Stage 1. Product challenge

The Discovery Team, in our case, this is the Product Owner, Analyst, Designer, Technical Leader and business representatives, once again personally tell us about the stories that we would like to start work on.

The product challenge should take no more than 30 minutes. We discuss features from the point of view of the product (“what are we doing?”, “why are we doing it?”).

People ask pre-prepared questions. During the discussion, we write out new problems, risks and barriers to the implementation of the feature that cannot be solved quickly. When the product challenge ends, the Development Team looks at all of this and makes a decision:

To postpone further work until the Discovery Team resolves the issues that have arisen. In this case, we assign a new product challenge.
To continue the PBR process if the outstanding issues are not critical. In this case, the DevTeam may:

Drill down a feature discussion with the whole team (not the best way in terms of interaction efficiency).
Select a working group (a cross-functional team whose competencies allow it to fully work out the technical implementation of the feature).
Select several working groups (feature teams) so that each team tackles several decomposed user stories from one big feature. After the work is completed, the feature teams present the selected solutions to each other.

In my opinion, the last option is ideal for a team of eight or more people. We broke up so that each feature team had one representative from the platform. This helped to involve all participants and speed up the development of features.

Depending on the chosen work format and the complexity of the discussed feature, the DevTeam may:

Start a technical elaboration within the current meeting (no more than 50 minutes).
Agree on follow-up work (a new meeting or asynchronous mode of work via instant messenger — the team chooses any format that suits them).

The visually described Product Challenge process looks like this:

Stage 2. Technical challenge

DevTeam works on decomposed features in one of these formats: the whole team, a working group, or several feature teams. One important condition: in any format, the technical team is cross-functional, autonomous and empowered to make decisions on its own. Product Lead, TechLead, Product Designer and Scrum Master can participate in the technical challenge as external experts at the request of the team.

A checklist of questions that will help the team with the analysis of the problem on PBR:

How many modules are affected by the task?
How many external interactions and dependencies are there: contract formed with backend, work with other teams, top-level architecture worked out.
How many internal interactions are there?
Technical decomposition.
Estimated story points (complexity, volume, risks), did testing take these into account? Do you have time for conversions?
Risks. What can go wrong? What is the worst case scenario?
Acceptance Criteria (AC).
Definition of Ready (DoR) control.

You can also use the DoR checklist for all product teams:

Is there a description or presentation for the task?
Are there Acceptance Criteria (AC)?
Is there a Story Point (SP) estimate?
Are there User Interface (UI) layouts?
Are there analytical metrics?
Are there localization keys if needed?

The technical challenge lasts 50 minutes if the team continues the Product Challenge meeting, or around an hour and a half if it is a separate meeting. The duration also depends on the complexity of the feature.

If the feature team can’t “buff” the feature in less than an hour and a half, it means that the feature was badly decomposed. This is worth discussing in retrospect.

Stage 3: Final challenge

This is a general event lasting no more than 30 minutes, in which feature teams present each to other (if they have been separated), the product lead, the technical lead and the designer, the technical solution of the feature.

The purpose of this stage is to get approval from the above participants on the further implementation of the feature within the next sprints, and also to sync up if several teams have been working on the features.

During the discussion, the team checks each feature according to DoR and parks the questions that have arisen during the meeting on a separate board. At the end, we make a decision: the feature is ready for the sprint (converted into Ready for development) or additional clarifications/discussions are needed. Also one responsible person is selected who will transfer all information from Miro to Jira.

What the participants say

I spoke with the participants in our PBR experiment. Here is some feedback from my team members:

Backend developer

Before, the analysis of what the business wants did not allow for discussion of any points. And this entailed task changes on the fly. When we started discussing a task at PBR, because the team was so large, it turned into a story that wasted quite a lot of time and lowered the quality of internal communication. Now, when we divide the meeting into relatively small teams, everything works fairly well, but there are always moments that we want to improve.

QA engineer

Pros:

Understanding the essence of the tasks before development.
Documentation testing has become the responsibility of the team, not the testers.
The priority of the tasks became apparent.
Everyone could express their “essence [’fe’ in Armenian’]”.

Cons:

Takes time.
Forced to think.

Android developer

Before the arrival of Agile Coach, we had no idea what story points were and that tasks should be evaluated! Because of this we had sprints for 1–2 months without results. There were no discussions, it was more like “there are problems here, okay let’s take a look”. Thanks to the facilitator’s brain cells, a meeting structure has appeared. We now understand that we can assess everything, and then plan a sprint.

Product Owner

There was unpredictable development, there was no understanding of the timing for the development of several tasks — fixed, except for a few exceptions.
Missing the development timeline — fixed, I think we hit 80%.
Only a few people participated in the discussion — fixed.
There was no common understanding of task assessment — plus or minus, you need to keep recalibrating
There was no preparation for the PBR and no involvement in the discussion. The team did not take responsibility for the task — now everyone is involved, but sometimes they perform more formally.
The task processing quality has improved.

How to cut the release inspection time from 4 days to 4 hours

inDrive.Tech — Tue, 09 Aug 2022 12:38:23 +0000

In this article we’re going to tell you about how inDriver’s release team cut the duration of regression testing for the release build of a mobile app, and the release cycle, to one week, about the problems they came up against and about how they solved them.

Some background information

In 2018, the release team was significantly smaller than it is now, releases were not yet happening regularly and all of the company’s QA-engineers played a part in the pre-launch inspection. That was very time-consuming, though, and it slowed down the overall development process significantly. It was decided that the testing of each app released would be conducted solely by the release team.

Back then, the release cycles lasted 2 weeks. The team had 3 QA engineers, who weekly for 2–3 full-time days checked the release build of one of the alternating platforms. In addition to checking the release, the guys were busy streamlining the release process, writing documentation, onboarding newcomers, and updating test cases in the TMS.

There were a number of drawbacks with this approach:

Defects could only be discovered during the 2–3 days of the check, so more time was required to fix them and the Time-to-Market (TTM) increased.
If anyone in the team was unable to take part in the testing of the release, the workload on the other team members was significantly greater, and so too was the time required for the check.
Long release checks are tedious, and the likelihood of a defect being missed increases.
There is a low level of coverage across devices, meaning that specific defects were more likely to be missed.
During the check, you had to get to grips with all the new features and the ways of configuring the test environment to suit them. The test cases and other documentation therefore have to be perfectly written, before the point when the feature gets into the release. Otherwise, the inspection process would be slowed down: a lot of time would be wasted clarifying all the nuances.

Changing the release inspection process

At the end of 2021, the decision was taken to scale up the release check to the QA engineers from all teams. And it was decided that, from 2022 onwards, we would move to weekly checks of both the mobile platforms at the same time, and stop doing the TMS TestRail in favor of Qase, since the former was very slow and kept going down.

Since the automatic branch cuts and the forming of the release builds for the mobile app used to take place on a Friday evening, Monday was chosen as the most suitable day for checking the release. The tech leads in each team knew that, for 4 hours on a Monday, the QA engineers would be working solely on the release check. For those 4 hours, the tech leads had to remove, or at least minimize, any team activities in which the QA engineer was supposed to be involved.

In turn, by the time the check started, the release team would prepare a relevant test environment, form the test runs and distribute them to all the cases. The aforementioned problems were thereby solved:

All the bug reports are compiled in the first 4 hours of a Monday, and, accordingly, the fixes are put into the release build at a much earlier stage.
If a couple of QA engineers are unable to take part in the release check, this has practically no impact on how quickly the release check can be conducted.
The release check does not take more than 4 hours — and it’s much easier to maintain one’s concentration and alertness for that kind of time interval.
The level of coverage across devices goes up several times over.
Certain very specific new features are initially checked by their “owners”, and then gradually rolled out across the entire team.

The release team also writes UI self-tests, in conjunction with the QA Automation team, which develops various testing instruments. To achieve this, the following tools are used:

Appium.
Kotlin, JUnit 5.
Selenoid.
Allure.

The upshot

At this point in time, UI tests have covered about 30 percent of the total test cases in the acceptance set. They are launched immediately after the cut on the release branch, and the result of them, in the shape of an Allure-report, is sent to Slack by a bot. As this automated process unfolds, the test cases are taken out of the release run’s pool. During the release check, the QA engineer on duty goes through the fallen tests manually, and, where necessary, compiles a bug-report:

In order to keep the tests green and discover bugs ahead of time, they are launched on a dev-build every night. After that, the duty QA enters the new test update tasks or bug-reports on a special dashboard. A range of tests can also be launched by anyone who wishes to do so with the help of GitHub Actions:

As a result of the changes set out above, the duration of build release checks has fallen from around 72 hours to 4 hours, without sacrificing anything in terms of the quality of the product.

One of the problems that the release team encountered was that of time zones. Our staff are located in a wide range of different cities and countries, making it far from easy to conduct a simultaneous release check. However, given that most of the engineers are located in three time zones, it was decided that the time of the check should be made as close as possible, taking everyone’s work schedule into account. In Almaty, for instance, the release check starts first thing in the morning.

Another problem is related to the fact that, in order to get a large number of engineers involved in the same process, particular effort is required on the organizational front:

Drawing up lists of the people who are going to take part in the release, taking vacations and days off into account.
Redistributing cases in the release process, if anyone has had any problems getting through them.
Checking and preparing the test environment in good time, and doing the same thing with the methods of delivering the app build, so that there is no downtime.
Checking to make sure that the developers promptly set to work on any defects discovered in the release build.
Answering any questions that arise on the part of those involved in the process and dealing with any unexpected situations.

To solve this problem, a flow of weekly duties was introduced by one of the QA engineers in the release team, who assumes responsibility for all the duties referred to above and independently accompanies the release from beginning to end.

In the first instance, it was hard to work out how long the release check was going to take. To calibrate its duration, the progress on the cases it is going through is recorded at hourly intervals. It turned out that an interval of 4 hours was ideally suited to the task, and enabled everyone to go through the release at a comfortable pace.

Thereafter, the release team left in the flow a requirement to note the release’s progress. The table below shows the percentage of cases from the release run that have been completed, at a particular stage of the release check. It can be seen that the total time spent on the check gradually falls:

Now, the time required to check a release version of the app is gradually falling. With the transition to this flow, the TTM of product features was significantly reduced, and at the same time the quality of the check was enhanced. The release process, meanwhile, became more predictable and transparent for all the other teams.

10 items that must be addressed during a one-on-one meeting

inDrive.Tech — Mon, 01 Aug 2022 10:19:40 +0000

The one-on-one meeting is one of the most valuable tools for communicating with an employee, especially when working remotely. Here, we highlight 10 items that must be addressed during a one-on-one meeting.

Turn your webcam on and ask your employee also to turn theirs on. Pour yourself some tea, coffee, or water to deal with a dry mouth if you have to. And make sure you smile.
Small talk. A brief exchange on an unrelated matter is needed to make sure you both are tuned in and on the same page. For example, you can give the other person a compliment, say something nice about their hoodie, cool glasses, their Google Meet background or the view out the window, and so on. Yes, these are trivial things, but they go a long way to contributing to an overall pleasant vibe and bringing a smile to the other person’s face.
Ask about how things are going for them and how the sprint went. Watch closely as the person talks about issues they have encountered in the past week.
Ask how things are going with the team and the team lead.
Discuss your employee’s concerns. Don’t interrupt them, and let them fill you in on all the key details.
Check in to make sure the employee has been able to look at the agenda you had prepared for this meeting. If not, go over the highlights once again.
Share the news or important announcements you have to discuss. This item is optional, as you might have nothing to share for this particular week :)
Ask the employee what they think about the news and important announcements you just brought up. Find out how your employee feels about this new information.
At the very end of the session, check if the employee has any questions left to ask, and whether they are clear on everything you have discussed. Make sure you both are on the same page on all key points of the agenda.
End the call with a smile and wish your employee a great day.

Additionally, below we will highlight several crucial points that a manager should bear in mind during a one-on-one meeting so as to establish a relationship of trust with the employees.

Important point #1. I recommend one-on-one meetings be conducted not only with the employee, but also with their team lead or product lead. From them, you can learn how the employee behaves within the team, as well as get feedback on their performance. The team lead or product lead may be able to shed light on details that may have slipped under the manager’s radar.

Important point #2. During a one-on-one conversation, neither the employee nor the supervisor should be distracted by any chats, parallel incoming calls, or other unrelated tasks. If your employee is distracted in this way, stress to them the importance of the discussion and explain that it would be great if they could focus their undivided attention on the conversation at hand.

Important point #3. Always take an interest in the employee’s opinion and perspective on various workplace situations, even if they are inexperienced or disagree with you. The important thing here is to show that you are interested in their opinion. This is essential to build mutual trust and get to know your employee better as a person and a professional. This makes them feel how important it is to communicate and helps them take a deeper dive into the topics under discussion in a one-on-one setting, rather than just answering with platitudes or keeping their opinions to themselves.

Important point #4. If you have some relevant examples from your past jobs, make sure you always share your stories, screw-ups, and inspiring cases.

Important point #5. When talking with your employee, make sure to ask more open-ended questions and give them enough time to think through and perhaps discuss the issue briefly with you (remember Point #3).

Important point #6. As a meeting recap, always briefly summarize the points you have agreed on and what you expect from the employee concerned.

Most important! Point #7. You must deliver on any promise made to your employee. If you can’t do that, be honest about it and explain the reason.

How we switched to regular mobile app releases

inDrive.Tech — Thu, 21 Jul 2022 10:33:51 +0000

Since a short time ago, inDriver has been rolling out new mobile releases weekly. Below, we will tell you about how we switched from random to regular releases, what issues we ran into along the way and how we handled them.

Some background information

In 2018, there were four development teams at inDriver: Android, iOS, Backend, and QA. They had about 30 employees, 10 of whom were mobile developers. At that time, new app releases were rolled out only on a when-needed basis — mostly when the big tasks were complete and ready.

There were several problems with this approach:

It was unclear when the next release was going to come out. It was difficult to predict the release of a new feature, as the timeline of large tasks might take anything from a few weeks to a few months.
You had to wait a long time for the release of small tasks. There was a backlog of minor improvements and fixes awaiting release, which could already have benefited our users.
Long turnaround times for releases. As too many tasks were involved in the release, there was a high probability that many bugs would be identified, requiring more time to look into. With significant changes being made, it was harder to catch all the bugs before release, so the debugging process involved multiple hotfixes, thus contributing to postponements to the full-fledged release. And that’s to say nothing of the tasks that “had to be included for sure, let’s move back the release date a short while, there’s only a little bit of work left to do.”
Development slowdowns during the release testing phase. All new features got stuck at the “Ready for Test” status because the bulk of the testing personnel’s efforts was diverted and fully focused on testing the release for a few days. Additionally, at that time, no new features could undergo a test.

This situation continued until 2020. In late 2020, we increased the number of development personnel, implemented a major transformation in the development structure, and moved over to operating cross-functional teams. And whereas in the recent past you only had to coordinate your release within one team, now there were 20 such teams to consider and make arrangements with. The mobile developers who used to be committed to the shared repositories were now on different teams, and this imposed extra restrictions on the release of the app. After all, each team wanted to release their own tasks in alignment with their own plans and priorities.

Something had to be changed. We decided to set up a dedicated team to handle release management issues. That was how the release team emerged.

Switching to regular releases

Once it was established, the first step our release team took was to shift to regular releases. The plan to follow was like this:

Establish a release cycle.
Set the day of the week on which to create a release branch.
Set up a release schedule.

By this point, we had already made several attempts at transitioning. Based on this experience, we outlined a clear-cut approach to managing releases. We knew for a fact that a two-week release cycle with alternating platforms would suit us just fine. Previously, we had tried a three-week cycle, but we were not happy with the delivery speed and the fact that the releases in this case were fairly large, which affected the testing process. Therefore, deciding on a release cycle length was a quick choice to make.

We chose Friday as the day of the week on which to create a release branch. We had several reasons for this:

It was a good fit because it synced with the end of the work week and the completion of sprints.
Releasing on a Friday protects the guys from too much overwork on weekends trying to keep the release on schedule.
Release validation efforts kicked off on Monday because, at that time, it took several days to run a release verification routine. Hopefully, there would be enough time to check the release during the week.

Once the release cycle and the cutoff date were defined, we proceeded to establish a release schedule in Google Sheets:

Release Schedule

But that was not all. It took several months for the teams to get used to the new process. As it turned out, no one was prepared to wait two weeks until the next release, so a lot of team members actively threw in tasks of their own. Due to this, multiple errors arose during release checks, and this pushed back the timeline.

But there were some positive changes as well:

Now, not as many tasks were getting into the release anymore, and they became smaller.
The delivery process for our product accelerated. Smaller tasks were steadily reaching users now.
It had now become possible to plan out your tasks based on the release schedule.

Generally speaking, a more transparent process emerged. The releases became regular and small. But along with this came a large amount of routine work. Plus, the lengthy testing process for the release was still there to go through. Therefore, automating the process and speeding up the release verification were the next issues at hand that needed addressing.

Automating the release process

The process of releasing an application consists of several stages:

Preparing a candidate release.
Acceptance testing.
Uploading and sending the release to the store for review.
Rolling out and monitoring the release.
If all goes well, the release is rolled out to all users.

Each of the stages involves a particular set of steps. For example, the following steps are performed at the stage of the release candidate’s development:

Creating a release branch.
Creating a task for the release.
Creating a pull request.
Building a release app.
Bumping the app version.
Creating a release changelog.
Sending release notifications.

We decided to automate routine work as it was taking up too much time. To automate all of the above steps, we wrote a large number of scripts and are now actively developing our internal service for releases. Here is our technology stack:

GitHub Actions.
Bash, Python, Go.
Fastlane.
Docker.

The first thing we did was to prepare a source of release information. We created a new type of Release task in Jira and presented the release steps as a workflow:

Release Workflow

This strategy enabled us to have a clear idea about which stage the particular release had reached. Previously, you had to check in with the people involved in preparing the release. Now there was no need to ask anyone.

We gather the necessary information in the release tasks. You can view a list of tasks, build numbers, and command statuses, by subtask. In the testing phase, the progress of individual teams can be tracked via these subtasks.

If any bugs or errors are discovered, they are tied to the release task at hand. In this manner, we can check the current status of the release: to see how many bugs are in the works and which ones are not being investigated.

A separate dashboard can be used to keep track of release statuses:

Dashboard

The release task is created on Fridays at midnight. Scripts responsible for the work, which is now routine, are triggered and run in Github Action, as scheduled.

The bottom line:

We have improved the transparency of the release process. Now, the status of releases and a list of tasks included in them can be viewed.
The amount of routine time-intensive work is now significantly reduced.
The release process for both platforms is now standardized.

Speeding up the release verification process

As I mentioned in the beginning, in 2018, our primary testing personnel had to be diverted to attend to the release verification responsibilities. At that time, no new features could be tested, and this slowed down the development process during release testing. To solve the problem, we decided to run checks through the efforts of our release team only.

We assigned four testers to the team, thus relieving the workload off of the other teams. In addition to checking the release, the guys were busy streamlining the release process, writing documentation, onboarding newcomers, and updating test cases in the TMS.

However, this approach revealed a number of downsides:
It is tiring to go through the lengthy checks for the release.
If someone on the team was unable to participate, the other guys were faced with an immediate increase in workload to deal with.

Relatable

You start missing mistakes as your eyes get too used to looking at your work.
There’s not much coverage on devices.
You have to be a good expert on all the features to quickly check the entire application.
You need to have well-written test cases to check unfamiliar functionality.

This went on for several months. Afterward, taking the shortcomings identified into account, we decided to scale up the test to embrace the entire testing team.

Things went much better after that:

The release veriﬁcation process was accelerated significantly.
More coverage on actual devices.
Concurrently, we improved the knowledge of the product and its verticals among all testers, thus further facilitating potential replacements within the team or access to help in critical situations.

It became clear that it was now essential to automate the release verification process in order to cut down testing time. Together with the team of automation developers who were tasked with developing various testing tools, we went on to actively implement UI tests, to validate the release. To achieve this purpose, we use the following tools:

Appium.
Kotlin, JUnit 5.
Docker, Selenoid.
GitHub Actions.

At this point in time, UI tests have covered about 30 percent of the total test cases in the acceptance set. And to keep these tests green and detect bugs in advance, we run them on a daily basis, at night.

To recap the highlights here:

Switching to regular releases cleared away most of our problems:

We set up a release schedule. Our teams now have the ability to plan out their tasks, and it became possible for businesses to plan launches and know the dates of the next releases in advance.
The bulk of the routine time-intensive jobs was automated. This allowed us to focus on other tasks, such as those intended to actively implement UI tests.
We improved the transparency of the release process. It was now possible to track the status of each release and view the necessary information.
The release validation time was reduced to one day, on Monday, and that time frame is rapidly becoming shorter through automation.

Even so, we realized that a two-week release cycle with alternating platforms had a long delivery time for new features. As teams were still unprepared to wait 2 weeks for the next release and then a full rollout of the application, they tried to throw as many extra tasks into the release as possible. Prior to the release cutoff, there was a long queue of tasks for infusion, and this put significant stress on CI. Plus, the teams had asynchronous sprints due to the alternating of the platforms.

With this in mind, the goal for the next year was to shift to weekly releases. To accomplish this, we conducted a one-week release experiment at the end of 2021 and gathered feedback from the team. As a result of the experiment, several problem areas that needed improvement were identified. In addition, some things had to be completely replaced.

Your Product Without UX Writing: Wasted

inDrive.Tech — Tue, 05 Jul 2022 14:11:57 +0000

When you introduce a new IT product to a highly competitive urban environment, you have to cater to various groups of people and factor in multiple levels of tech availability.

UX writers do not always stick around when the company is just launched. More often than not, firms consider hiring a UX writer when the product is fully functional and about to go live.

You can boost any product with a good text. Let’s use our inDriver app as an example and see how it works.

What is the foundation of good UX?

Let’s start with the foundation of a good product: what is necessary for building an optimal user experience.

Simple idea, clear benefits

If a product has no use, no text will describe how it helps people.

The idea of the inDriver app is that you can find a driver on your own and agree on the ride price with them. Its perks are obvious savings and flexibility vs. imposed tariffs.

Understanding the audience

Text is the main tool of communication for any company. Communicating with people without understanding their needs and use cases is a ride for a fall.

Marketing, BI, Support — all teams communicate with people who use our app to a greater or lesser extent. Communication is the primary source of ideas, problems and solutions.

Focus on software development

The name of the button has to be unambiguous. I need to know what happens when I tap the button. If this button doesn’t work and doesn’t bring me anywhere, the text won’t help. As UX writers, we can tell people we’ve messed up and resolve the problem. But we can’t press our luck. If it happens more than twice, the person will look elsewhere for a working product.

inDriver has dedicated development teams, keeping the software development processes under control at all times.

Once we’ve identified the product idea and benefits, verified the idea with the audience and assembled a development team, it’s now time to do UX writing.

What is UX writing?

Generally speaking, UX writing is a process of creating microcopy within an IT product. Everything a person reads in the app, on the website, landing pages and any other interfaces.

The goal of UX writing is to make the interface easy to understand, logical and predictable. To that end, microcopy needs to be easily intelligible, recognizable and suitable for localization.

The core elements of UX writing are:

Structure. Microcopy is easy to scan without reading.
Consistency. The same object is called the same name across the board, punctuation is consistent.
Simple language and unambiguity. Everyone reading the microcopy can understand it at once.
Short sentences. One sentence — one idea.
Informative. Every phrase and sentence is useful to the reader.
Accessibility. Microcopy can be read and understood by people with disabilities.

UX writing has its limitations. You should use certain elements with caution if you are positive they’ll be appropriate and intelligible for your audience. These include:

Phrasal verbs.
Phraseologisms and idioms.
Humor, especially local humor.
Wordplay.

What are UX writers responsible for?

UX Writer or UX Content Writer, Content Designer, UX Copywriter — these are different names for the same profession.

UX writers are engaged in writing interface texts. With the help of microcopy, they create and develop a product hand in hand with designers and researchers. UX writers always know the context. They understand the product, the audience, business requirements, design changes, new app features and test results.

Even working on a single screen, the UX writer has the full picture and makes sure every step is clear and predictable. By predictability, I mean a person has an understanding of how everything works. They see it when previous actions are completed, they see it when it’s time to move on.

If a person wants to get home from work at their own price, they will come to use our product. To find a driver, they’ll go through several steps: download the app, enter a phone number, receive a confirmation code, figure out how the app works and where to start, fill in their basic info so drivers can respond to their offers, fill in the ride info, suggest a price, and choose a driver.

This number of steps looks annoying, but if there is someone who prompts and helps, the task becomes easy to complete and undemanding.

UX writers create microcopy that help people. As if someone were sitting next to them and guiding them through the process. As I mentioned before, it’s crucial to cater to the needs of both long-term users and newcomers who have just tried the app.

Aside from creating microcopy, UX writers are responsible for writing guidelines that benefit the entire company.

Tone of Voice or the brand voice — the company’s distinct style of communication with its audience through the app, web, social networks and ads.

The purpose of the Tone of Voice is to build trust towards the product as people view our ads, download the app, go to the website and contact support. That’s why the brand voice always considers the target audience and adapts to it. Our app has a vast geography. It seems impossible to narrow down the target audience, so we took a calm and respectful approach that works in any culture.

Depending on the situation and environment, the voice may vary. This is called the Tone of Communication. For example, we are friendly on social media, and we sound more official, yet humane and caring in customer support.

Identity verification screen

This is how we’ve applied our Tone of Voice to this screen:

We rewrote the microcopy in casual style.
We showed that we care.
We informed people of what’s important and showed respect.
Also we applied gender-neutral wording in the button caption and removed superfluous checkbox.

Guidelines. Here’s another essential document for the UX writing team. This document is about our internal text rules.

Clear microcopy is instrumental in Giudelines as it saves people’s time. Such a guide includes grammar rules, yet it’s more about interface clarity. Punctuation, capitalization, upper or lower case use — all these technicalities are up to UX writers themselves.

inDriver Guidelines focuses on how the person benefits, as is this case the company benefits as well. Here are some of the rules:

We don’t make microcopy short just to make it short. If microcopy gets longer, yet more useful, then we’re on the right track.
Fewer punctuation marks — greater clarity. We remove any perception barriers that may emerge.
No ambiguity in microcopy, it has to be suitable for translation.

Login screen

That’s how we applied Guidelines to the login screen:

Dot was removed from the title.
The phone number was rendered in the accepted format.
The name of the button was changed as it leads to the confirmation screen.
The label above the social media icons and the confirmation text were edited.

Glossary. This third instrumental document includes the terms we use to name various entities in our product. It helps us avoid unwanted multiplication of terms and make our naming recognizable. For example, if an app section is called ‘Balance’, we need to stick to this name, rather than ‘Wallet’, ‘Finance’, etc.

The ride Options and Comments screen

Words on the new screen are the words from our Glossary:

On a previous screen this block is called ‘Options’, so we use the same word.
The options themselves became more intelligible.
The button is called ‘Apply’, because all buttons that save some options are called ‘Apply’.
The input field was named ‘Comments’ and moved to the bottom of the screen: comments are entered only if the necessary option is lacking.

UX writing for business

To describe the benefits of UX writing for business, let’s go back to the three fundamental principles of a working product.

If the product has a simple idea and benefits, microcopy will be a tool that explains this idea and shows how the product is useful to the person.

When our product team was researching the updated version of the app, we realized standard texts sounded indifferent to people. The templates were robotic or abstruse: a person wouldn’t understand what they read, and it felt like the app showed off its intelligence.

The updated confirmation window is written in casual language without formality. It tells you how the process of deleting an account works. The unnecessary info and ambiguity in the name of the button were removed.

If a person feels comfortable with the product, they get used to it and recommend it. Word of mouth works — the number of unique users grows.

If the business understands its audience, microcopy personifies the business as a brand. We communicate with people in a common language and build trusting relationships. In a modern product, it’s key to show that there are real people behind the product. Also, it’s important to stick to the voice of the brand. By the way, being calm and respectful is also the voice and character of the brand.

One of the ways to accommodate the needs of a large audience is to use universal English in microcopy, without British humor or American slang. That’s how the product becomes easier to understand for more people across the globe.

UX writing is also about accessibility. We can’t write something like ‘Press the green button on the left side of the screen’, as this leaves out people with disabilities and limitations. According to the World Health Organization, one in seven people have one or more disabilities. Such a disability may also be temporary. For example, when using the phone outdoors in sunny weather, it’s very difficult to distinguish colors in bright sunlight.

We also aim to preempt possible questions. Remember the identity verification screen? We mentioned that the photo will not be published, which helped to boost by 7% in just two weeks.

If you focus on software development, the person won’t notice that everything is working, because it should be that way. In this case, microcopy can make the UX even better.
According to our research, people notice it when microcopy becomes more readable and easier to scan. If programmers pay little attention to microcopy, the structure may crash: lists, non-breaking spaces, separation with an empty line — anything can go wrong. A responsible development team makes sure the screen matches its layout exactly.

How does UX writing benefit a software product?

An edge over the competition.
Expanded audience — accommodating those who couldn’t use the product before.
Ethical product that keeps up with the times.
Genuine care and long-term relationships.

In general, UX writing is an investment in a software product. Proper microcopy helps a company reach out to different audiences and make the product relevant in various scenarios.

By thinking about people and caring about their experience, we create the best version of our product. A product that helps people and powers company growth.

A journey into the unknown: how we saw Qase

inDrive.Tech — Wed, 22 Jun 2022 12:59:15 +0000

In this article, I will try to provide a brief description of what the Qase test management system looks like. There will be some small marks where there are differences from TestRail, the system we used to use.

A little background

One not-so-great day, we started thinking about moving from TestRail to a different Test Management System (TMS). This is because TestRail had started to produce bugs that we did not like.

It became inevitable that we would have to search for a new system. And we started Googling right away. Most of the articles we found described each system in general terms — this is a TMS, which allows us to store and edit cases. And here is a list of its features. But that wasn’t enough. The upshot of our short search was Qase.

A couple of words on what Qase is all about. It is a cloud-based test management system that helps teams store and organize product test information and organize team work. To put it simply, it is a place where testers hold their test cases and carry out all sorts of manipulations with them.

This article will constitute a short overview of the system. I will briefly touch on the main questions to which our team wanted to find out the answers, and that we received on the demo and during the transition.

General view

At the top, we see a menu that divides the resource into different parts:

Menu

Project — contains projects that we select from the list of projects created. We can create our own project. There is also a list of cases, runs, plans, etc.
Workspace — workspace setup (users, gender, roles).
Reports — reports and queries.
Apps — integrations.

Projects can be presented as a list or as cards:

Lists

Cards

Here we can create a new project, find it, filter it, and add it to favorites. The latter option allows us to keep the selected projects at the top of the list at all times. We can choose an icon for each project — this is very convenient.

Let’s move on to a more detailed review.

Case Repository

Here’s what this section looks like:

Repository

We see here:

Action menu with cases — it appears only if we select several cases. Actions are visible on the buttons.
List of cases — this contains the automation icon (a hand turning a gear that sets the automation level), case ID and name. At the bottom, there is a button for creating a case quickly. There are 4 buttons next to the name of the suite — creating a suite or case, editing the description, cloning, and deleting.
View — a way to display cases. All in one long plain-text version, or each folder separately.
Action menu — exporting and importing cases. There is also a very handy trash can. No case will ever be deleted, but will simply be put in the trash.
List of suites in the project — contains the name and number of cases in it.
Case counter — contains the total number of suites and cases. If we apply a filter, it will contain values based on the filters set.
Adding filters.

A brief word on the advantage of TestRail in this section — there we can add the display of information about additional fields to the list. Unfortunately, this is not yet available in Qase.

Here’s what the case looks like with different opening methods:

When you tap on the case name, it opens like this

When you tap on the case ID in the list, a preview opens up

The editing mode is presented in two screenshots:

Editing №1

Editing №2

Above, there are standard system fields, then pre- and post-conditions.
Tags.
Custom fields.
Attachments.
Parameters. Example of usage — when you enter 2 parameters, there are already 2 identical cases in the run, one for each parameter. There is still only one case in the repository.

For the steps themselves and the objective results, a toolbar is provided; this eliminates the need to keep the markdown in your head (I always struggled with this in TestRail). Font color, type, 2 types of list, links, tables, image, code block, etc.

Toolbar

Shared Steps

This contains the list of Shared Steps for the project. It is possible to create and edit a shared step, and also to search by the existing ones.

It is convenient that they are not stored in one big heap: each project has its own set. They can be edited easily and created immediately. As we can see, the number of cases in which it is used is displayed:

Shared Steps

Con: shared steps with the same name can be created. And only here can we make it from two or more steps.

When creating a shared step in the case editing mode, we can create it in just one step:

Creating a Shared Step

Milestones

Used to indicate a milestone in development. I could not find any differences between Qase and its fellow product, TestRail. It’s available as part of the project, and this makes good logical sense. We hardly ever use it.

The description of the list contains basic information about it. Unfortunately, there are no filtering options on this screen yet.

A milestone can be selected when creating a run or a case within a project. If you have several teams, and each has its own project, creating a single entry point will not work.

Milestone

Plan

This is where things get more interesting:

Plan

The main difference between Qase and TestRail is that the plan is a template for the future run. In TestRail, it was the entity that enabled runs to be merged.

The plan contains the name and estimated run time — it is formed on the basis of the duration of the cases (if they were run). This is convenient if you want to provide a forecast about the run time.

When creating a plan, you can provide a name and a description, and collect cases by condition. Also, when selecting cases, assign is available for the person selected.

Cons: no dynamic filters. If you collected cases according to a condition, but then they stopped going there, the plan will not change.

Assigned cases in the plan

Test Runs

Just as in TestRail, this is a set of cases to run within a release or a feature. The peculiarity is that there is a wizard, a kind of interface for performing a run.

Multiple entry points for creating a run:

Select a plan — create a run based on it.
Go to the Test Runs section — create a run there.
Select one or more cases in the repository — use the action bar (Run button) to start them up.

Test runs

On the left, there is a list of cases. We can filter them as required.
On the right, there is the case itself. At the top, there is the result for the case; below each step, there is a specific result.
The View and Edit buttons open the case in a new window for viewing and editing, respectively. Changes to a case lead to a change in the case in the run after a page refresh.
Custom fields are displayed in the run, above the steps (we can see the AndroidResult field as an example).
Case Run History — history of the case. This displays the result of past runs.

_Cons: it is not clear what was written in the comment when the case was run. We need to open the general list of cases in the run (*by closing the wizard) and click on the result label.

And if we do not put in the result for each step of the case, we will not see the steps in the completed case.

It seems to me that TestRail is more convenient, since we can immediately see in the tab what happened in the last run._

View of the run with a closed wizard

We see a list of cases; when they are selected, several more actions are available. In the side menu, there is a chart of case statuses (when clicked, filtering by the status selected is performed) and some information (who started it and when).

The Team stats tab will show how much has been completed, and by whom:

Team stats

Settings

It is logical that it contains the project settings:

Settings

Name, code (this will be the case ID), description, and type. There are also tabs for integration, webhooks, configuration, and setup.

Of particular interest is the Settings tab — there we can set settings for starting and ending runs, confirming the deletion of a case, and displaying fields in project cases.

Workspace

Here we see the following:

Workspace

Members — a list of participants: their role, name and the time of their last activity. This makes it possible to block and unblock users. There are filters by status (active or blocked), role, and type (full or read only).
Invites. This contains a list of the invites sent. There is an option to revoke an invite on this page.
Groups — used when a private project is being created. When creating a project whereby access is only given to a specific group.
Roles — roles in TMS. It regulates the capabilities of a user under a specific role. We can create a role, delete it or edit it.
Fields — system and custom fields, creating or editing, and also deleting.
Tags — entity available for a case, a run, and other filtering options.
Attachments — a complete list of all attachments (photos, etc.). It is possible to conduct a search: we can specify in which project a specific attachment is involved.
Logs — a complete log of the actions of all users. Various filtering options are available.

Fields and Roles

In the Field tab, we can set up system fields and custom fields. We can create custom ones right there:

Fields

All the fields are in one place — this is convenient, as we can set up the visibility of a specific project for each field.

Edit a field (a custom one or a system one) — here you are, except for the Automated, isFlaky, and Status system fields. Also, you will not be able to change the field type (from Single List to Multi List, for example). Everything else can be edited quickly and in a convenient way.

Editing field №1

Editing field №2

When editing, the name of the fields (though not for system ones), direction (case or run), and type are set. Next, the visibility for the project and the default value are selected.
The values are set on the second tab. For each one, as needed, a color and an icon are selected (for some future feature, I suppose). Values can be deleted, their positions can be swapped, and new ones can be added.

Now let’s talk about the roles:

Roles

We see the list of roles, type and whether the field is a default one. The number of users for each role is displayed:

Creating a role

When creating the role, we set the name, description and choose what is available for it.

Reports

On this page we can create and see:

Dashboard — information about the project or projects. The dashboard contains some information about cases and other data. One or more widgets are created in order to display information about cases, runs or defects.

Dashboard

Query — a QQL query is created (this is similar to the advanced search function in Jira). A search is performed for projects according to conditions (status, project, name, etc.). A QQl memo will open if you click on the question icon in the search bar.

Each query can be edited however you like:

Queries

Saved queries — a list of saved queries is stored here:

Saved queries

Profile. When we click on it, we will see the following:

Profile

Billing — a button for payment. This contains information about the payment for the current subscription, as well as the payment history (access depends on the role).
Appearance — choice of a theme from among the ones suggested.
API tokens — creating an API token.
Profile — setting up a profile, changing the name, password, subscribing to notifications, and adding a photo.
Help — a help center.
API docs — API documentation.
Roadmap — a product roadmap. This shows which features are planned, which are in the works, and which have already been implemented.
Status — information about incidents, the current state of the product.
Sign out — exit button.

Choice of themes

Conclusion

Of course, one article is not enough to review a tool as large as this. I hope, though, that it will help you in choosing a solution. In the future, I will try to write a short piece with some more extensive material on how we migrated from TestRail.

The result of the transition to Qase, for us, is the absence of critical bugs and peace of mind while we work. Yes, this TMS is not perfect, but it is better than TestRail. And our use of it has proven as much.

The important thing is the continuous improvement of it and, even more importantly, the incredible feedback from the Qase developers themselves. It’s nice to get an answer to your questions quickly and to see bugs being fixed even more quickly (incomparably faster than with TestRail, when it took a couple of months for bugs to be fixed).

During the transition to Qase, a lot of questions were asked, and we received a detailed and extended answer to each of them within 1 to 2 hours, at most. The number of questions, as you know, was huge. But the support team answered with all the calmness of a well-fed Tibetan boa constrictor.

P.S. If you are interested in this topic, I am attaching links to the Qase YouTube channel and GitHub, where you can learn more about the system’s capabilities.