Мне кажется, что Плохой дизайн и архитектура является не самостоятельной причиной скопления дефектов, а причиной возникновения дополнительной сложности, что возвращает нас к пункту выше.
Что касается Частоты изменений. Тут тоже есть нюанс. Мне кажется, что частота изменений сама по себе не приводит к проблемам. Это просто увеличение вероятности просто за счет увеличения количества событий. Тут важнее наличие экспертизы и прогретого контекста (читай "Опыт разработчиков" помноженный на "Подробная документация" + "Время работы с конкретным модулем"). Если команда экспертов вносит много правок, то продукт/модуль будет становиться только лучше. (не без оговорок, конечно)
Попробовать договориться с теми, кто ставит задачу о ее оформлении. Сэкономит время на разобраться 'чего надо'. Договориться, что задачи, которые не были оформлены не принимаются в работу. Как минимум, при наличии задач в работе/очереди. (Назовем это вынужденной бюрократией в условиях высокой нагрузки)
Попробовать эпизодически скидывать прохождение тестов на коллег. Себе оставить написание чек листов и кейсов для этих задач.
Не забывать уточнять: "А что будет если я не успею? Каковы реальные последствия? Точно нужно ради этого ночью работать? Нужно? А доплатите 2ю ставку? (если по ТК РФ)". Некоторые дедлайны могут быть мнимыми. Да. Кто-то что-то ждёт к определенной дате, но денежных или даже репутационных потерь нет. Просто 'хочется быстрее. Чтобы график красивый был. Просто пообещал.'.
Стараться участвовать в оценке задачи на этапе планирования. Закладывать тестирование в оценку. Напоминать, что дата сдачи в тест + оценка на тест != Дата окончания тестирования. Есть другие задачи. Бывают баги. И т.п.
P.S: берегите свой ресур. Не выгорайте. Так будет эффективнее.
Information
Rating
Does not participate
Registered
Activity
Specialization
Test Automation Engineer, Quality Assurance Engineer
Мне кажется, что Плохой дизайн и архитектура является не самостоятельной причиной скопления дефектов, а причиной возникновения дополнительной сложности, что возвращает нас к пункту выше.
Что касается Частоты изменений. Тут тоже есть нюанс. Мне кажется, что частота изменений сама по себе не приводит к проблемам. Это просто увеличение вероятности просто за счет увеличения количества событий. Тут важнее наличие экспертизы и прогретого контекста (читай "Опыт разработчиков" помноженный на "Подробная документация" + "Время работы с конкретным модулем"). Если команда экспертов вносит много правок, то продукт/модуль будет становиться только лучше. (не без оговорок, конечно)
Попробовать разнести во времени релизы платформ.
Попробовать договориться с теми, кто ставит задачу о ее оформлении. Сэкономит время на разобраться 'чего надо'. Договориться, что задачи, которые не были оформлены не принимаются в работу. Как минимум, при наличии задач в работе/очереди. (Назовем это вынужденной бюрократией в условиях высокой нагрузки)
Попробовать эпизодически скидывать прохождение тестов на коллег. Себе оставить написание чек листов и кейсов для этих задач.
Не забывать уточнять: "А что будет если я не успею? Каковы реальные последствия? Точно нужно ради этого ночью работать? Нужно? А доплатите 2ю ставку? (если по ТК РФ)". Некоторые дедлайны могут быть мнимыми. Да. Кто-то что-то ждёт к определенной дате, но денежных или даже репутационных потерь нет. Просто 'хочется быстрее. Чтобы график красивый был. Просто пообещал.'.
Стараться участвовать в оценке задачи на этапе планирования. Закладывать тестирование в оценку. Напоминать, что дата сдачи в тест + оценка на тест != Дата окончания тестирования. Есть другие задачи. Бывают баги. И т.п.
P.S: берегите свой ресур. Не выгорайте. Так будет эффективнее.