Привет, Хабр! Представьте: ваш лучший тестировщик уходит на другой проект. Вместе с ним «утекает» уникальный опыт, накопленный за месяцы работы. Новый сотрудник тратит недели, чтобы разобраться в особенностях продукта, а релиз задерживается. Знакомо?

Меня зовут Наталья Мурашова, и за 15 лет в тестировании (IBS, Boeing, DHL, Сбербанк, MVIDEO) я убедилась: ключ к стабильности — не в гениальных отдельных специалистах, а в системе обмена знаниями. Сейчас я руковожу процессами тестирования в СИБУРе и расскажу, как мы:

• превратили разрозненный опыт в общую базу знаний, доступную даже новичкам;

• научили команды учиться друг у друга, а не изобретать велосипеды;

• сделали тестирование ключевым звеном в принятии решений компании.

Если вы хотите, чтобы ваши тестировщики перестали работать в режиме «пожарных», а их экспертиза стала драйвером роста — читайте дальше. Здесь нет теории, только мой опыт и практика, которая уже работает в крупных корпорациях.

Зачем это нужно?

1. Быстрее решаем похожие задачи

Чаще всего мы сталкиваемся с задачами, которые уже решались в других проектах — особенно когда речь идет о тестировании интеграций с общими продуктами компании, специфических процессах, самописных фреймворках или необычных инструментах.

Если экспертиза доступна, не приходится изобретать велосипед — достаточно посмотреть, как задачу решили коллеги.

2. Развиваем сотрудников

Когда тестировщик долго сидит на одном проекте, ему становится интересно, чем занимаются соседние команды. Какой функционал они разрабатывают? Какие инструменты используют? Может, там применяются технологии, которые я хотел бы освоить?

3. Прокачиваем наставничество

К каждому новому сотруднику мы прикрепляем наставника, который рассказывает о процессах тестирования. Это особенно помогает стажерам, у которых есть только теория, но нет практического опыта.

Кстати, фан фэкт: наставничество полезно и для самого наставника. Рассказывая о процессах, он сталкивается с неожиданными вопросами или замечает новые способы решения задач, о которых раньше даже и не думал.

4. Создаем поддерживающую среду

Тестировщики не боятся обсуждать проблемы и искать решения вместе. Если у кого-то возникли сложности, он знает, что может обратиться к коллегам или попросить подключить более опытного специалиста.

Каждый понимает, что он не один на один со своими проблемами.

5. Повышаем статус тестирования

Систематизированный опыт помогает поднять значимость тестирования в рамках всей компании. Это особенно важно при внедрении процессов тестирования в новые проекты.

До сих пор в некоторых проектах по разным причинам не привлекают тестировщиков. Наша задача — обеспечить присутствие специалистов по тестированию во всех новых проектах. От этого напрямую зависит качество продуктов и репутация компании.

А когда руководство видит, как у нас организован процесс, какие есть результаты и куда мы движемся, это укрепляет позиции тестирования в компании.

Как мы это делаем

1. Внутренние митапы

У нас есть обязательная ежемесячная встреча и дополнительные — по необходимости, если возникает срочный вопрос или интересная тема.

На этих встречах мы:

• Знакомим новичков с командой.

• Рассказываем о процессах.

• Просим новичков поделиться их опытом из предыдущих мест работы.

Очень важно про последний пункт: мы не только передаем опыт новичкам, но и готовы учиться у них.

Темы для митапов берем из разных источников:

• Телеграм-каналы по тестированию и IT.

• Новости технологий.

• Текущие проблемы (сейчас, например, остро стоит вопрос замены инструментов из-за санкций).

• Новые инструменты, которые хотим изучить.

Мы часто предлагаем кому-то из команды глубже изучить новую технологию, чтобы потом рассказать о ней всем: стоит ли внедрять, какие особенности, почему может не подойти.

2. Wiki

Мы ведем раздел по тестированию в корпоративной wiki. Там храним:

• Список команды с контактами и проектами.

• Технические инструкции по настройке инструментов.

• Страницы по новым технологиям.

• Список тем на будущее.

• Полезные материалы.

• Информацию для командного духа (например, дни рождения).

Даже если нет времени детально проработать тему, создаем страницу-заготовку с основной информацией и помечаем как «на доработку». Так не теряем идеи.

3. Кросс-проектное ревью

Это один из самых хороших методов. Тестировщик из одного проекта на время подключается к другому, чтобы посмотреть на процессы тестирования.

Ему не нужно глубоко вникать в функциональность разрабатываемого продукта — достаточно посмотреть:

