как вы считаете какими задачами занят тестировщик в свой обычный рабочий день
Будни тестировщика, или при чем тут Пирамида Маслоу
С некоторых пор в Яндекс.Деньгах все продукты состоят из множества микросервисов, для которых выходит до десятка обновлений в день. Кроме того, регулярно приходится проверять на прочность весь платежный сервис – насколько он выдерживает пиковые нагрузки, есть ли запас прочности.
Именно поэтому подразделение тестирования ПО у нас одно из самых многочисленных. Среди тестировщиков больше всего специалистов-функциональщиков. В этой статье я на примерах расскажу, чем занимаются эти ребята и какие инструменты используют в работе.
В отделе есть еще специалисты по производительности, а также мобильному и интеграционному тестированию, но о них в другой раз.
Группа функционального тестирования проверяет работоспособность сервисов, над которыми вся продуктовая команда трудится в течение квартала. В основном проверки ручные – автотесты здесь пишут для часто повторяющихся сценариев. Кроме того, «функциональщики» выполняют обязанности техподдержки в сложных и непонятных случаях.
Отдел состоит у нас из пяти направлений:
Что важнее: знать жизненный цикл разработки или как работает интернет
Просматривая сотни вакансий на профильных сайтах, можно подумать, что тестировщику нужно знать назубок методологию разработки, несколько языков программирования и иметь начальные навыки управления космическим шаттлом. В нашей парадигме принято ожидать, что тестировщик знает IT-алфавит и умеет составлять из него осмысленные «слова».
Можно воспринимать этот алфавит как фундамент пирамиды Маслоу, без которого по-настоящему понимать, как работает тот самый интернет, не получится.
У нас не принято назначать сверху «тестовый план» и даже нет выделенного тест-лида для распределения задач. Каждый тестировщик должен сам понимать, чем сейчас нужно заниматься, поэтому уровень личной ответственности достаточно высокий. Разумеется, общее понимание работы ключевых компонент компании тут здорово поможет, однако первое время все равно придется уточнять приоритеты в непонятных ситуациях у менеджеров проектов.
Поэтому новичку стоит смириться, что первые полгода он будет по каждому чиху спрашивать коллег из тестирования, из своей команды, из отдела аналитики.
Убрать это неловкое чувство беспомощности можно, только плотно «поварившись» в конкретной команде. Благодаря этому можно сэкономить от пары часов до нескольких дней на проверке совершенно всех сценариев ошибки. Простой пример: пользователь снимает деньги в банкомате, но вместо наличных получает «что-то пошло не так».
Если предложить разобраться в проблеме новичку, он начнет с проверки всех пришедших в голову сценариев оплаты и всех возможных исходов. Если же этот человек уже успел познать дзен внутреннего устройства и взаимосвязей всех участвующих компонент, он сможет сфокусировать усилия на конкретном процессе снятия денег и трех-пяти участвующих компонентах.
В первый месяц новички узнают больше про архитектуру приложения, REST API, JSON. Становятся ближе к Linux, знакомятся с языком запросов SQL и с гибкими методологиями разработки, автотестами. А также познают основы Java и Kotlin – последний показался нам удобным для автотестов благодаря более лаконичному и компактному итоговому коду.
Автотесты, к слову, у нас пишут все – если для тестировщика программирование выглядит чем-то с другой планеты, то накидывать в нужном порядке методы из нашего фреймворка он всё равно будет способен. А со временем и знания алгоритмов и языков подтянет.
Погружаться во фронтенд или бэкенд
Очень популярен среди начинающих тестировщиков подход «тестирование – это про то, чтобы прокликать все кнопки на сайте, можно быстро кликать UI и всегда быть востребованным», однако это не всегда упрощает поиск работы и дальнейший карьерный путь. К примеру, большинство сервисов Яндекс.Денег состоят из фронтенд- и бэкенд-частей, и у нас нет разделения тестировщиков по этим категориям.
Вместо группировки тестировщиков по технологиям мы назначаем их в команду разработки того или иного продукта, где фокус может быть смещен в сторону фронта или бэка. Но в любом случае эти компоненты часто перекликаются, и уметь работать с обоими необходимо.
К примеру, у нас есть внутренний инструмент для контакт-центра – веб-сервис с информацией обо всех пользовательских обращениях. В ходе очередного проекта инструмент получил новую сводную страницу, которая упрощает отслеживание состояний тикетов и соблюдения SLA.
Для новой версии нужно было сделать следующее:
Любой проект начинается с технического решения, после реализации которого к процессу подключается тестировщик.
Обычно все начинается с технического решения, которое готовят аналитики, разработчики и руководители проектов. В решении непременно указывается, какие компоненты задействованы, какие в них должны быть обработки и что за сущности нужно добавить или доработать на бэкенде и фронте.
На планировании проекта решение декомпозируется на задачи разработчиков, что позволяет тестировать их по мере выпуска. В такие моменты день тестировщика выглядит примерно так:
1. Утром формируешь себе список задач на день из текущего спринта. Делается это с помощью канбан-доски в Jira, где приоритет отдается срочным вещам вроде багов. Остальные приоритеты распределяет руководитель проекта. Теперь главное – двигаться по списку и просто так его не перекраивать.
2. Проверяешь компоненты реализованных задач, обычно начиная с бэкенда, потому что он запускается в разработку раньше и фронт без бэка все равно не появится.
3. Чтобы что-то проверить, нужно знать, как все это работает в задумке. Поэтому у каждого проверяемого метода должно быть описание (что на вход, что на выход и т.п.). Но обычно информации не хватает (что понятно разработчику, не всегда понятно остальным), в этом случае сильно помогают Swagger и отзывчивые коллеги. Добытые знания полезно добавить в техническое решение, для пользы остальным и для истории.
У нас в инфраструктуре широко используется REST API, поэтому частый сценарий тестирования – запросы HTTP, отправляемые через Postman.
К слову об инструментах – в ежедневной работе наши тестировщики используют следующий набор:
Выбор конкретного инструмента зависит от личных предпочтений тестировщика и наличия инструмента на целевом хосте.
Периодически приходится копать глубже и переключаться в debug-режим в конфигурации тестируемого приложения. Главное, не забыть снять флаг этого режима, как только вся необходимая информация собрана, чтобы ненароком не остановить приложение из-за перерасхода дискового пространства.
Обычно тестирование бэкенд-части заключается в отправке запроса с необходимыми входными данными, получении ответа и проверке, что результат соответстветствует документации. Эта простая цепочка часто спотыкается, например, о необходимость проверить запись результатов POST-запроса в БД. Для этого проще всего вручную зайти в БД через агента СУБД и проверить корректность данных.
Поэтому нужно локально зайти на сервер с базой (например, PostgreSQL) или через pgadmin и выполнить запрос на выборку интересующих данных. Язык SQL знать не обязательно, так как все можно сделать в графическом интерфейсе pgadmin. Однако совсем базовые конструкции SQL-запросов знать все же желательно (SELECT*, WHERE, ORDER BY).
Например, в БД может быть 10 000 записей, и искать данные через GUI может быть слишком долго. В общем, тестировщику хорошо бы уметь быстро написать в консоли запрос вида:
Всё остальное – приятный бонус.
О балансе тестирования и межведомственном общении
Самостоятельность тестировщику нужна не только для выбора задач, но и для проведения серии тестов – нужно всегда искать баланс между «проверить все, что можно» и временем на это. Нет смысла проверять все возможные значения и сценарии в компоненте, если он уже получает данные из специальной формы с проверкой значений.
К примеру, есть метод, который принимает на вход только строковые переменные, и нужно проверить, что будет при передаче туда скриптов (к слову о безопасности) или переменных Integer. Даже составлять перечень таких данных очень долго, не успеешь выполнить другие задачи. В выборе разумного перечня тестов помогут уже готовые user stories. В сущности, фронтенд уже ограничивает ввод некоторых параметров, что резко сужает список проверок.
Некоторые задачи требуют проверки в условиях, приближенных к боевым, – например, на тестовой среде трудно полностью проверить платёж картой, проходящий через всех эквайеров и платежные системы. Поэтому проверка проходит на нашем preproduction – несколько фронтэнд-хостов, отключенных от балансировщика и доступных только из нашей сети по прямому URL.
По сравнению с тестовой средой, проверять сценарии в «боевых» условиях не так удобно из-за отсутствия некоторых доступов, да и настоящие деньги тратить не хочется. Поэтому на preprod-окружении мы проверяем только ограниченный приемочный набор тестов.
Интересно обстоят дела с проектами, где задействована не только наша компания, но и партнеры. Хороший пример – поддержка бонусной программы партнера, для которого Яндекс.Касса выступает как платежное решение. Кассе нужно уметь передавать ему информацию о бонусах и осуществлять, например, погашение ими части покупки – зависит от желания покупателя и возможностей бонусной программы.
Вся соль таких проектов – в «межведомственном взаимодействии», когда для успеха нужны определенные действия с той стороны.
Если помните прошлую статью о подборе тестировщика, то там важное значение имел навык общения – умение со всеми договариваться. И тут оно пригодится как нигде. При совместном проекте с любым партнером, с которым мы обмениваемся специфической информацией, необходимо получить рабочую тестовую среду и сами данные. Последнее может быть пулом партнерских карт, среди которых есть заблокированные, условно-неподдерживаемые бонусной программой и т.п.
Кроме тестовой среды и данных, нужен также канал коммуникации (обычно Telegram, который нравится партнерам и под который написано много ботов для собственных нужд) для оперативного общения технических специалистов. Когда подготовительные работы проведены, остается дождаться готовности проверяемого метода на стороне партнера.
Например, рассмотрим подробнее проверку метода типового платежа, которая состоит из следующей цепочки действий:
После проверки положительного сценария проверяются негативные. Например, привязываем не участвующую в бонусной программе карту и пытаемся провести запрос. Еще можно сымитировать сетевой таймаут и проверить, дождемся ли мы ответа на запрос, а также какие будут коды ошибки в случае неудачи выполнения запроса.
Такая цепочка действий в дальнейшем автоматизируется для ускорения повторных тестов. Сами автотесты пишутся на Java или Kotlin.
Однажды на собеседовании после вопроса, что такое первичный ключ, меня в ответ спросили: «зачем вы это спрашиваете? Открываешь Хабр, там каждая вторая статья про блокчейн, нейро-сайенс и искусственный интеллект, а вы тут про первичные ключи». Эта статья – попытка объяснить, что знания тестировщика – это своеобразная пирамида Маслоу и без знания базовых вещей на следующие уровни не перепрыгнешь.
Базы данных, коды HTTP-ответов и консоль Linux – это своеобразный алфавит, который вам позволяет осмысленно говорить на языке IT-индустрии. Без них вы будете сидеть в китайской комнате, не особенно понимая, что вас спрашивают, но зная, какой ответ от вас ожидают.
Таким образом, мы ждем от нового человека не просто знания алфавита, а умения складывать из терминов предложения и способности понимать, что это значит на самом деле.
Рабочий день тестера
Что я буду делать в свободный день:
поиграю в самолетики под кроватью,
совершу мелкое хулиганство над печенью,
поищу место под солнцем, накормлю жадные пальцы,
поражу красноречием, пренебрегу приличиями.
facebook (Дети диаграммы Ганта)
У вас видимо очень хорошо построен процесс планирования.
А вообще, насколько я представляю, рабочий день тестера прыгает в разных ситуациях и разных компаниях от 0 часов в день и бывает до 20.
Да собственно рабочий день тестировщика зависит от планирования всех процессов.
А вообще, насколько я представляю, рабочий день тестера прыгает в разных ситуациях и разных компаниях от 0 часов в день и бывает до 20.
facebook (Дети диаграммы Ганта)
Хотел бы я поработать под вашим началом 🙂
Ну вот представьте себя на перегретом рынке, где огромное количество конкурентов, есть общепризнанные короли, а есть и темные лошадки. Вы где-то в середине. Представьте себе проект, который идет вровень с конкурентами до самой своей, скажем, публичной беты.
И вот, в процессе беты, какая-то темная лошадка выдает свою бету с некой фичей, которая всем вашим клиентам видится весьма и весьма полезной. Настолько полезной, что они готовы перебраться к конкуретну.
Извините, задело. И прошу прощения за слог. Есть все-таки места, где приходится перерабатывать, просто чтобы успеть за конкурентами. Рынок диктует свои условия. Конкуренты не спят, а тоже работают. И далеко не всегда по 40 часов в неделю.
Вообще, в 99% случаях переработки виноват менеджер и топ менеджер. Одновременно.
Ну, про 0 часов я сообщил не из своего опыта работы. Просто ко мне пришел сотрудник, которому надоело сидеть в предыдущей компании без дела, так как его уже месяц не включали ни в один проект.
А сам я самое позднее по делам тестирования уходил пару лет назад во втором часу ночи.
Соответственно, могу предположить, что и 20-часовой рабочий день не предел.
И абсолютно согласен, что в большинстве переработок виноват топ и миддл-менеджмент.
Ну, само собой специфика выпуска продукта на заказ или для рынка заметно влияет на условия работы.
Но в приведенном затем примере в результате-то всё-равно окончательное решение принимает топ-менеджмент. И, как мне кажется, оно также далеко не всегда бывает оптимальным.
Как проходит рабочий день тестировщика на удалёнке в Bercut
Авторизуйтесь
Как проходит рабочий день тестировщика на удалёнке в Bercut
стажёр инженер-тестировщик в Bercut
Меня зовут Андрей. Мне 23 года. Я студент-магистр в Политехническом университете и сегодня я расскажу, как строится мой день.
Онбординг
Моя первая в жизни работа началась летом этого года, во время пандемии, а значит, сразу удаленно.
Начну с первых дней в компании. Меня как новичка больше всего волновал коммуникативный момент – как знакомиться с людьми, процессами, задачами, не выходя из дома?
Оказалось, это возможно. Команда классная, много открытых людей, готовых помочь, а главное – профессионалов. Уже в первые дни все опасения по поводу удаленки были рассеяны.
Я прошел курс адаптации, который провёл меня от позиционирования компании и её продуктов до основ телекома. Прикольно, что в этот момент в Bercut как раз запустили программу адаптации через платформу дистанционного обучения.
Я читал внутренние документы и wiki для стажёров, делал небольшие учебные проекты. Даже на этом этапе, как любой другой новичок, я сталкивался с множеством различных проблем, когда ничего не работало и не получалось. Но постепенно появлялось понимание, а сложные ситуации стали вытекать в фиксации багов, правок wiki и заведение CR-ов (Change Request, заявка на внесение изменений).
Рабочий день
Спустя пару месяцев я освоился, и теперь можно посмотреть на то, как проходит мой обычный рабочий день. Я просыпаюсь в 9 часов, привожу себя в порядок и иду завтракать. За чашкой кофе, как и любой другой современный человек, я проверяю мессенджеры. Затем смотрю программы про путешествия, сейчас, к сожалению, можно только смотреть.
В 10 часов пора работать! Можно начинать и позже, но мне приятнее вместе со всеми. Первые рабочие часы начинаются с разбора тасков в JIRA.
Я тестирую микросервис, который отвечает за планировку периодических и отложенных заданий в распределенном приложении. Это высоконагруженный сервис, к которому предъявляются высокие требования по времени отклика и пропускной способности, поэтому каждое изменение в коде оценивается на код-ревью, в том числе, с точки зрения эффективности и соблюдения потокобезопасности.
Я смотрю заведенные баги и правки, оцениваю их приоритеты и, конечно, советуюсь с наставником, чтобы выбрать наиболее актуальную задачу. Далее начинаю вникать в суть, пытаюсь воспроизвести ошибку, уточняю информацию и смотрю исходный код.
Ближе к обеду наступает пора летучки. В это время мы созваниваемся командой, делимся своими планами, задаем вопросы и обсуждаем проблемы. А после этого можно пойти на перерыв.
Мой перерыв, как правило состоит из обеда, а иногда – и небольшой тренировки. Перерыв помогает освежиться, и это особенно полезно, когда «замылены глаза» и я не понимаю, как исправить какой-нибудь баг.
После перерыва возвращаюсь на рабочее место с новыми силами. Все сомнительные и неоднозначные ситуации обсуждаю с наставником или с инициатором заявки – созвоны, созвоны. В результате я глубже погружаюсь в проблему и специфику её решения.
Когда задача решена, я пытаюсь понять, а можно ли как-то сделать лучше? Как правило, можно! Значит, начинается пора рефакторинга. Мы всегда пытаемся оптимизировать код, даже если я исправил в нём несколько строк и вижу, что можно весь метод написать лучше, то беру и пишу. Рефакторинг может длиться час, а может растянуться и до конца рабочего дня. Он заканчивается отправкой на код-ревью, после которого я узнаю, что именно можно было сделать еще лучше, о различных тонкостях и об аспектах, о которых я не догадывался.
Около 18-19 часов рабочий день подходит к концу. 2-3 раза в неделю конец рабочего дня переходит в университетские лекции и практики, а когда их нет, то сразу же после работы я готовлюсь к ним. Бывает, что занятия проходят в течение рабочего дня, и на них приходится прерываться, корректируя рабочий график.
Можно сказать, что работа и учёба в моём случае дополняют друг друга, а удалёнка дала возможность без потерь совмещать одно с другим. Но минусы также есть, и я очень хочу лично встретиться с коллегами в офисе, познакомиться и пообщаться.
Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.
Перейти к регистрации
Я работаю тестировщиком и зарабатываю около 150 000 ₽
Профессия: тестировщик
В трудовом договоре написано «Старший специалист по тестированию», но в миру мы известны как QA-инженеры или попросту тестировщики.
Доход: 150 000 Р на руки
Выбор профессии
Насколько мне известно, нет такой профессии в вузах — «тестировщик», потому что эта работа не требует специфических навыков. Хорошая соображалка и элементарная компьютерная грамотность — любой человек с этими навыками может стать начинающим тестировщиком.
По образованию я бакалавр направления «Прикладная информатика в экономике» и моя карьера начиналась в 1С-франчайзи. 1С я изучала самостоятельно и на краткосрочных курсах, в вузах этому не учат.
На старте карьеры я работала не в Москве, а в другом городе-миллионнике, и в 2016 году я получала около 25 000 рублей.
Однако, жизнь сложилась так, что я переехала в Москву, устроилась также в компанию 1С на зарплату 55 000 рублей, но долго не продержалась. Сыграли разные факторы: мне не нравилась предметная сфера, не устраивала политика 1С в области сертификации специалистов и вообще узкая направленность этой сферы. Также при устройстве у меня была серая зарплата, а в 2017 году ее срочно полностью «обелили», потому что компания рисковала нарваться на штрафы. После этого зарплата стала 50 000 рублей (конец 2017 года) и я решила искать новую работу.
Я хотела остаться с ИТ, но программировать на популярных языках, например Python или Java, не умела, да и учиться особенно не было желания. Тогда по совету знакомого разработчика решила попробовать себя в качестве тестировщика.
Я почитала книги, в том числе легендарного Савина «Тестирование дот ком», посмотрела кое-какие видео на ютубе, почитала блоги, немного потренировалась писать запросы SQL (тут меня спасло то, что внутренний язык запросов 1С — это как SQL, только на русском, было просто). С этим багажом и вышла на рынок.
Около месяца я ходила по собеседованиям, получила много отказов, потому что мало компаний в конце 2017 года были готовы брать нулевых сотрудников. Это сейчас для тестеров есть стажировки в условном Сбербанке, только приходите, тогда ничего подобного не было. В итоге мне прислали оффер из телеком-компании на 65 000 рублей. Это и стало моим первым местом работы в качестве тестировщика.
Суть профессии
Профессия тестировщика подойдет тем, кто хочет работать в ИТ, но не готов погружаться в тонкости разработки. Хотя знание любого языка программирования не помешает, ведь многие ручные операции можно и нужно автоматизировать, не отвлекая разработчиков от их работы. Не повредят общие технические знания: как работают сети, что такое HTTP-протокол, какая бывает архитектура приложений. Хорошо, когда у тестировщика есть знания по предметной сфере и понимание бизнес-процессов: это поможет воссоздать портрет потенциального пользователя и более тщательно провести тестирование.
Тестирование — не творческая работа. Тут важнее внимательность, усидчивость, гибкий ум и коммуникабельность. Зачастую именно тестировщику приходится играть роль «телефончика» между разработкой, бизнесом и специалистами из смежных систем. Молчуны-интроверты часто не справляются.
Работая тестировщиком, я часто вспоминаю цитату из «Дивного нового мира» Хаксли: «Как хорошо, что я бета… У альф работа гораздо трудней, чем у нас, потому что альфы страшно умные. Прямо чудесно, что я бета, что у нас работа легче». Под альфами, конечно, понимаются программисты:)
Мне нравится быть частью ИТ-сферы, зарабатывать деньги, сидя за компьютером — это моя мечта со школы. С одной стороны, эта работа довольно простая, для ручного тестирования не надо быть гением. С другой, можно углубиться в автоматизацию и баловаться кодингом: писать автотесты, утилиты для генерации тестовых данных или других рутинных операций. Но при этом нет такой ответственности, как у разработчика. Если тестировщик напишет некачественный код, то выстрелит в ногу себе, а не пользователю продукта.
Самое трудное в работе — работа в условиях недостатка документации и тушение пожаров на проде. К сожалению, даже лучшие тестировщики пропускают баги, которые влияют на пользователей, и каждый такой инцидент — стресс.
Место работы
Сейчас я работаю в банке, который все знают, не хочу конкретизировать. В крупных банках условия плюс-минус одинаковые.
Мне нравится отношение компании к сотрудникам. У нас белая зарплата, регулярные премии, ДМС со стоматологией, скидки на фитнес, уютный офис недалеко от метро. Не могу сказать ничего про корпоративы, так как устроилась после начала пандемии, но говорят, раньше они были:)
Есть возможность удаленной работы, нет трекинга рабочего времени, самый главный показатель — выполнение задач в рамках дедлайна.
Основной минус, который я сейчас вижу, — это отсутствие серьезного роста по зарплате, но это общая проблема в ИТ, как мне кажется. Хочешь хорошую прибавку — либо шантажируй оффером (и не факт, что это хорошо закончится), либо уходи в другое место. Других минусов назвать не могу.
Рабочий день
Я работаю на удаленке, и мой рабочий день начинается в промежутке с 9 до 10 часов. Мы работаем по скраму (а кто по нему сейчас не работает), и в 11 часов у нас daily scrum meeting, а по-русски — ежедневная летучка. Обсуждаем, кто что сделал вчера, чем будет заниматься сегодня и какие есть проблемы. После этого каждый расходится по своим делам.
В мои обязанности входит регрессионное тестирование перед релизом — убедиться, что новые функции не поломали то, что работало раньше. Время на регресс ограничено, не более 1-2 дней в неделю, все остальное время надо посвящать тестированию новых задач.
Тестирование проходит в несколько этапов. Я могу начинать, когда готова техническая документация, по которой разработчик пишет код. Я же в это время пишу тестовую документацию: чек-листы и тест-кейсы. Чек-листы позволяют проводить проверки быстрее, зато тест-кейсы облегчают работу новичкам, в них по шагам описано, какие кнопки надо нажимать и что в итоге должно получиться.
Когда разработчик закончил свою работу, он переводит задачу на меня, и я исполняю свои тесты. Каждый тест я отмечаю: если все хорошо, то «пройден» (passed), а если нашлась ошибка — тест «завален» (failed). Я составляю баг — отчет о дефекте, где описываю шаги воспроизведения (что я делала), ожидаемый результат (он основан на технической документации) и фактический результат (что происходит на самом деле). Баг — это любая ситуация, когда ожидаемый и фактический результат не совпадают. Например, пользователь вводит неверный пароль, а программа все равно разрешает вход, — это баг.
Проверка небольшой задачи занимает примерно день, и как только накопится пачка багов, разработчик их исправляет и отдает мне новую сборку программы. Я снова прохожу свои тесты, иногда после починки багов вылезают новые неприятности. В итоге цикл «кодинг — проверка» осуществляется до тех пор, пока все не будет работать как надо. Разработчик закрывает задачу, и мы переключаемся на следующую.
Еще одна из наших задач — автоматизация тестов. Ручной труд долгий и утомительный, поэтому чем больше тестов автоматизировано, тем лучше. Но в автоматизации есть свои сложности, иногда тесты ломаются, показывают ложные падения или ложный успешный результат. Наша задача — писать новые устойчивые тесты, актуализировать старые и поддерживать всю систему автотестов в жизнеспособном состоянии.
И конечно же, скрам не мыслим без «церемоний» — это встречи команды для обсуждения задач. Мы работаем двухнедельными спринтами. В начале недели мы планируем, что должны сделать за этот спринт, в середине недели 1-2 раза собираемся на «груминг» — обсуждение будущих задач, а в конце недели проводим демо и ретро. Демо — это демонстрация бизнесу того, что мы у спели сделать, а ретро — обсуждение процессов и выявление способов работать еще лучше.
Удивительный случай
Здесь могла быть изумительная байка про джуна-тестировщика, который случайно стёр все данные с продакшена, но к счастью, у нас такого не случалось:)
На собеседованиях часто просят рассказать про самый интересный баг, который я находила, но у меня нет таких историй. Все баги обычные: то верстка поехала, то при нажатии «Сохранить» документ удаляется.
Подработки
Мне хватает основной работы, поэтому искать подработки я не пыталась. В отличие от разработчика, который может работать один, тестировщик не самодостаточен, поэтому найти работу на фрилансе не так-то просто.
Есть сервисы по краудтестингу, но это больше развлечение для стажеров. Денег там не заработать (это как биржи копирайтинга с расценками 10 рублей за 1000 збп).
Доход
Сейчас я получаю около 150 000 рублей на руки. Это в рамках рынка, хотя с моей квалификацией можно найти зарплату и повыше. Но пока что я морально не готова поднимать якорь.
Чтобы зарабатывать больше, говорят, надо устроиться в другой всем известный банк, а я туда не хочу:)
Расходы
Я живу одна и полностью себя обеспечиваю. В среднем регулярные траты такие:
Сколько получится — в подушку безопасности. Сейчас у меня накоплена сумма, которая позволяет спать спокойно, поэтому пополнение подушки идет по остаточному принципу.
Траты по остальным категориям зависят от сезона, необходимости и средств в наличии. Так, например, в сентябре я потратила рекордные 27 000 на одежду и 21 000 на обустройство рабочего места. Иногда приходится оплатить какое-то обучение (к сожалению, компания не готова спонсировать развитие сотрудников), несколько раз в год я езжу в родной город, сейчас много трат, связанных с подготовкой к грядущему новому году, а летом идут траты на отпуск.
Экономия
Особых лайфхаков по экономии у меня нет. Еду покупаю во Вкусвилле, одежду в массмаркете, шкаф стараюсь не захламлять.
Конечно, я могла бы отказаться от многих необязательных трат, например, тренироваться без тренера, пилить ногти дома, не ходить к косметологу, скачивать фильмы с торрентов вместо походов в кино, не ходить в театры и на концерты, есть только дома, передвигаться только на метро, и ходить в одной и той же одежде, пока она не поползет по швам. Но смысл? За деньги не купишь счастья, но можно купить маленькие радости, которые делают жизнь лучше.
Финансовая цель
К пенсии хочу свою квартиру, но пока не знаю, где. Может, в Москве, а может и нет. Поэтому пока что не тороплюсь влезать в ипотеку, чтобы купить одну квартиру по цене двух, а инвестирую.
Будущее
В ближайшее время я не хочу уходить из профессии, но возможно сменю место работы. Я устала от банка, хочется чего-то менее хардкорного и более спокойного. Но пока что у меня есть цель и я ее не реализовала, и я не сдвинусь с места, пока ее не выполню.
По хард-скиллам мне надо подтянуть автоматизацию. Многие вещи я делаю интуитивно, а хочется опираться на best practice. Меня не привлекает должность лида тестирования, поэтому свою ценность на рынке я собираюсь повышать именно путем совершенствования хард-скиллов и решения сложных технических задач.
Что касается более далекой перспективы, я вижу себя в роли тестировщика лет до 55-60. Я трудоголик и собираюсь работать до последнего, не хочу просиживать старость дома (даже если он будет на берегу Тихого океана), как это сейчас делают мои бабушки (нет, они не на берегу, они в хрущевках города-миллионника). Я буду энергичной бабулей, которая поднимает штангу в качалке и путешествует по миру (надеюсь, к тому времени ковидные ограничения снимут).
Сейчас я вижу, как набирает обороты онлайн-образование, и ютьюб часто предлагает мне освоить профессию тестировщика:) Может, лет через 20 я стану методистом в условном Скилл Боксе, а может скрам-мастером (если к тому времени аджайл не умрет). В общем, после 50 надо будет начинать думать про переквалификацию в менее техническую должность, потому что мозги будут уже не торт.
Профессии. Читатели делятся профессиональным опытом.