Home

Автор: Джеймс Бах (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

Автор: Алексей Никитин, Visiology CEO, https://www.linkedin.com/in/alexey-nikitin-5aa09869/

Технологии Agile, Scrum и CI/CD становятся общепринятой нормой, и нам уже кажется, что новые релизы всегда можно выпускать постоянно, практически непрерывно. Технически, сейчас действительно есть реальная возможность выкатывать обновления каждый день, а некоторые разработчики готовы релизиться каждый час — для web- и мобильных приложений это совершенно нормально. При такой частоте возникает вопрос: на сколько хорошо должна быть отлажена система автоматизированного тестирования? Цена ошибки в таком релизном цикле невысока, а компания получает возможность переложить финальное тестирование на плечи своих клиентов. Если у кого-то что-то пошло не так, можно моментально выпустить исправление. Но возможен ли такой подход в разработке корпоративной BI-системы? Об этом и поговорим сегодня.

Привет, я Михаил Шваркунов, директор по качеству ВКонтакте. Расскажу, как выглядят наши ежечасные релизы с точки зрения тестирования: как мы переложили часть задач по тестированию на разработчиков, сколько у нас автотестов и что мы ими покрываем. А ещё как команда тестирования сопровождает релиз, какие у нас при этом SLA и что делаем после. И вообще — зачем так часто что-то выкатывать? Что, нельзя подкопить и катать раз в день? 

Деплой: раз в месяц → раз в час, или Зачем так часто

У разных компаний бывают релизы и раз в месяц, и раз в неделю, у некоторых каждый день. ВКонтакте релиз происходит каждый час. Так было не всегда — до того, как мы так ускорились, наши релизные поезда были длинными и перегруженными, за ними всегда кто-то бежал с криками: «Подождите! Подождите! У меня релиз, договорённости, вы не можете без меня уехать!»