Home

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

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

Дисклеймер

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

Я сам не считаю себя профессионалом невероятного уровня, мой опыт в 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 и что делаем после. И вообще — зачем так часто что-то выкатывать? Что, нельзя подкопить и катать раз в день? 

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

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

Меня зовут Александр Пронин, я занимаюсь тестированием более пяти лет, последние полгода из которых — в QIWI, проект ContactPay. Мы делаем платежную систему для международного рынка, она состоит из микросервисов, которые написаны на Python и живут в Google Cloud. Проект существует на рынке более двух лет, на данный момент среди наших клиентов уже есть компании-единороги. 

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

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

Заходит тестировщик в бар, а бармен ему говорит: сегодня не работаем, у меня инвентаризация просроченного пива.

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.

Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.

Автор: Джоэп Шууркс (Joep Shuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если не на основе рисков, то на основе чего?

Перевод: Сообщество ProQuality Community, https://t.me/proquality_community

Автор оригинала: Gipil Quddus

Когда мы слышим термин "Quality Gates" (QGS), мы склонны думать о них довольно недальновидно на уровне проекта как об этапах и предпосылках для перехода к следующему этапу реализации проекта. На проектах, особенно на тех, которые работают с использованием любой гибкой методологии, часто можно обнаружить что показатели качества более низкого уровня (например, критерии входа и выхода из теста, а также определение Definition of Done) часто обсуждаются/документируются, но затем упускаются из виду или вообще не используются.

QGS – это, по сути, очень хорошие чек-листы, подкрепленные простыми рабочими процессами. Они обеспечивают нам наглядность, уверенность и структурность того, что мы поставляем как результат процесса разработки, а также соответствие нашим установленным стандартам качества и ожиданиям. Для любой роли необходимо убедиться, что вы можете организовать список необходимых задач (чек-листов) и выполнить эти важные задачи. Этот процесс является ключом к предоставлению качественного программного обеспечения, когда команда поставляет продукт без спешки и потери качества.

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