Home

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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

Вариант: заручиться поддержкой аналитиков и начать собирать данные по командам из таск-трекера, с последующей визуализацией на дашбордах. Как показала практика, это не быстрый, итеративный процесс — особенно когда нужно мониторить сразу несколько команд. Но в результате такой мониторинг может стать мощным подспорьем для роста показателей по метрикам и в целом выступать индикатором качества процессов.

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

Привет, меня зовут Василий, я Deputy CTO в Сравни. Уже пару лет мы централизованно мониторим производительность в командах, чтобы видеть реальную рабочую нагрузку, выявлять сложности в процессах и влиять на персональное развитие сотрудников. Речь, по сути, о визуализации данных из корпоративного таск-трекера — по настраиваемым полям получаем на дашбордах данные в нужном нам разрезе, на их основе делаем выводы. 

Оригинальная публикация

Всем привет! Меня зовут Ксения Лопатина. В предыдущей статье я рассказывала вам о своем подходе к построению карты компетенций для команды тестирования. Там я описала зачем нужна карта компетенций, как можно подойти к ее построению и как провести оценку.

Сегодня я хочу рассказать о том, что же делать дальше, после того, как вы провели оценку. Вы узнаете, что такое ИПРы и как создавать их на базе карты компетенции, как правильно ставить задачи и нужно ли контролировать их исполнение. Также покажу вам наиболее оптимальный формат, который я выработала путем проб и ошибок. Статья будет полезна и тем, кто уже выбрал подход работы с ИПР и тем, кто только в начале данного пути. Также будет полезно если вы составляете ИПР себе самостоятельно или делаете их для ваших сотрудников.

Оригинальная публикация

Всем привет! Меня зовут Ксения Лопатина, я вот уже почти 9 лет в тестировании. Не так давно поймала себя на мысли, что мой аккаунт на Хабре совсем запылился. А ведь за годы работы у меня было достаточно много опыта на различных позициях от ручного тестировщика до руководителя и мне действительно есть чем поделиться. Так и пришла в мою голову мысль поднять в очередной раз тему развития в тестировании. Мне кажется, что эта тема будет актуальна всегда. Эта статья будет первой, в планах у меня уложиться в три, но там уж как пойдет. 

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

Автор: Фроленков Роман
Оригинал статьи

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд.

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

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

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

Оригинальная публикация

Импортозамещение и уход иностранных вендоров заметно повлияли на отечественный рынок IT. С одной стороны, госкомпании и ключевые организации, включая банки, обязали переходить на отечественное ПО. В то же время продолжается исход зарубежных систем, последней из них стала Qase TMS, которая объявила о прекращении работы на российском рынке и блокировке аккаунтов по IP. Эти изменения сильно ускорили развитие российского ПО и его популярность.

На фоне этих событий мы подготовили мини-обзор систем управления тестированием, которые сейчас доступны в России. Это не рейтинг или рекомендация, а скорее ревью.

Автор: Елизавета Лященко, ГК Самолет

Когда фича «протестировать табуретку» вызывает нервный смех у тестировщиков и недоумение у менеджеров, пора разобраться, как на самом деле работает тестирование. Меня зовут Елизавета Лященко, я работаю тестировщиком уже 5 лет, из которых 1.5 года в Самолете, и сегодня разложу по полочкам весь цикл проверки — от странных требований до стресс-тестов и финального релиза. Мы узнаем, почему тестировщик задает миллион вопросов, чем его работа отличается от «я все проверил, все ок» и как тестирование спасает команду от хаоса. Готовьтесь увидеть табуретку так, как вы ещё никогда её не видели!

Мне в своей работе порой приходится сталкиваться с ситуациями, когда коллеги из других отделов не до конца понимают и принимают процессы тестирования. Это может проявляться по-разному: где-то забудут оценить сложность задачи с учётом тестирования, где-то разработчик отдаст в тест фичу с комментарием «я там уже всё протестировал, так что можешь сразу закрывать», где-то аналитик обидится, что к его требованиям задают слишком много вопросов, а где-то проджект-менеджер прибежит с вопросами, почему так долго фича находится в тестировании. Обычно все эти вопросы решаются методичным и нудным объяснением «чтобы что», переоценкой задач и заведением пачки тикетов на «уже протестированную» фичу.

Но так как штат растёт, а старые коллеги имеют свойство «обнуляться», время от времени приходится повторять упражнение и закреплять материал. С целью экономии придумалось, как объяснить все процессы тестирования на примере популярного задания при приёме на работу: «протестируй табуретку». На этом наглядном примере я объясню, из чего состоит цикл тестирования фичи, и почему ни один из этапов нельзя выкидывать с какой бы то ни было целью.

Автор: Наталья Кудрачинская, SmartHead

Моя первая статья об интеграции Playwright и GitLab CI в Qase получилась довольно формальной. Переживания о ней были огромными: я хотела сделать ее «правильной» и, самое главное, доступной для каждого, кто решит ее прочитать и применить на практике. В столь технической статье было сложно выразить свое мнение о чем‑либо, поэтому в этой статье я бы все же хотела это сделать и немного порассуждать на тему обеспечения качества, и почему это не только про тестирование. Я рассмотрю QA как комплексный процесс, который включает помимо технических аспектов еще и командную работу, планирование, предотвращение ошибок и многое другое.

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

А пока…

Автор: Наталья Руколь

Статей про эмоциональное выгорание много, и часть из них очень даже хорошие. Они фокусируются на работе с людьми: как и что говорить, какие ставить задачи, где вести общение, и вот это всё. Я хочу разобрать более узкую тему: специфичное выгорание тестировщиков. И решения буду предлагать не про людей, а про процессы. Как строить такие процессы разработки, чтобы минимизировать эмоциональное выгорание в команде? Какие баги (в коде и в процессе) надо фиксить? На какие штуки обращать внимание? Рассказывать буду с трёх позиций: что с каждой проблемой может сделать биг‑босс (РМ или собственник бизнеса), тест‑менеджер и сам выгоревший тестировщик. Букв в статье получилось много, сорян ))) Зато вроде полезные? Поехали!

 11 марта 2024 года. Вентиляторный завод, село Крюково, Московская область: 
- Сергей Петрович, здравствуйте. Я сегодня не смогу выйти на работу, потому что я не в ресурсе. 
- Жека, да ты чего? А что с тобой? 
- Сергей Петрович, мне совсем не хочется работать, не могу войти в поток, у меня упадок сил. 
- Женя, ну ты чё, надо заботиться о себе. Совсем упахался. Ты давно с друзьями на рыбалку ездил? А ванну с бомбочками принимаешь? 
- Блин, Сергей Петрович, у меня на такое не было времени. Вот видите, до чего я себя довёл. 
- Понятно, Жека. Отдохни обязательно пару дней и возвращайся. 

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Я часто разговариваю с тестировщиками, которых бесит их менеджер. Вот типичные жалобы:

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

Сталкивались ли с этим вы? Время узнать, как управлять вашим менеджером! Ниже – шесть моих идей.

Автор: Ирина Иванова, старший инженер по тестированию в образовательной платформе Учи.ру.
Оригинальная публикация

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

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