Про регресс для самых маленьких
Очень часто студенты задают вопросы по регрессионному тестированию. Решил ответы на самые часты из них написать и здесь. Первые вопросы, о которых пойдет речь: когда же проводится регресс? И кто виноват в багах, найденных в процессе регресса?
Регрессионное тестирование обычно проводится перед релизом новой версии приложения. Это происходит следующим образом: в течение какого-то времени делаются какие-то фичи и другие задачи, они тестируются по отдельности и сливаются в общую ветку (мастер/девелоп - чаще всего эта ветка называется в зависимости от процессов в проекте). Дальше, когда время подходит к релизу от ветки девелопа создается ветка релиза, из которой собирается релиз-кандидат и на нем уже проводят регресс.
Часто встречаю ответ на вопрос «когда проводят регресс?» такой: после релиза. Нет, нет, и еще раз нет. Перед релизом мы должны убедиться, что выпускаем качественную версию нашего продукта, поэтому нам и нужно провести регрессивное тестирование нового билда.
А что если в процессе регресса были найдены баги? Ну, начнем с того, что хорошо, что эти баги нашлись сейчас тестированием, а не после релиза пользователями. Дальше надо уже разбираться отдельно с каждым конкретным багом. Какие могут быть причины:
- Низко-компетентная разработка. В таком случае, баги в процессе регресса будут регулярными. Это может быть связаны с кривым мержем задач версии, некорректно решенными конфликтами при мерже, невнимательности.
- Плохое качество тестирования. Когда тестировщик во время тестирования своей задачи пропустил какой-то кейс, а он потом всплыл при регрессе у другого тестера.
- Другие недостатки в процессах на проекте. Например, в одном релизе едут 2 фичи, которые как-то пересекаются друг с другом по функционалу, но которые тестировали 2 команды (тут может быть как проблема с коммуникациями в проекте, так и проблема в уровне квалификации тестировщиков и разработчиков, которые не взяли во внимание такое пересечение и менеджеров, которые впихнули 2 фичи в один релиз - такое должно быть допустимо только в крайних случаях и в качестве единичных акций, в остальных случаях стоит разбивать такое на 2 релиза и не рисковать качеством и конечной датой релиза).
Также не стоит забывать про обычный человеческий фактор и если такие ситуация проявляются не часто - то берите во внимание, анализируйте, проговаривайте с командой, но не делайте поспешных выводов и не принимайте радикальных решений.
Очень часто студенты задают вопросы по регрессионному тестированию. Решил ответы на самые часты из них написать и здесь. Первые вопросы, о которых пойдет речь: когда же проводится регресс? И кто виноват в багах, найденных в процессе регресса?
Регрессионное тестирование обычно проводится перед релизом новой версии приложения. Это происходит следующим образом: в течение какого-то времени делаются какие-то фичи и другие задачи, они тестируются по отдельности и сливаются в общую ветку (мастер/девелоп - чаще всего эта ветка называется в зависимости от процессов в проекте). Дальше, когда время подходит к релизу от ветки девелопа создается ветка релиза, из которой собирается релиз-кандидат и на нем уже проводят регресс.
Часто встречаю ответ на вопрос «когда проводят регресс?» такой: после релиза. Нет, нет, и еще раз нет. Перед релизом мы должны убедиться, что выпускаем качественную версию нашего продукта, поэтому нам и нужно провести регрессивное тестирование нового билда.
А что если в процессе регресса были найдены баги? Ну, начнем с того, что хорошо, что эти баги нашлись сейчас тестированием, а не после релиза пользователями. Дальше надо уже разбираться отдельно с каждым конкретным багом. Какие могут быть причины:
- Низко-компетентная разработка. В таком случае, баги в процессе регресса будут регулярными. Это может быть связаны с кривым мержем задач версии, некорректно решенными конфликтами при мерже, невнимательности.
- Плохое качество тестирования. Когда тестировщик во время тестирования своей задачи пропустил какой-то кейс, а он потом всплыл при регрессе у другого тестера.
- Другие недостатки в процессах на проекте. Например, в одном релизе едут 2 фичи, которые как-то пересекаются друг с другом по функционалу, но которые тестировали 2 команды (тут может быть как проблема с коммуникациями в проекте, так и проблема в уровне квалификации тестировщиков и разработчиков, которые не взяли во внимание такое пересечение и менеджеров, которые впихнули 2 фичи в один релиз - такое должно быть допустимо только в крайних случаях и в качестве единичных акций, в остальных случаях стоит разбивать такое на 2 релиза и не рисковать качеством и конечной датой релиза).
Также не стоит забывать про обычный человеческий фактор и если такие ситуация проявляются не часто - то берите во внимание, анализируйте, проговаривайте с командой, но не делайте поспешных выводов и не принимайте радикальных решений.