У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только единственный тестировщик.
Здравствуй, Хабр! В этой статье хочу поделиться с вами о своем опыте работы на проекте, в котором я была единственным тестировщиком для проверки качества функционала web-приложения, компонента в мобильном приложении, микросервиса и реализации стандарта ISO20022 (на web, iOS, Android и на печатных форм). И как же я пыталась справиться с такой нагрузкой.
Напишу сразу спойлер: я инициировала запрос лидеру хаба на второго специалиста по тестированию, после чего этот ценный сотрудник появился в команде.
Затишье перед бурей
1-ая неделя: В команду я пришла на тот момент, когда в компании проводилось планирование итераций. За 4-е рабочих дня на мне не было никаких задач, я лишь только слушала организацию спринтов проекта участниками команды и потока в целом в зуме (методология SAFe). Заочно проходила онбординг на проект и изучала будущий фронт работ.
Что-то вне рабочего времени пыталась автоматизировать уже существующие тест-кейсы, чтобы сразу сократить регресс-тестирование (не увенчалось успехом из-за частого изменения верстки).
Приближается цунами!
Всё ещё 1-ая неделя: Пятница 7:00 просыпаюсь от звука уведомлений в телефоне (работаю на удалёнке). Мне пишет аналитик с просьбой помочь протестировать разработку команды в мобильном приложении. С функционалом проекта на мобилках я не была знакома и поэтому изучала его на ходу (да и в целом не было опыта тестирования мобильного приложения). Передали мне список задач (их было около 44-х без описания, а только лишь заголовки), которые нужно покрыть тест-кейсами, потому что в понедельник готовилась сборка релиз-кандидата для установки на предпродакшн среду.
Анализ задач, поиск и изучение требований, написание тест-кейсов, прикрепление тестов к этим таскам – заняло у меня все выходные. Само тестирование уже на тестовом стенде мобильного приложении, конечно, заняло ночь.
Цунами задач настигло. Прятаться негде!
Начало 2-ой недели: В этот же понедельник ко мне обратились и другие аналитики с задачами тестирования web-приложения и функционала, разработанный по стандарту ISO20022, после написали девелоперы, чтобы я протестировала микросервис. Знали ли они, что я тестирую мобильное приложение с горящими задачами? Да! (Просто в этой команде не было тестировщиков на полную ставку, приходил лишь тестер на регресс-тестирование по старому всё еще рабочему функционалу. И команда была рада увидеть специалиста по тестированию на полный рабочий день). Наивно отвечала коллегам «Возьму в работу», стараясь помочь команде разобрать кучу, заваливала переработкой себя саму (конечно же, снова ночные работы).
Вторник 2-ой недели: успешно завершила прогон по созданным тест-кейсам мобильного приложения для iOS и Android. Критические баги не были обнаружены. Список таск ушел в релиз на посадку. С облегчением выполненной работы в срок, решила сходить на обед. Спустя 5 минут прилетает мне вопрос от лидера хаба: «Ты провела регресс тестирование по web-приложению?» (СТОП! ЧТО? Я же вот-вот закончила проверку функционала мобильного приложения!!! Какой ещё регресс по сайту?).
За эти 5 минут я бы вряд ли смогла протестировать web-часть, поэтому задачи, которые бизнес-аналитики отправляли на посадку, отклонили.
В последствии узнала расписание релизов:
1. Релиз-кандидат web-приложения собирается каждую неделю у всего ARTа;
2. Релизная сборка по мобильным приложениям – каждые 2-е недели – также у всего потока команд.
Таким образом, каждая вторая неделя выпадает на параллельную посадку билда релиз-кандидатов двух платформ. И вторая неделя моего участия в команде попала в расписание двух сборок (web и mobile) выпуска продукции банка («Нервные срывы? Ха-ха-ха-ха-ха! Вы о чём?» *тихо плачет*).
Наводнение. Спасайтесь кто может!
Пыталась ли я как-то распределить лавину задач? Определенно! Так как процесс работы в команде знала очень плохо, составила план-тестирования. Изучила доску PI в Miro. Нашла задачи в Jira и добавила весь этот список в тест-план для наглядности объема тестирования (снова ночные смены) и общей картины в целом.
Приоритетов выпуска продукции нашей команды, признаюсь, не знала, и распределить поток тестирования было сложно. Кроме того, приоритеты вовсе поменялись от изначального варианта (и меняются до сих пор).
По итогу, уточнила преимущественный набор Jira-задач у владельца продукта и распределила назначенные таски в нужной последовательности.
Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.
Прибыла спасательная бригада
Из-за расстановки задач по их важности, накопилось 40+ заданий iOS и Android функционала. Поэтому запросила у лидера хаба помощь в лице еще одного тестировщика. Тестера дали, но временного на две недели (который в последствии профукал релиз веба (так же, как и я в начале участия в команде. Читайте выше), а после временный QA и приболел (бывает), но это уже другая история), пока ожидали постоянного . Временный QA сильно помог закрыть некоторые задачи веба за одну неделю работы, взяв на себя ответственность. За счет чего мне удалось потрудиться над компонентами мобильного приложения (терпеливые iOS и Android разработчики были этому рады). А потом у меня начался отпуск, который выпал на неделю важного web-релиза нового интерфейса модуля сайта («Гы-гы-гы» *хитро смеется*). Кстати, во время отпуска, команда писала с просьбой помочь протестировать функционал (помните же да, что временный тестировщик был на больничном?).
Что стало с двумя релизами web-функционала?
Список задач по web, которые чуть не были отклонены (не будем показывать пальцем) всё же были установлены на продакшн среде. Благодаря разработчикам совместное тестирование регресса завершилось за 50 минут;
Сборка веба, которая выпала на мой отпуск не вышла в среду эксплуатации, не только из-за отсутствия QA на проекте, но из-за очень сырого программного продукта, не было полного покрытия функционала тестами (+ я просила бизнес-аналитиков не отправлять новый функционал в продакшн, потому что в нем присутствует много багов, которые разработчики за пятницу вечер вряд ли успеют исправить).
Как обстоит тестирование с новым (постоянным!) QA-инженером и профукал ли он, по традиции, свой релиз? Расскажу во второй части статьи. Продолжение следует…
P.S. Если у вас есть опыт и вы можете дать совет, как справиться с нагрузкой и не сойти с ума, то с радостью почитаю ваши комментарии. :)
Комментарии (22)
JaneGame
07.09.2024 14:46+3Тут единственный выход - разговаривать с тимлидом, продактом и, если не слышат, идти выше. Спрашивать о приоритетах, обрезать регресс где нанесет меньше вреда и т.д. Что я поняла пока была одна на пятерых - пока не откроешь рот - всем на тебя пофиг и даже больше - видя как "хорошо" ты справляешься от тебя будут хотеть всё больше притом без существенных изменений условий.
AliyaTokareva Автор
07.09.2024 14:46+1Да, я поднимала этот вопрос, и в команде соглашались со мной, что это невозможно так работать. Аналитики и разработчики шли на помощь в тестировании и в создании тест-кейсов (а потом просили проверить правильность написания тест-кейсов). Но тихо-тихо задачи все равно подкидывают. Сейчас попросила менеджера, который будет управлять процессом. Буквально вчера и пришла девушка оптимизировать процесс. В PI слишком много задач взяли - не рассчитали.
Спасибо большое за совет, учту <3
JaneGame
07.09.2024 14:46+1"Тихо-тихо подкидывают" - а вы не берите. Или требуйте пересмотра приоритетов. Если у вас есть объем работ на какой-то промежуток времени, то для вас он должен стать константой. Ну или какой-то объем должен быть необязательным, так сказать полезной нагрузкой если останется время.
AliyaTokareva Автор
07.09.2024 14:46О, даже вспомнила. С утра на дейлике говорю команде какие задачи выполняю (и ни слова о других заданиях нет) на текущий день. А потом ближе к концу рабочего дня налетают аналитики и PO с требованиям заниматься другой задачей, которую нужно было сделать вчера. D;
Mad0Cat
07.09.2024 14:46+3
Делегирование;) Можно попробовать делегировать часть работы.
Аналитикам доверить кейсы, хотя бы примерные. Или попросить нарисовать схему состояния и переходов.
Разработку озадачит юнит тестами. Или подключить к автоматизации api через постман, или любой другой аналог который позволяет запускать запросы коллекциями. Пишутся быстро, поддерживать просто.
И вот когда все осознают боль, будут ныть и жаловаться, придти к продакту (оценку на тестирование задачи прихватить с собой) и сказать что нужно ещё один тестер:)))
vshopin
07.09.2024 14:46+1Ухх. Я бы точно не смог так сверхурочно работать. Ну если конечно что-то там эдакое в договоре не прописано конечно. Я сам 1 тестировщик в команде на 8 разрабов уже долгое время, и в принципе все ок, чрезмерной нагрузки нету, во многом потому что разрабов самих заставляют тестировать, но и спасает что большая часть функционала автоматизирована, так что руками приходится делать не так много как 3 года назад.
AliyaTokareva Автор
07.09.2024 14:46Вот сама уже думаю поднять вопрос об оплате переработок. Конечно бывает заканчиваю рабочий день пораньше, когда есть возможность, чтобы был баланс работы/отдыха. Но и соблюдать баланс не всегда удаётся
demsp
07.09.2024 14:46+1вот здесь про команду без тестировщика https://habr.com/ru/companies/maxilect/articles/722142/
Je_t
07.09.2024 14:46+1я бы сделал следующее:
у тебя всегда должен быть сквозной список задач, со всех проектов
у тебя всегда должны быть оценены трудозатраты по всем задачам
если оба пункта выше будут выполняться, ты всегда сможешь составить таймлайн - в неделе 40 часов, успею сделать от пункта 1 до пункта 10
если приоритеты или сроки кого-то не устраивают - сразу же эскалируй. пусть приоритезацией занимается менеджеры проектов между собой, это вообще не твоя зона ответственности. на поиск компромиссов в таком ритме у тебя не будет времени. со сроками тоже самое - пусть обозначат что нужно сделать быстрее, тогда можно будет предложить варианты сокращения объёмов тестирования, подсветив риски которые это несёт
будут постоянно дёргать между проектами - напоминаем менеджерам, что на переключение между задачами тоже тратится время, процентов 10
нужно занять твёрдую позицию, максимально избавить себя от попыток всем угодить, ничем хорошим при таком объёме работ это не заканчивается. при этом обеспечить прозрачность для менеджеров по своим активностям
Litovsky83
07.09.2024 14:46+1Почему бы не посадить на тестирование dev команду? Фронты вполне могут покрывать автотестами ui и проводить приемку.
Не совсем понимаю, зачем так "насиловать" тестировщикаAliyaTokareva Автор
07.09.2024 14:46кстати, временных авто-тестировщиков обещали. Команда ожидает
Litovsky83
07.09.2024 14:46Сможет ли это решить проблему? У вас потенциально 5–7 автотестеров-разработчиков, почему бы их не использовать? За качество вы же все отвечаете.
Но решать, конечно, вам.
Litovsky83
07.09.2024 14:46+1Пришлось пожертвовать одной платформой (это мобильное приложение), так как веб был более важнее (по словам бизнес-аналитиков). Разработчики iOS и Android терпеливо ждали тестирования функционала.у них же есть (наверное) опыт и компетенции, что бы протестировать самим и не терять время (время деньги(с)) в ожидании тестировщика
Я всей картины не знаю, но как будто тут вопрос в процессахAliyaTokareva Автор
07.09.2024 14:46Кстати, был кейс, где разраб писал тест-кейсы. Пришлось их переписывать :(
endpoints
Как я понял, у вас не верно устроен жизненный цикл разработки, отсюда и не понимания и другие проблемы
JaneGame
Мне кажется, 1 тестировщик на 9 разрабов это вообще на грани фантастики. Я сама долгое время была одна на пятерых - и это был ад.
AliyaTokareva Автор
Да-да, именно, об этом я и говорила в команде. Даже был скрам в команде, а процессы все равно не настроил (как я поняла) как следует. Методология SAFe, которая предполагает самоорганизацию участников проекта без менеджеров :(