Здравствуй, Хабр! Сегодня я хочу завершить цикл статей об организации тестирования (начавшийся с изучения ошибок и опыта), рассказав о том, как же все-таки Badoo выпускает два качественных серверных релиза каждый день. Кроме пятницы, когда мы релизимся только утром. Не надо релизиться в пятницу вечером.

Я пришел в Badoo чуть более четырех лет назад. Все это время наши процессы и инструменты для тестирования непрестанно развивались и совершенствовались. Для чего? Число разработчиков и тестировщиков увеличилось примерно в два раза — значит, для каждого релиза готовится больше задач. Количество активных и зарегистрированных пользователей тоже удвоилось — а значит, и цена любой нашей ошибки стала выше. Для того чтобы доставлять пользователям максимально качественный продукт, нам нужны всё более и более мощные средства контроля качества, и эта гонка не заканчивается никогда. Цель этой статьи не только продемонстрировать работающий пример, но и показать, что какими бы крутыми ни были ваши процессы контроля качества, наверняка можно сделать их еще лучше. Технические реализации некоторых инструментов вы сможете найти по ссылкам на другие статьи, о некоторых из них нам еще предстоит написать.

В Badoo существует несколько разных QA-флоу, отличие которых обосновано разными средствами разработки и целевыми платформами (но мы используем для них общие системы: JIRA, TeamCity, Git и т.д.), и я вам расскажу о процессе тестирования и деплоя наших серверных задач (а заодно и веб-сайта). Его можно условно разделить на 5 больших этапов (хотя тут, конечно, многие мои коллеги считают по-разному), каждый из которых включает в себя и ручную, и автоматизированную составляющую. Постараюсь рассказать вам по очереди о каждом из них, отдельно выделяя то, что изменялось и развивалось в последние годы.
Читать дальше →

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

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