Home

Автор: Джуди Мосли (Judy Mosley)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Пономарева Анастасия

Недавно знакомый PM попросил рассказать «Что значит отвечать за качество?» в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

Начну немного издалека. Последние лет пять тема продуктовых команд очень популярна. Тестировщиков из «колодцев» и подчинения QA лидам и хэдам забирают в команды. Если сначала было матричное управление с функциональным руководством, то последние годы растет тренд на отказ от QA лидов с передачей функции лидам продуктовых команд.

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

Это третья статья из серии. В первой я разобрал 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 как комплексный процесс, который включает помимо технических аспектов еще и командную работу, планирование, предотвращение ошибок и многое другое.

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

А пока…