5 лет. Много легаси, много функционала, с которым проходит интеграция новых ТЗ
2. ТЗ в основном глобального плана, по регрессу почти любое может зацепить что угодно
3. Много новых людей, обучение на предмет элементарного знания системы (минимум по функционалу, что можно/нет, как примерн работает - занимает от 2х месяцев и более
4. Опыт в других проектах, как показывает практика, помогает слабо
5. Описаний старого функционала нет и появится не скоро (описывать много, долго, и к сожалению поверхностного описания не всегда достаточно для понимая)
6. Проблема с описанием ТЗ на достаточном для понимания уровне уже решена, ТЗ по новому функционалу есть. ТЗ не детальные, детальной инфы что зацепят изменения нет
Вопрос в следующем:
Как грамотно посторить работу отдела тестирования - как подступиться к процессу в подобных условиях?
С мобильного, поэтому выскажусь тезисно. 1. Документация должна быть обязательно. Тут либо привлекать аналитиков, потом за ними дописывать, либо сразу писать самим. 2. Должен быть написан тестплан, для этого опять же требуется большая работа по декомпозиции по фичам, дробления их на подфичи, написание планов и кейсов, анализ и согласование приоритетов с бизнесом. 3. В условиях постоянного регресса/тестирования сырых билдов и фичеветок пункты 1 и 2 практически не реализуются, работой заваливает с запасом. Вывод - нужно по максимуму отмазываться от вечного регресса. Пусть фичи сначала смотрят аналитики или разрабы, сокращается количество новых фичей, что-то уходит в прод без тестирования. Короче нужно выбирать чем жертвовать чтобы разгрести техдолг. Увеличивать количество людей в команде/автоматизация в помощь. Практически нереально качественно провести регресс вручную силами 1-3 человек на таком большом проекте.
Обсуждают сегодня