Home

Автор: Копцова Екатерина, руководитель служб тестирования в Яндексе
Оригинальная публикация

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

Зрелым командам такие метрики ощутимо помогают:

• замечать периоды низкого перформанса команды и нехватку ресурсов;

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

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

Меня зовут Катя, я руковожу службами тестирования Музыки и Букмейта, и в этом посте я хочу рассказать про основные метрики, которые мы используем в команде тестирования Яндекс Музыки, и обсудить, как правильно с ними работать.

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Мухаммад Саад написал на LinkedIn про интересный сценарий. Приведу его курсивом и прокомментирую.

Представьте, что вы первый день как вышли работать тестировщиком. Вам показывают приложение, которое нужно протестировать. Это ERP-приложение, содержащее сотни форм и тысячи отчетов. Вы начинаете исследовательское тестирование, открывая форму, в которой около 50 разных полей.

Автор: Дарина Майорова, телеграмм

Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.

Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов; далее для простоты я буду часто объединять их в одно понятие Афиша), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.

Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).

Автор: Юлия Поттингер (Julia Pottinger)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

В январе 2022 мы подводили командные итоги 2021 и обнаружили, что у нас довольно много приемочных багов при тестировании новых фич. Мириться с этим было нельзя, и за дело принялся знающий человек — наш тимлид. Он собрал команду и поставил задачу: снизить количество приемочных багов до минимально возможного значения, желательно разика в три. Это был челлендж, который казался невыполнимым. Но сдюжили! Расскажу, как мы всего добились и почему это хорошо.

Автор: Антон Синькин

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

Дисклеймер

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

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

Автор статьи: Глеб Саркисов (Gleb Sarkisov)
Оригинал статьи

Всем привет, меня зовут Глеб! Я — Head of QA в Mayflower. В последние несколько лет мне стали интересны метрики QA — особенно такие, которые позволяют искать проблемы в процессах, вести переговоры с бизнесом, показывать пользу тестирования для проекта и использовать показатели в качестве KPI.

За время работы в различных компаниях я видел разные подходы для решения этих задач и среди множества метрик я сконцентрировался на defect density. В результате ее изучения, я кастомизировал ее и запилил свою dd “со звездочкой”. Если вы тоже находитесь в поиске метрики, учитывающей чистоту релизов, их объем и скорость, вам может быть полезна моя статья.

По классике, метрика defect density — это доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза; считается на тысячу строк кода. Идея метрики заключается в том, чтобы определить отношение дефектов в вашем коде к его объему и постепенно уменьшать его. Идея, надо признать, отличная, но нюансы внедрения метрики могут сделать ее достаточно неудобной для использования.

1. Если ваш проект написан на нескольких языках, имеет много модулей, отдельных сервисов, механизм подсчета этой метрики будет непросто прикрутить.
2. Интерпретация значений может быть затруднена: для кого-то соотносить баги и количество строк может показаться неудобным, нелогичным и неприменимым, например, при тестировании “на стороне”, когда к коду вообще может не быть доступа, а данные о его качестве хочется получать.

Хочется взять самое лучшее от этой метрики, модифицировав ее для удобства и большей информативности. Если оттолкнуться от идеи, добавить производительность команды, критичность разных дефектов, то можно посчитать defect density ”со звездочкой” — отношение дефектов различных приоритетов на продакшне к фактической пользе, которую донесла команда за спринт. Так можно учесть сразу и чистоту тестирования внутри спринта, и скорость доставки через доставленный объем задач и багфиксов. Такой показатель можно понятно объяснять бизнесу и на него можно подвязываться как на качество релизного процесса — как на уровне отдельной команды, так и на уровне всего продукта.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Вопрос от тестировщика:

Как быть с багами прода? Когда менеджмент спрашивает "Ты это вообще тестировал?", что мне отвечать?

Автор оригинала: David Tzemach