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

Hey. My name is Dasha, I am testing a 2GIS mobile app on iOS. I want to share our process of maintaining features, which helps not only to save time, but also to pump personal skills. Read the article to find out how we manage to keep in the same context products, designers, development. We believe that the review of the first test assembly by all those who are interested really makes life easier for people. And communication is a key point in the management of features.

Our pain

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

Previously, we also had something similar: when planning a sprint a task arrived, at the beginning of the sprint it was taken into development, the task was already being worked on. If there were questions about the interaction with other teams - 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 of a feature in battle; and in the other team did not even know about its existence. Such a process was inefficient, wasted a lot of time / energy, brought chaos.
')
In the end, we realized that it was impossible to live like this, and began to build a new process. He has already helped to save someone's nerves, and possibly life.

About the team

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

For us, a feature is a person living with features from TK to release. It has up-to-date information about what happens to features in general, and serves as an entry point for questions about working on features for people from other teams. For more information about the featured ones, see the report of Sasha Kartavtsev . Remember this term, then it will meet more than once.

Release for 9 stages

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

Rewards - this is encouraging 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 - The process of developing the TK

Before proceeding to the elaboration of the feature, we created a chat in a slug and called all the people involved there. We agreed that we would discuss all the issues on the feature and events in the life of the chat participants that may affect the course of the release. It is not necessary to say that I went for milk, but about vacations / sick leave - it is necessary, otherwise you risk running into hatred for not answering.



First of all, the features from development and testing looked at TK / designs, asked questions, suggested improvements, based on the experience of other features. The fichekrynye made sure that the questions were answered during the day. If the deadlines were delayed, then the same guys hinted to the products / responsible people that the watch was ticking and it would be good to answer.
The process of working out the TOR is considered complete when all major issues are closed, there are final designs, the development has no questions about the implementation of the feature.



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

Stage 2 - Checklist Compilation

In the process of working out the TZ, I, as a feature for testing, compiled test cases for the features in TestRail, which were subsequently checked for features. Prioritized cases for their further automation. Since there is a backend in the feature, I added a test plan for it: which fields we send, which ones we get, and what will happen if there is some strange nonsense coming. We give the finished checklist to look at the development and products to synchronize the expectations of the features, so that it does not work out, that the testing thought one thing, the product expects another, and the developer did something else altogether.

Stage 3 - Development

After working out the TZ, the development of the feature began. Testing at this time dozakryvalo / endorse unclosed questions in the TK and chatika, informed the development of all changes, if any: new requirements, new designs, new texts, whatever - the development should be aware of everything, otherwise you can not avoid a fight.

Stage 4 - Review of the first build feature

Having received the first build, we dropped it into the chat feature, where we called for products and designers to review. Testing controlled that the assembly was viewed and the feedback was given - the sooner the better. This is done in the early stages so that later there are no unpleasant situations.

Stage 5 — Platform Testing

In parallel with the review of the first assembly, testing began on the platform using test cases compiled earlier. In the process of testing, if you found problems that threaten to disrupt the release, or understand that something can be done better - they threw features into the chat or left a comment in the TK. 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 an assembly to the product and designer on the review to make sure that the expectations coincided with reality.

Stage 6 - Integration Testing

This item is necessary if other commands besides mobile phones are involved in the development of the feature. For example, mobile + backend. If we have replaced the font or the color of the icon, then, of course, there is no integration. However, in our example with the Awards, the backend is involved - integration was not enough.
The first thing was to dock in Confluenc. As a rule, in the beginning this is done by one person.

In the document are written:
- dates;
- participants - so that the team knew the heroes by sight, and the heroes could not refute this fact;
- list of checks;
- list of cases - check scripts with certain conditions.

Compiling the dock, I dropped it into the chat feature and called on all integration participants to review / add cases.



On day X, the integration participants gathered in one room and checked all the scenarios from the integration docks. It is great to conduct joint integrations with the backend team - you solve all the issues right on the spot, clarify all the oddities.

Stage 7 - Support Briefing

Before the release they informed the support that the feature will be released soon, it's time to get ready. They gave to read TZ, poke the assembly. They told us which chat rooms to write to and who to contact if feedback was received from users.

Stage 8 - Release

They started to roll the feature, notified the chat about it and simultaneously watched Crashlytics, feedback and support. They hoped for the best, they drank valerian. With the Awards, everything went smoothly, but we were ready to immediately make a hotfix and inform everyone in the feature feature, if during rolling out a critical bug was found on the side of the platform.

Stage 9 - Support features after release

After the release of the features to the battle, our role became informational: they answered incoming questions, suggested, solved some platform problems, or, if they understood that the problem was on the backend, they were transferred to them. After the release, I also poured the Cases to check the Rewards in the main repository of the cases in the test trailer so that they could be reused later.

And briefly

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

The knowledge and experience I gained in the process helps me both at work and in life. I pumped communication, independence, responsibility, plunged into the product beyond the work of our team. The team, by the way, is also pleased - in the case of a fakapa, he is now drinking wine, and not valerian.