How do we test a feature from TK to post-production and maintain friendly relations within the team

Hey. My name is Dasha, I'm testing a 2GIS mobile application on iOS. I want to share our process of conducting features, which helps not only save time, but also upgrade my personal skills. Read the article to find out how we manage to keep products, designers, development in the same context. We believe that the review of the first test assembly by all interested people really makes life easier. And communication is the key to managing a feature.

Our pain

When communicating with testers from other companies, I often notice that testing their features is somehow messy, unstructured. Because of this, time is wasted, the strength of the people involved in the development. People become angry, start to hate their colleagues, wait for them at the porches.

Previously, we also had something similar: when planning a sprint, a task flew in, at the beginning of the sprint it was taken into development, we worked out the task already in the process. If there were questions on interaction with other teams, we went to the product. It often happened that in some teams the work was already in full swing: everyone was looking forward to the release, someone had already dreamed about the feature in battle; and in the other team they didn’t even know about its existence. Such a process was ineffective, spent a lot of time / effort, brought chaos.

As a result, they realized that it was impossible to live like that, and began to build a new process. He has already helped save someone's nerves, and possibly life.

About team

Our team consists of: 9 developers, 6 testers, a product and a designer. When planning an iteration (what we will be doing for the next 4 months), features are compiled that you want to release in the current time period. When the list is compiled, one feature is allocated for each feature from the team from development and testing, which will be with features from beginning to end.

For us, featured is a person who lives with features from TK to release. He has up-to-date information about what happens to the feature as a whole, and serves as an entry point for questions about working on features for people from other teams. You can learn more about features at the end of the report by Sasha Kartavtsev . Remember this term, then it will be found more than once.

Release in 9 stages

The whole process of bringing features to release can be divided into 9 main stages. For clarity, we take the recently released feature of the “Rewards” and tell how we conducted it in all nine stages.

Awards are a reward for users for their contribution to the product. Users get them for writing reviews, uploading photos, adding new companies to the directory. They can be seen on the tab “My 2GIS”.

Stage 1 - TK development process

Before starting to work out the features, we created a chat room in slack and called all the people involved there. We agreed that in it we will discuss all issues on features and events in the lives of chat participants that may affect the course of the release. It’s not necessary to say that you went for milk, but you need to talk about holidays / sick leave, otherwise you run the risk of running into hatred for unresponsiveness.



First of all, the features from development and testing looked at TK / designs, asked questions, proposed improvements, based on the experience of other features. The feature was monitored so that questions were answered within a day. If the deadlines were delayed, then these same guys hinted to the product / responsible people that the clock is ticking and it would be nice to answer already.
The process of developing TK is considered completed when all the main issues are closed, there are final designs, the development has no questions on the implementation of features.



At the first stage, it’s very cool to make a prototype of a feature and use it in the development of TK: it will help to feel the feature on the device and identify imperfections at an early stage, come up with cases for testing. Products will be able to make changes to the logic even before the development on the platform begins.

Stage 2 - Drawing up the checklist

In the process of working out the ToR, as a feature for testing, I made up test cases for the feature in TestRail, according to which the feature was subsequently checked. Prioritized cases for their further automation. Since there is a backend in the feature, I added a check for it to the test plan: which fields we send, which we receive, and what will happen if there is some incomprehensible nonsense here. Let’s give the finished checklist to the development and the products for synchronizing expectations from the feature, so that it doesn’t happen that testing thought one thing, the product expects another, and the developer did something else.

Stage 3 - Development

After the development of the ToR, the development of features began. Testing at that time closed / debated open issues in the ToR and chat room, informed the development of all changes, if any appeared: new requirements, new designs, new texts, anything else - the development should be aware of everything, otherwise there is no way to avoid a fight.

Stage 4 - Review of the first feature assembly

Having received the first assembly, we threw it into a feature chat, where we called on the products and designers for a review. Testing controlled that the assembly was viewed and was given feedback - the faster, the better. This is done in the early stages, so that later unpleasant situations do not happen.

Stage 5 — Platform Testing

In parallel with the review of the first assembly, testing began on the platform using test cases compiled earlier. During the testing process, if you found problems that threatened to disrupt the release, or realized that something could be done better, they would add features to the chat or leave a comment in the statement of work. We made sure that the question did not remain open.

At the same stage, there were changes in the logic of features (UI, for example) - they also gave the assembly to the product and designer for a review to make sure that the expectations coincided with reality.

Stage 6 - Integration Testing

This item is necessary if teams other than mobile phones participate in the development of the feature. For example, mobile phones + backend. If we replaced the font or color of the icon, then, of course, no integration takes place. However, in our example with Rewards, a backend is involved - integration was indispensable.
The first thing to do was make a dock in Confluence. As a rule, at first one person does this.

The document spells out:
- dates of carrying out;
- participants - so that the team knows the heroes by sight, and the heroes cannot refute this fact;
- list of checks;
- list of cases - verification of scenarios with specific conditions.

Having compiled a dock, I threw it into the features chat and called on all the integration participants to review / supplement the cases.



On day X, the integration participants gathered in one office and checked all the scenarios from the integration docks. It is great to carry out joint integrations with the backend team - you immediately resolve all issues on the spot and clarify all the oddities.

Stage 7 - Support Briefing

Before the release, they informed support that a feature will be released soon, it's time to get ready. Dali read TK, poke assembly. They reported which chats to write and who to contact if they receive feedback from users.

Stage 8 - Release

We started rolling the feature, notified the chat about it and in parallel watched Crashlytics, feedback in the store and support. We hoped for the best, drank valerian. Everything went smoothly with the Rewards, but we were ready to immediately make a hotfix and inform everyone in the features chat if during the rollout a critical bug were found on the platform side.

Stage 9 - Support for features after release

After the feature entered the battle, our role became informational: they answered incoming questions, prompted, sorted out some platform problems or, if they understood that the problem was on the backend, passed them on. After the release, I also poured the cases on the Rewards check into the main case storage in the test trail so that they could be reused in the future.

And if briefly

• Always keep everyone in the same context. Report important changes.
• As soon as an assembly with features appears, organize a review of the first assembly by all interested parties.
• If changes occur in the logic of a feature at any stage, also organize a review.
• Get the answer: write, call, kick, until you respond.
• Prepare support for a new feature and help it after launch.

The knowledge and experience that I gained in the process helps me both at work and in life. I pumped communication, independence, responsibility, immersed myself in the product beyond the work of our team. The team, by the way, is also happy - in the case of a fakap, now he drinks wine, not valerian.