Регрессионное тестирование: взгляд изнутри от лидера команды

Многие разработчики и начинающие тестировщики считают регрессионное тестирование рутинной и скучной работой. Максим Атлашкин, руководитель отдела регрессионного тестирования РСХБ-Интех, готов развеять этот миф. Из интервью вы узнаете, как за 2,5 года пройти путь от джуна до лида регрессионного тестирования. Максим расскажет реальные истории о спасении релизов благодаря тестированию и поделится инсайдами о процессах тестирования в крупном банковском IT-проекте. Максим, как ты пришёл в сферу тестирования? Пришел в тестирование 20-м году из сопровождения первой линии другого банка, где во время процесса перехода на новую систему ДБО (другими словами клиент-банк) мой отдел начал изучать систему раньше пользователей и находил ошибки. Делали мы это исследовательским путем, ошибки записывали по шагам и передавали письмом (багтрекера для сопровождения не было) в отдел разработки. Мне этот процесс понравился, особенно когда была обратная связь и ошибки действительно исправляли, и нужно было сделать ретест. Тогда-то и начал интересоваться тестированием в целом, искал информацию в интернете по типу «Как тестировать», прошел несколько бесплатных курсов и решил, что нужно профессионально идти в тестирование, параллельно продолжая изучать эту сферу. Что тебя вдохновило заняться именно регрессионным тестированием? Цели идти именно в регрессионное не было. У меня не было опыта, и я не до конца понимал, как это работает на тот момент. Я оказался в РСХБ-Интех и изначально попал в команду регресса ДБО для юридических лиц. Только месяц-два изучил, как и что тут работает, как пришла пора «распиливать» монолит на микросервисы, появились продуктовые команды разработки, и колесо фортуны закинуло меня в одну из них, да еще и с очень критичным продуктом платежей и переводов. Там я на практике познакомился с большим количеством инструментов (Postman, Swagger, BrowserStack, DBeaver, Fiddler и др.). Впервые поработал в гибкой методологии agile, ранее был знаком только с waterfall-ом. Моему счастью не было предела. Шутка =)

https://habr.com/ru/companies/rshb/articles/911580/

#тестирование #регрессионное_тестирование

Регрессионное тестирование: взгляд изнутри от лидера команды

Многие разработчики и начинающие тестировщики считают регрессионное тестирование рутинной и скучной работой. Максим Атлашкин, руководитель отдела регрессионного тестирования РСХБ-Интех, готов развеять...

Хабр

Тестирование без инцидентов в проде. Утопия или реальность?

Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь нулевого количества инцидентов в продакшене за отчётный период. Это не теория, а реальная история из проекта крупного банка, где мы внедрили систему процессов, позволившую минимизировать риски. Если вам интересен практический подход к предотвращению сбоев, давайте разберём его вместе.

https://habr.com/ru/companies/itfb/articles/911760/

#itfb #тестирование #регрессионное_тестирование #qa #agile #инцидентменеджмент #автоматизация_тестирования #разработка_по #разработка_приложений

Тестирование без инцидентов в проде. Утопия или реальность?

Всем привет! Я старший специалист по тестированию в ITFB Group. Сегодня хочу поделиться с вами практическим опытом нашей команды — как нам удалось достичь  нулевого количества инцидентов  в...

Хабр

Реестр систем ДОМ.РФ – «единое поле координат» для управления ИТ и синхронизации с командами

Привет, Хабр! Эта статья про то, как команда корпоративной архитектуры ДОМ.РФ выстраивала управление ИТ на основе единого реестра автоматизированных систем. В ней мы поделимся опытом, как и почему и пришли к этому решению, а также расскажем про плюсы и минусы данного подхода. Предыстория Для начала объясним, что из себя представляет группа ДОМ.РФ и её ИТ-ландшафт. Группа компаний ДОМ.РФ реализует нацпроекты в области жилищного строительства с 1997 года и развивает цифровизацию российской строительной отрасли и банковской сферы. В группу входит множество направлений – от собственного банка до лифтостроительного завода. Все направления имеют ИТ-составляющую и свои оцифрованные процессы.

https://habr.com/ru/companies/domrf/articles/901434/

#тестирование #нагрузочное_тестирование #боты #тестировщик #регрессионное_тестирование #тестирование_производительности

Реестр систем ДОМ.РФ – «единое поле координат» для управления ИТ и синхронизации с командами

Привет, Хабр! Эта статья про то, как команда корпоративной архитектуры ДОМ.РФ выстраивала управление ИТ на основе единого реестра автоматизированных систем. В ней мы поделимся опытом, как и почему и...

Хабр

День Сурка QA: как не застрять в цикле рутинных задач

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

https://habr.com/ru/articles/900660/

#Рутина #Задачи_QA #регрессионное_тестирование #багтрекинг #коммуникация #автоматизация #автоматизация_рутины #автоматизация_тестирования

День Сурка QA: как не застрять в цикле рутинных задач

Привет, Хабр! На связи  Евгений Гусинец  - Middle+ QA Engineer из Минска, ментор и автор ТГ-канала QA❤️4Life . Добро пожаловать в мою небольшую подборку "тестировочной рутины" и советов, как...

Хабр

QA. Расшиваем бутылочное горлышко регресса

