Как стать автором
Обновить

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

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров5.6K
Всего голосов 3: ↑3 и ↓0+3
Комментарии28

Комментарии 28

Как я понял, у вас не верно устроен жизненный цикл разработки, отсюда и не понимания и другие проблемы

Мне кажется, 1 тестировщик на 9 разрабов это вообще на грани фантастики. Я сама долгое время была одна на пятерых - и это был ад.

Да-да, именно, об этом я и говорила в команде. Даже был скрам в команде, а процессы все равно не настроил (как я поняла) как следует. Методология SAFe, которая предполагает самоорганизацию участников проекта без менеджеров :(

Тут единственный выход - разговаривать с тимлидом, продактом и, если не слышат, идти выше. Спрашивать о приоритетах, обрезать регресс где нанесет меньше вреда и т.д. Что я поняла пока была одна на пятерых - пока не откроешь рот - всем на тебя пофиг и даже больше - видя как "хорошо" ты справляешься от тебя будут хотеть всё больше притом без существенных изменений условий.

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

Спасибо большое за совет, учту <3

"Тихо-тихо подкидывают" - а вы не берите. Или требуйте пересмотра приоритетов. Если у вас есть объем работ на какой-то промежуток времени, то для вас он должен стать константой. Ну или какой-то объем должен быть необязательным, так сказать полезной нагрузкой если останется время.

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

Тогда надо говорить "я возьму задачу Б, но тогда не сделаю задачу А"

Делегирование;)
Делегирование;)

Можно попробовать делегировать часть работы.

Аналитикам доверить кейсы, хотя бы примерные. Или попросить нарисовать схему состояния и переходов.

Разработку озадачит юнит тестами. Или подключить к автоматизации api через постман, или любой другой аналог который позволяет запускать запросы коллекциями. Пишутся быстро, поддерживать просто.

И вот когда все осознают боль, будут ныть и жаловаться, придти к продакту (оценку на тестирование задачи прихватить с собой) и сказать что нужно ещё один тестер:)))

Ухх. Я бы точно не смог так сверхурочно работать. Ну если конечно что-то там эдакое в договоре не прописано конечно. Я сам 1 тестировщик в команде на 8 разрабов уже долгое время, и в принципе все ок, чрезмерной нагрузки нету, во многом потому что разрабов самих заставляют тестировать, но и спасает что большая часть функционала автоматизирована, так что руками приходится делать не так много как 3 года назад.

Вот сама уже думаю поднять вопрос об оплате переработок. Конечно бывает заканчиваю рабочий день пораньше, когда есть возможность, чтобы был баланс работы/отдыха. Но и соблюдать баланс не всегда удаётся

вот здесь про команду без тестировщика https://habr.com/ru/companies/maxilect/articles/722142/

спасибо большое <3

я бы сделал следующее:

  1. у тебя всегда должен быть сквозной список задач, со всех проектов

  2. у тебя всегда должны быть оценены трудозатраты по всем задачам

  3. если оба пункта выше будут выполняться, ты всегда сможешь составить таймлайн - в неделе 40 часов, успею сделать от пункта 1 до пункта 10

  4. если приоритеты или сроки кого-то не устраивают - сразу же эскалируй. пусть приоритезацией занимается менеджеры проектов между собой, это вообще не твоя зона ответственности. на поиск компромиссов в таком ритме у тебя не будет времени. со сроками тоже самое - пусть обозначат что нужно сделать быстрее, тогда можно будет предложить варианты сокращения объёмов тестирования, подсветив риски которые это несёт

  5. будут постоянно дёргать между проектами - напоминаем менеджерам, что на переключение между задачами тоже тратится время, процентов 10

  6. нужно занять твёрдую позицию, максимально избавить себя от попыток всем угодить, ничем хорошим при таком объёме работ это не заканчивается. при этом обеспечить прозрачность для менеджеров по своим активностям

спасибо огромное. Отличный совет! Возьму на вооружение <3

Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку.
Не совсем понимаю, зачем так "насиловать" тестировщика

кстати, временных авто-тестировщиков обещали. Команда ожидает

Сможет ли это решить проблему? У вас потенциально 5–7 автотестеров-разработчиков, почему бы их не использовать? За качество вы же все отвечаете.

Но решать, конечно, вам.

да, можно попробовать, кстати

Тут больше вопрос. А как они раньше отработали? Почему вдруг тестирование стало камнем преткновения

Все задачи прошлых спринтов как раз легли на меня. То есть, не отправляли задачи на посадку. Тестировали только старый функционал, проверяли, что ничего не сломалось и всё

Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.

у них же есть (наверное) опыт и компетенции, что бы протестировать самим и не терять время (время деньги(с)) в ожидании тестировщика
Я всей картины не знаю, но как будто тут вопрос в процессах

Кстати, был кейс, где разраб писал тест-кейсы. Пришлось их переписывать :(

Я как понимаю work-life balance даже не заходил к вам?

вообще нет :D (*нервно смеется*)

Сочувствую вашим не прозрачным и не настроенным процесам..

Как показывает практика даже в команде сеньоров (2 бэка, 1 фронт) случаются ситуации когда надо чем то жертвовать (чаще всего документацией), если не хватает времени на тестирование функционала.

  1. Попробовать разнести во времени релизы платформ.

  2. Попробовать договориться с теми, кто ставит задачу о ее оформлении. Сэкономит время на разобраться 'чего надо'. Договориться, что задачи, которые не были оформлены не принимаются в работу. Как минимум, при наличии задач в работе/очереди. (Назовем это вынужденной бюрократией в условиях высокой нагрузки)

  3. Попробовать эпизодически скидывать прохождение тестов на коллег. Себе оставить написание чек листов и кейсов для этих задач.

  4. Не забывать уточнять: "А что будет если я не успею? Каковы реальные последствия? Точно нужно ради этого ночью работать? Нужно? А доплатите 2ю ставку? (если по ТК РФ)". Некоторые дедлайны могут быть мнимыми. Да. Кто-то что-то ждёт к определенной дате, но денежных или даже репутационных потерь нет. Просто 'хочется быстрее. Чтобы график красивый был. Просто пообещал.'.

  5. Стараться участвовать в оценке задачи на этапе планирования. Закладывать тестирование в оценку. Напоминать, что дата сдачи в тест + оценка на тест != Дата окончания тестирования. Есть другие задачи. Бывают баги. И т.п.

  6. P.S: берегите свой ресур. Не выгорайте. Так будет эффективнее.

Спасибо Вам большое за ценный совет <3

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории