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

от автора

У нас было два пакетика травы… 1 product owner, 9 разработчиков, 5 аналитиков и только единственный тестировщик.

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

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

Здравствуй, Хабр! В этой статье хочу поделиться с вами о своем опыте работы на проекте, в котором я была единственным тестировщиком для проверки качества функционала web-приложения, компонента в мобильном приложении, микросервиса и реализации стандарта ISO20022 (на web, iOS, Android и на печатных форм). И как же я пыталась справиться с такой нагрузкой.

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

Затишье перед бурей

1-ая неделя: В команду я пришла на тот момент, когда в компании проводилось планирование итераций. За 4-е рабочих дня на мне не было никаких задач, я лишь только слушала организацию спринтов проекта участниками команды и потока в целом в зуме (методология SAFe). Заочно проходила онбординг на проект и изучала будущий фронт работ.

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

Приближается цунами!

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

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

Цунами задач настигло. Прятаться негде!

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

Моё лицо, когда узнала о регресс-тестировании web-приложения

Моё лицо, когда узнала о регресс-тестировании web-приложения

Вторник 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-функционала?

  1. Список задач по web, которые чуть не были отклонены (не будем показывать пальцем) всё же были установлены на продакшн среде. Благодаря разработчикам совместное тестирование регресса завершилось за 50 минут;

  2. Сборка веба, которая выпала на мой отпуск не вышла в среду эксплуатации, не только из-за отсутствия QA на проекте, но из-за очень сырого программного продукта, не было полного покрытия функционала тестами (+ я просила бизнес-аналитиков не отправлять новый функционал в продакшн, потому что в нем присутствует много багов, которые разработчики за пятницу вечер вряд ли успеют исправить).

Как обстоит тестирование с новым (постоянным!) QA-инженером и профукал ли он, по традиции, свой релиз? Расскажу во второй части статьи. Продолжение следует…

P.S. Если у вас есть опыт и вы можете дать совет, как справиться с нагрузкой и не сойти с ума, то с радостью почитаю ваши комментарии. 🙂


ссылка на оригинал статьи https://habr.com/ru/articles/841566/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *