QA мануал, 120к. Опыт в резюме - 3 года, реальный - 2 месяца, на днях закрыл испыт.
Вышка по IT специальности, когда решил вкатываться в QA за плечами были пройденные курсы по веб-разработке, гит&гитхабу и питону, купленные на рутрекере.
Вкатился в QA в сумме месяца за 2. Около месяца вяло смотрел бесплатный курс на ютубе и собесы ксендзова, сделал резюме, с первого собеса получил оффер, принял.
Формально ненормированный день, по факту же работаю с 11-18, так как все активно работают в этом время и я вынужден с ними общаться по задачам. Работаем двухнедельными спринтами, активностей по типу дейликов, естимейтов etc. нету.
Само тестирование в теории процесс не сложный, разраб написал что задача залита, открыл на одном экране постановку, на другом сделанную фичу и сверяешь фактический результат с ожидаемым. На практике же большую часть рабочего времени я занимаюсь выяснением того, как задача должна быть сделана(иначе не понятно какое поведение ожидаемое), т.к. ~70% от всех задач это задачи бэкенда, а аналитики, не всегда имеют полное представление как должна выглядеть структура запроса и взаимодействия между сервисами.
Далее опишу процесс разработки так, как я его понимаю (первые 4 этапа разработки можете считать моей выдумкой, к ним отношения не имею):
1. Аналитики пишут постановку для задачи, с подробными особенностями реализации описывают как должен выглядеть функционал на бэке и на фронте.
2. Дизайнеры рисуют макеты.
3. В постановку вносятся финальные замечания со стороны команд разработки бэка и фронта(где-то здесь потерялось тестирование требований).
Лид бэка дает оценку времени задачи и решает какие задачи они могут взять в следующий спринт.
4. Команда бэка делает бэкенд часть задачи
5. Тестирование бэка. Базово при помощи постмана или сваггера(все что я тестирую общается только через REST) проверяю работоспособность эндпоинтов(сверяю поля, валидации с постановкой, смотрю отсутствие 500 ошибок)
Тут могут быть нюансы, для примера функционал задачи может требовать интеграции с другими модулями проекта, но в требованиях от аналитиков это не будет описано, в таком случае пишу в общий чат, описываю ситуацию, при необходимости собираю созвон, решаем как действовать дальше.
Задачи которые прошли тестирование отдаются аналитиками в команду фронта, лид фронта дает оценку времени всем задачам и говорит какие задачи могут взять в следующий спринт.
6. Команда фронта делает фронт часть задачи
7. Тестирование фронта. т.к. бэкенд был протестирован заранее на этом этапе сверяю верстку с макетами, проверяю валидации, смотрю все ли запросы отдаются без ошибок и все ли кнопочки нажимаются.
Если задача прошла тестирование на дев, сообщаю команде об этом и жду залива на тест, проверяю минимально там.
На прод-окружение захожу только по праздникам(катастрофам).
Так же в мои обязанности входит таск-трекинг, если правки по задаче долго не отдаются, могу написать разрабу, спросить как успехи, чаще всего просто забывают менять статус задачи на актуальный.

Присылай историю | Расти в IT