Всем привет! Я Лид тестирования в одной из компаний и поделюсь своей историей решения проблемы, когда регрессионное тестирование становится бутылочным горлышком всего процесса. Предыстория. В этом году направление получило взрывной рост и количество команд утроилось (стало 15 команд), а количество QA‑ специалистов стало превышать 20+ человек. Довольно быстро выявились следующие проблемы...

https://habr.com/ru/articles/871694/

#регрессионное_тестирование #qa_management #qa_lead

QA. Расшиваем бутылочное горлышко регресса

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

Хабр

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд. В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным. Сразу уточню : я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения. Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки "на глаз" оказывались неточными. Ведь если заложить слишком много рисков – в продакшен попадут не все задачи, а если их не заложить – есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

https://habr.com/ru/articles/861640/

#тестирование #оценка_задач #qa #qa_процессы #регрессионное_тестирование #декомпозиция_задач #релиз #управление_процессами #qa_lead #оценка_трудозатрат

Точная оценка задач QA: возможно ли это?

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из...

Хабр

Подходы к сокращению регрессионного тестирования

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования. Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA. Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы. А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете. Плюс, регресс — штука дорогая, ведь в это время команда (особенно QA) не занимается созданием новой ценности для заказчика и пользователя, а перелопачивает старую.

https://habr.com/ru/companies/sportmaster_lab/articles/852200/

#тестирование #qa #тестирование_itсистем #регрессионное_тестирование

Подходы к сокращению регрессионного тестирования

Привет, Хабр! Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-подразделении Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела...

Хабр

Один в поле воин или не воин? Когда ты один тестировщик на 9 разработчиков. Часть 1

У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только один тестировщик. Рассказываю о своём опыте тестирования как единственного тестировщика на проекте. И удалось ли мне справится с такой нагрузкой работ.

https://habr.com/ru/articles/841566/

#опыт_работы #тестирование_вебприложений #тестирование_мобильных_приложений #регрессионное_тестирование #тестировщикикотики #тестировщик

Один в поле воин или не воин? Когда ты один тестировщик на 9 разработчиков. Часть 1

У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только единственный тестировщик. Как я себя чувствую, когда все разработчики присылают сборки на тестирование...

Хабр

Еще раз о регрессе: почему тестирование до сих пор вызывает вопросы?

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье для новичка о нем рассказывается. Вроде бы можно закрыть тему… Но почти каждый раз, когда на собеседовании я задаю вопрос: «Как мне выбрать тесты для регресса?», четкого ответа я не получаю. Это не зависит от уровня тестировщика, его опыта и направления. Из интереса я пристала к разработчикам, аналитикам, менеджерам и архитекторам с этим же вопросом, но получила лишь размытые формулировки и жалобы на то, что мы слишком долго проводим регресс и давно пора все автоматизировать. Такое происходит, потому что с виду простой вопрос содержит множество уровней, о которых обычно нет времени задуматься. Меня зовут Алена Вахтина и я ведущий специалист по тестированию в Лиге Цифровой Экономики. В этой статье постараюсь хотя бы частично рассмотреть такие подводные камни регрессионного тестирования.

https://habr.com/ru/companies/digitalleague/articles/815615/

#тестирование #регрессионное_тестирование #аналитика #регрессионный_анализ #автоматизация_тестирования #регресс

Еще раз о регрессе: почему тестирование до сих пор вызывает вопросы?

Писать о регрессе в 2024 году — казалось бы, странная идея: каждый, кто хоть как-то связан с IT-миром, знает, что такое регрессионное тестирование и зачем оно нужно. В каждом курсе, в каждой статье...

Хабр

Как защитить PROD от багов и себя от стресса

Сегодня хочу поговорить про баги на ПРОДе и о том как защитить команду от этого, ведь для реализации необходима помощь всей команды в выстраивании процессов разработки ПО. Прекрасное название этой статьи говорит само за себя - если не получается защитить команду от багов, то точно получиться защитить себя от стресса, ведь не все зависит от QA. Важно подсветить, что под багом подразумевается отличие ожидаемого результата от фактического. Мы ожидали, что при нажатии кнопки А будет окно В, но происходит совершенно другое. На схеме выше отображаются риски не только появления бага, но и не предусмотренных ошибок в виде программа не делает лучше, а только затрудняет использование. Первый риск: Идея попадает к аналитику Владелец продукта и аналитик на этапе проектирования тех. требований могут некорректно описать логику нового функционала (флоу). Заказчик имел ввиду одно, а по итогу в спецификациях совершенно другое. Решение данной проблемы может зависеть от правил взаимодействия с заказчиком в вашей команде. Второй риск: разработка по тех. требованиям Frontend и Backend разработчики берут задачи из бэклога в спринт, но в задаче может быть прикреплена устаревшая документация, ее может и вовсе не быть.

https://habr.com/ru/articles/804171/

#баги #тестирование #qa #qa_testing #разработка #testing #регрессионное_тестирование #приемочное_тестирование #процессы_разработки #команда_разработки

Как защитить PROD от багов и себя от стресса

Мне этот мир абсолютно понятен Привет, Хабр! Меня зовут Иван, я инженер по ручному и автоматизированному тестированию (Full Stack QA). В роли QA уже 2 года, веду телеграм канал о тестировании QAtoDev...

Хабр