Home

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

Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде.

Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове:

«Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?»

И тут меня накрыло. Я же слышу такое каждый месяц на работе:

«Зачем нам QA? Разработчики сами протестируют.»

«Зачем менеджер? Мы сами разберёмся, мы же взрослые.»

Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает.

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

Только как быть, если в вашей команде уже не 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)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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