• Есть ли тест-кейсы и как они написаны.

• Как заводятся баги и задачи.

• Как в целом организована работа.

Это полезно обеим сторонам: проект получает свежий взгляд, а тестировщик видит новые подходы, которые может применить у себя.

Плюс это своего рода нетворкинг — знакомство с другими командами и проектами пригодится, если захочется перейти на новую задачу.

4. Мини-обучение специфике компании

Мы проводим небольшие обучающие сессии по специфичным для компании вещам: особенностям тестирования в нашей среде, корпоративным инструментам, процессам.

Например, если у нас есть собственный фреймворк для автоматизации, собираем заинтересованных и показываем, как он устроен и как с ним работать. После обучения тестировщики уже сами пишут автотесты.

5. Неформальные встречи

Помимо рабочих митапов проводим неформальные встречи и тимбилдинги. Часто именно там происходит самый интенсивный обмен информацией. Неформальное общение помогает лучше понимать контекст работы и укрепляет доверие в команде.

Если находятся энтузиасты, они могут организовывать квизы по тестированию или другие активности, которые делают обмен знаниями увлекательнее.

Подробнее о кросс-проектном ревью

Эту практику часто обсуждают, поэтому расскажу о ней детальнее.

Как решаем вопрос доступа к информации?

Всё зависит от используемых инструментов. У нас тестовые сценарии хранятся в Allure TestOps, и все тестировщики имеют доступ ко всем проектам.

С Jira сложнее — доступ к проектам обычно ограничен. Владелец пространства — чаще всего руководитель проекта. Мы обсуждаем с ним возможность дать доступ стороннему сотруднику. Если не получается, ограничиваемся ревью только тестовых сценариев.

Сколько времени занимает?

Обычно около 30 минут. Это не ежедневная и даже не еженедельная активность. Чаще всего договариваемся, что после релиза команда приглашает тестировщика из другого проекта.

Если команда работает в двухнедельных спринтах, ревью проходит раз в две недели. Если релизы реже — соответственно, реже и ревью.

Что получают обе стороны?

Тестировщик, проводящий ревью:

• Видит, как устроены тестовые сценарии и задачи в другом проекте.

• Знакомится с инструментами соседей.

• Находит новые подходы к структурированию тестов.

Проект, проходящий ревью:

• Проверяет правильность своих процессов.

• Подтверждает, что задачи и баги заводятся корректно, тесты соответствуют релизным задачам.

• При необходимости получает рекомендации по улучшению.

В итоге руководство убеждается, что все проекты следуют принятым корпоративным  процессам, а специалисты обмениваются опытом.

А для автоматизации работает?

Да, это эффективно и для автоматизированного тестирования.

Особенно полезно тестировщикам, которые еще не занимаются автоматизацией, но хотят начать. Они могут посмотреть на реальные автотесты, понять их структуру и определить, какие навыки нужно развивать.

Наставничество для новичков

У каждого новичка в команде есть наставник (Buddy), помогающий влиться в коллектив и разобраться с процессами.

Роль наставника зависит от ситуации:

• Если новичок приходит в сложившуюся команду с опытными тестировщиками, наставник меньше вовлекается — команда сама проводит адаптацию.

• Если новичок присоединяется к новому проекту или команде без опытных тестировщиков, наставник активно помогает: настраивает инструменты, выстраивает процессы, контролирует их развитие.

Для удаленных сотрудников, особенно джунов, организуем регулярные созвоны. Сначала, возможно, каждый день, потом раз в неделю, затем реже — всё зависит от скорости адаптации.

Наставник помогает не только с тестированием, но и с техническими моментами: настройкой S-Terra, VPN и других инструментов. Всё индивидуально.

Что работает лучше всего?

Для укрепления командного духа лучше всего работают внутренние митапы и неформальные встречи — они помогают познакомиться и поделиться новостями.

А для решения конкретных проблем и передачи опыта наиболее эффективно кросс-проектное ревью. Даже если все в компании работают по похожим процессам, погружение в другой проект всегда дает новые идеи.

Что в итоге?

Накопление и распространение экспертизы в команде тестирования — не просто полезная практика, а необходимость. Благодаря ей мы:

• Быстрее решаем типовые задачи.

• Развиваем сотрудников.

• Укрепляем наставничество.

• Создаем поддерживающую среду.

• Поднимаем значимость тестирования в компании.

Каждая команда может выбрать подходящие методы в зависимости от своих особенностей. Главное — сделать обмен опытом постоянной практикой.

А как у вас организован этот процесс? Какие методы работают лучше? Давайте обсудим в комментариях.