Комментарии 28
Как я понял, у вас не верно устроен жизненный цикл разработки, отсюда и не понимания и другие проблемы
Мне кажется, 1 тестировщик на 9 разрабов это вообще на грани фантастики. Я сама долгое время была одна на пятерых - и это был ад.
Да-да, именно, об этом я и говорила в команде. Даже был скрам в команде, а процессы все равно не настроил (как я поняла) как следует. Методология SAFe, которая предполагает самоорганизацию участников проекта без менеджеров :(
Тут единственный выход - разговаривать с тимлидом, продактом и, если не слышат, идти выше. Спрашивать о приоритетах, обрезать регресс где нанесет меньше вреда и т.д. Что я поняла пока была одна на пятерых - пока не откроешь рот - всем на тебя пофиг и даже больше - видя как "хорошо" ты справляешься от тебя будут хотеть всё больше притом без существенных изменений условий.
Да, я поднимала этот вопрос, и в команде соглашались со мной, что это невозможно так работать. Аналитики и разработчики шли на помощь в тестировании и в создании тест-кейсов (а потом просили проверить правильность написания тест-кейсов). Но тихо-тихо задачи все равно подкидывают. Сейчас попросила менеджера, который будет управлять процессом. Буквально вчера и пришла девушка оптимизировать процесс. В PI слишком много задач взяли - не рассчитали.
Спасибо большое за совет, учту <3
"Тихо-тихо подкидывают" - а вы не берите. Или требуйте пересмотра приоритетов. Если у вас есть объем работ на какой-то промежуток времени, то для вас он должен стать константой. Ну или какой-то объем должен быть необязательным, так сказать полезной нагрузкой если останется время.
О, даже вспомнила. С утра на дейлике говорю команде какие задачи выполняю (и ни слова о других заданиях нет) на текущий день. А потом ближе к концу рабочего дня налетают аналитики и PO с требованиям заниматься другой задачей, которую нужно было сделать вчера. D;
Можно попробовать делегировать часть работы.
Аналитикам доверить кейсы, хотя бы примерные. Или попросить нарисовать схему состояния и переходов.
Разработку озадачит юнит тестами. Или подключить к автоматизации api через постман, или любой другой аналог который позволяет запускать запросы коллекциями. Пишутся быстро, поддерживать просто.
И вот когда все осознают боль, будут ныть и жаловаться, придти к продакту (оценку на тестирование задачи прихватить с собой) и сказать что нужно ещё один тестер:)))
Ухх. Я бы точно не смог так сверхурочно работать. Ну если конечно что-то там эдакое в договоре не прописано конечно. Я сам 1 тестировщик в команде на 8 разрабов уже долгое время, и в принципе все ок, чрезмерной нагрузки нету, во многом потому что разрабов самих заставляют тестировать, но и спасает что большая часть функционала автоматизирована, так что руками приходится делать не так много как 3 года назад.
вот здесь про команду без тестировщика https://habr.com/ru/companies/maxilect/articles/722142/
я бы сделал следующее:
у тебя всегда должен быть сквозной список задач, со всех проектов
у тебя всегда должны быть оценены трудозатраты по всем задачам
если оба пункта выше будут выполняться, ты всегда сможешь составить таймлайн - в неделе 40 часов, успею сделать от пункта 1 до пункта 10
если приоритеты или сроки кого-то не устраивают - сразу же эскалируй. пусть приоритезацией занимается менеджеры проектов между собой, это вообще не твоя зона ответственности. на поиск компромиссов в таком ритме у тебя не будет времени. со сроками тоже самое - пусть обозначат что нужно сделать быстрее, тогда можно будет предложить варианты сокращения объёмов тестирования, подсветив риски которые это несёт
будут постоянно дёргать между проектами - напоминаем менеджерам, что на переключение между задачами тоже тратится время, процентов 10
нужно занять твёрдую позицию, максимально избавить себя от попыток всем угодить, ничем хорошим при таком объёме работ это не заканчивается. при этом обеспечить прозрачность для менеджеров по своим активностям
Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку.
Не совсем понимаю, зачем так "насиловать" тестировщика
кстати, временных авто-тестировщиков обещали. Команда ожидает
Тут больше вопрос. А как они раньше отработали? Почему вдруг тестирование стало камнем преткновения
Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.
у них же есть (наверное) опыт и компетенции, что бы протестировать самим и не терять время (время деньги(с)) в ожидании тестировщика
Я всей картины не знаю, но как будто тут вопрос в процессах
Я как понимаю work-life balance даже не заходил к вам?
Сочувствую вашим не прозрачным и не настроенным процесам..
Как показывает практика даже в команде сеньоров (2 бэка, 1 фронт) случаются ситуации когда надо чем то жертвовать (чаще всего документацией), если не хватает времени на тестирование функционала.
Попробовать разнести во времени релизы платформ.
Попробовать договориться с теми, кто ставит задачу о ее оформлении. Сэкономит время на разобраться 'чего надо'. Договориться, что задачи, которые не были оформлены не принимаются в работу. Как минимум, при наличии задач в работе/очереди. (Назовем это вынужденной бюрократией в условиях высокой нагрузки)
Попробовать эпизодически скидывать прохождение тестов на коллег. Себе оставить написание чек листов и кейсов для этих задач.
Не забывать уточнять: "А что будет если я не успею? Каковы реальные последствия? Точно нужно ради этого ночью работать? Нужно? А доплатите 2ю ставку? (если по ТК РФ)". Некоторые дедлайны могут быть мнимыми. Да. Кто-то что-то ждёт к определенной дате, но денежных или даже репутационных потерь нет. Просто 'хочется быстрее. Чтобы график красивый был. Просто пообещал.'.
Стараться участвовать в оценке задачи на этапе планирования. Закладывать тестирование в оценку. Напоминать, что дата сдачи в тест + оценка на тест != Дата окончания тестирования. Есть другие задачи. Бывают баги. И т.п.
P.S: берегите свой ресур. Не выгорайте. Так будет эффективнее.
Один в поле воин или не воин? Когда ты один тестировщик на 9 разработчиков. Часть 1