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

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

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров3.2K

Ранее в 1-й части статьи писала об STLC проекта с веб- и мобильной разработкой, который осуществлял переход не только на новый интерфейс, но и с монолита на микросервис. Из-за чего тестирование веб-приложения удваивалось, а в мобильной части проверок было четыре (iOS и Android).

Мы сделали велосипед!

 Флешбэки: «Всё ещё 1-ая неделя: Пятница 7:00 просыпаюсь от звука уведомлений в телефоне (работаю на удалёнке). Мне пишет аналитик с просьбой помочь протестировать разработку в мобильном приложении.»

За первые две недели на проекте проверила качество функционала более 60 задач и составила около 500 тестов. Коллеги заваливали сообщениями о новых тасках, ожидающих проверки качества. Рабочее время увеличивалось до 16 часов в будний день. А окончание итерации (спринта) заставило смеяться смехом Джокера (Хоакин Феникс) - последняя таска оказалась медным тазом из-за её особенности - девелопер закомментировал блок кода, в который и входил весь протестированный мною функционал New CJM… Впоследствии разработка нового UI и микросервиса не тестировалась на предпродакшн среде и ушла в релиз в виде комментария.

Но не стоит переживать, на предпроде было что проверить - это старый CJM (его разработка всё еще велась). Проверив качество, со спокойной душой закончила рабочий день («казалось бы»). Позже выясняю: бизнес‑аналитик перенаправляла мне таски функционала, который находится уже у пользователей (то есть, тестировать нет необходимости)…Да, именно по старому флоу («Это велосипед, Карл! Это велосипед!»). В силу низкой компетенции, аналитик хотела таким образом закрыть неактуальные задачи (напоминаю, на тот момент я на проекте была всего вторую неделю и выяснить устаревшие задачи было сложно).

По этой причине тестирование отставало от разработки на полтора PI. Задачи в статусе «Готово к тестированию» висели более двух месяцев.

Спойлер: Это были цветочки.

Продолжение вечера

Узнав новость, вышла на улицу перевести дух. Конец августа. Было темно, шел мелкий дождь. Получаю сообщение в мессенджере: «Нужно срочно протестировать функционал на Android!». У задачи отсутствовали тесты, стоял статус «Готово к тестированию». Как правило, такая таска не подлежит к отправке в релиз. Разработчик, готовивший предрелизную сборку, не знал рабочий процесс проекта. Команде дали два выбора:

  1. Протестировать всё (создание тестов, трехэтапное согласование акта, отправка задачи бизнес-аналитику на проверку, далее релиз-менеджеру);

  2. Удалить не протестированный функционал из предрелизного контейнера.

Еженедельно по пятницам в восемь вечера, ребята, отвечающие за среду эксплуатации, отправляли в продакшн финальную сборку разработок всех команд. До выкладки оставалось минут 10–15. Как думаете, какой вариант победил, учитывая, что техлид по Android разработке поддержал программиста?

Помогите! Я тону!

Организовала созвон с руководителями, дабы попросить помощи в разгрузке взвалившийся на меня работы. Обговорив детали, пришли к договоренности:

  1. Линейный руководитель берет на себя обязанности по перераспределению задач тестирования;

  2. QA из отдела «Центр компетенций» оптимизирует рабочий процесс команды.

Ещё спойлер: Линейный руководитель не выполнил свои обязанности. QA не участвовала в менеджменте рабочего процесса, а лишь предоставила документ «Кодекс процесса работ».

Помните говорила о втором тестере? Он пришел (Постоянный! Не временный!). Конечно же здесь есть НО: тестировщик попросил две недели на адаптацию и грозился увольнением, если его кто-то тронет нагрузит работой. По окончании его онбординга я немного вздохнула. Естественно, от него поступали вопросы о самом продукте, новый участник команды не имел нужных доступов и мобильных устройств. Регресс-тестирование сотрудник еще не проводил (лидер хаба запрещала), ну и тесты на тот момент писал плохо (опыт работы менее года) — из‑за чего появилась дополнительная нагрузка в виде наставничества. Продуктивная работа с тестировщиком принесла значительные плоды. Расстояние между тестированием и разработкой сократилось.

Дежавю?

Думаете инцидент с не протестированным функционалом задач в предрелизном контейнере закончен? Нет. Тот же самый Android-разработчик вновь повторил ситуацию, хотя ранее команда обговаривала план сборки. За 10 минут до релиза, программист поместил в предпрод билд, который содержал 11 тасок в статусе «Готово к тестированию» (забегая вперёд: в ходе перепалки разработчик врал команде о согласовании отправки задач в релиз SEMом). Снова пришел техлид Android с теми же самыми двумя вариантами на выбор. На этот раз перерабатывать не пришлось, но ценой обесценивания своего труда и троллингом со стороны технического лидера Android.

Разработчик успешно исправил свою ошибку, расхваливая себя как спасателя команды.

Факап Android-программиста привел к тому, что выпуск разработок всего потока (всех команд ARTa) передвинулся на выходной день.

И жили они долго и «счастливо»

Опущу все подробности сложных коммуникаций и прочее. В последние два спринта нам, а именно разработчикам и тестировщикам удалось наладить SDLC в момент, когда product owner, бизнес-аналитики и прочие менеджеры были на обучении. Тестеры со своей стороны объяснили Android-разработчику процессы тестирования и подготовки к релизу.

Мы запланировали список тасок, программисты подготовили контейнеры без лишних задач, а тестеры успешно проверили качество разработки.

Последний спойлер: после бизнес-аналитики сломали нашу конструкцию, впихивая свои задачи, не входящие в релизный план.

Но все равно успели протестировать и запланированный пулл задач, и таски, предоставленные аналитиками.

В финальном PI команда выпустила обновление до дедлайна из-за чего выиграла в номинации "Прорыв года".

Какой итог?

С начала нового года проект поделили на более маленькие подпроекты. А я уволилась с астено-невротическим синдромом до всех упрощений.

P.S. Возможно вы скажете, что можно избежать переработки, не отвечая на сообщения после рабочего дня. Но у заказчика были инструменты воздействия на меня в виде служебных записок с жалобами (получила такую, когда в конце рабочего дня объявила о завершении своей работы. К тому же заказчик перефразировал мои слова в негативном контексте), а инструментов противодействия я не имела, так как работала аутстаффом, а заказчик не из РФ.

Теги:
Хабы:
Всего голосов 5: ↑3 и ↓2+3
Комментарии5

Публикации