Привет! Меня зовут Люба, и я QA инженер команды разработки систем для контакт-центра в Lamoda.
Недавно исполнилось три года, как я работаю в нашей компании, и это заставило меня задуматься и заново посмотреть на события, которые происходили с момента, как я выбрала эту профессию, на решения, которые я принимала. На каком-то этапе своего карьерного пути я столкнулась с выгоранием, и была близка к тому, чтобы совсем уйти из профессии. Но не ушла, а наоборот продолжаю реализовывать себя в этой же сфере, причем работаю уже сравнительно долго на одном месте, и пока не собираюсь уходить.
Тестирование софта — та ли это профессия, которой я хочу заниматься?
По образованию я математик-программист, но еще в институте поняла, что становиться разработчиком я не хочу. Тестирование, наоборот, сразу показалось мне интересным, потому что требует самых разных навыков (и при этом остается возможность покодить).
За первые три года своей карьеры я поработала в двух компаниях, и в обеих занималась тестированием банковского ПО — и с благодарностью вспоминаю свои прошлые места работы и своих бывших коллег, которые помогли мне получить начальный опыт в профессии.
На первом месте я тестировала WEB-приложения на планшетах/мобильных устройствах (iOS, Android) и десктопные клиент-серверные приложения. Начала применять разные виды тестирования, и в копилке моего технического опыта появились новые навыки:
- все необходимое для работы в *nix системе научилась делать через командную строку;
- научилась делать запросы к СУБД Oracle;
- научилась создавать и настраивать свое тестовое окружение, используя в том числе VirtualBox;
- осознала важность логов и научилась с ними работать, а также настраивать их по уровням.
Затем я устроилась в аутсорс-компанию, предоставляющую услуги по тестированию и аналитике. Технического опыта эта работа прибавила мне мало: лишь знакомство с SoapUI, интеграционное тестирование, и на одном из проектов удалось еще более плотно заняться тестированием мобильных приложений.
Зато на некоторых проектах удалось попробовать себя в роли аналитика и тест-лида для небольшой команды тестировщиков. Я много общалась и с коллегами, и с заказчиками, что помогло мне развить софт скиллы.
В эти первые три года я поняла, что не ошиблась, тестирование действительно очень разнообразно, и работа в этой области мне по душе. Но чем больше появлялось опыта, тем сильнее меня начинали демотивировать некоторые моменты, которые вначале казались вполне приемлемыми. В основном это были особенности организации рабочих процессов, принятые в компании — что-то, на что я не могла повлиять. Я старалась справляться с дискомфортом, вкладывая свои внутренние ресурсы, ведь работа мне нравилась. Но в какой-то момент это перестало получаться.
Выгорание
Шел миллениал по опен спейсу, видит — работа горит. Сел за нее и выгорел.
К концу третьего года работы я перегорела настолько, что на три месяца ушла просто “в никуда”. Отдыхая и восстанавливаясь, я пыталась понять, что именно привело меня в такое состояние. Самыми критичными моментами для меня оказались:
- Не налаженные процессы: формально использовались гибкие методологии (скрам/канбан), но они не были подстроены под особенности работы конкретной компании.
- Не было ощущения команды и коллектива: при возникновении проблем все пытались найти одного виновного, не понимая, что работа над задачей на самом деле велась командой. Со многими разработчиками мне пришлось пройти долгий путь налаживания коммуникации, чтобы они осознали мою роль как QA-инженера в нашей общей работе, и начали нормально общаться при решении задач.
- Не принято было делиться знаниями с коллегами, часто было сложно получить информацию, нужную для решения задачи.
- Я получала очень мало аргументированного фидбека о своей работе для осознания, что уже делаю хорошо, а к чему можно стремиться, чтобы расти.
- Технических навыков за три года я получила все же очень мало. А обещанную во всех местах работы автоматизацию так и не удалось попробовать.
- Также в последний период работы не было много куда доступа из-за банковской безопасности — код, БД, логи.
- Но самая боль — это то, что некоторые работы шли «в стол» и я не видела результата того, что я делаю, не ощущала, как это влияет на бизнес и работу других людей.
Все эти неприятные вещи, если подумать, не связаны непосредственно с профессией тестировщика ПО. Но в тот момент мне было, конечно, сложно отделить одно от другого. И когда после перерыва у меня снова появилось желание отправиться на поиски работы, я задумалась о том, чтобы сменить специальность на смежную. Например, уйти в аналитику, или попробовать продолжить в роли QA Lead.
Но при этом я понимала, что мне невероятно нравится техническая составляющая именно моей профессии. И тогда осознала, что хочу продолжать развиваться как QA инженер. Что аналитика, вероятно, наскучит мне без технических моментов, а в роли QA Lead постепенно потеряю технические навыки. А по моим ощущениям в ближайшем будущем на рынке труда все же будут больше востребованы сильные технические специалисты.
Поиск нового места работы
На этот раз я выходила на рынок труда уже как достаточно опытный специалист. Я определила для себя список требований, по которым оценивала предложения работодателей. Конечно, мне хотелось, чтобы на новом месте работы отсутствовали те самые минусы, которые стали причиной моего выгорания. Отдельно я выделила еще несколько критериев:
- предмет тестирования больше не должен быть связан с банковским ПО;
- в компании не должно быть бюрократии;
- а самое главное — для удовлетворения от работы я должна видеть результаты своих трудов и получать обратную связь от пользователей и своих коллег.
Начался долгий поиск. Меня не очень радовали полученные предложения — было похоже, что большая часть минусов предыдущих мест будет и здесь.
И вдруг я вспомнила, что год назад засматривалась на вакансию QA инженера в Lamoda. На собеседовании меня зацепило то, что предполагалось много заниматься техническими задачами, использовать новые для меня инструменты и тестировать большую и сложную систему. И что нормальная коммуникация является одной из ценностей компании.
А что, так можно было?
Первое непривычное, с чем я столкнулась на новом месте, было то, что здесь вся работа ведется командной.
Проявляется это в налаженных процессах в виде адаптированного скрама — синхронные 2-х недельные итерации в каждой команде, в течение которых проходят разные встречи (митинги, груминг, оценка задач, обсуждение проектов). Моя рабочая нагрузка планируется с учетом того, что я буду посещать все эти встречи. В результате я всегда в курсе всех новостей по проектам.
Здоровые рабочие отношения
Еще лично мне очень нравится, что нет как такового отдела тестировщиков во главе с руководителем. Когда существует двойное подчинение – тимлид разработчиков и руководитель отдела тестирования – то порой возникает конфликт интересов и борьба за ресурсы под определенные задачи.
В Lamoda QA инженер — часть команды определенной системы.
И получается, что я в подчинении у тимлида своей команды, который в курсе моей текущей и предстоящей работы, и это помогает нам эффективно проводить 1-to-1 встречи. На них мы обсуждаем мою работу, наболевшее, и тимлид старается помогать со всем необходимым, а также определяет дальнейшие возможные векторы развития. То есть я получаю ту самую обратную связь от коллег через тимлида — то, чего мне очень не хватало раньше.
А еще я начала чувствовать себя абсолютно нормально, когда мне нужно обратиться за помощью к разработчику или аналитику, или даже к другим командам. Никто не выставляет тебя глупцом, если чего-то не знаешь, а наоборот делятся знаниями, и приветствуют такой подход.
Автономность в работе
Особенно важным для меня стало наличие доступов везде, где нужно. И я могу самостоятельно настраивать свое тестовое окружение как мне нужно, лазить в БД и в логи, а еще видеть код приложения в целом и все изменения в нем по пул реквестам задач.
Например, когда беру в работу задачу, то я вижу, что именно было изменено в коде. На этом этапе уже могу заметить дефекты. Если понимаю, что нужно проверить обмены с другой системой, то могу сама развернуть любую другую систему у себя на тестовом стенде — поднять для нее БД, контейнеры с нужной версией, накатить миграции. И мне не нужно просить это сделать кого-то из коллег.
Культура обмена знаниями
С самого начала моего работы в Lamoda меня невероятно радует открытость к шерингу знаниями, принятая в коллективе. Это очень упрощает многие рабочие моменты. Но обмен знаниями работает по-настоящему эффективно, когда является общей для всей компании ценностью, когда сформировалась уже целая культура, и каждый сотрудник является ее частью (о том, как именно этого добились в Lamoda, мой коллега недавно писал в статье). Я оценила все плюсы этой культуры на себе, и с удовольствием сама теперь ее поддерживаю.
Был момент, когда состав тестировщиков сильно изменился, и новые ребята не знали, как поднимать и настраивать стенды некоторых общих систем и как с ними в целом работать. На меня посыпалось много повторяющихся вопросов, и я приняла решение организовать пару встреч, на которых рассказала ребятам об этих системах и ответила на все их накопившиеся вопросы. После встречи стало понятно, какие именно заметки следует оставить в наследство, чтобы в дальнейшем история не повторялась, и я больше не тратила на это время.
И вообще пришло такое банальное осознание, что вместо написания заумных документаций (которые все равно пишутся очень редко и медленно) можно просто делиться знаниями в доступных для всех заметках, причем максимально простым языком. После работы в банковской сфере мне это было непривычно, и я сознательно отучала себя от добавления излишней терминологии и “воды”.
Оставляя такие заметки, в первую очередь я забочусь о себе будущей. Которая спустя время подзабудет, как что-то проверяла в прошлый раз, и тут мои записи из прошлого как раз пригодятся.
А со временем у меня появилось осознание, что можно и нужно делиться знаниями не только внутри компании, но и вовне — на различных конференциях и митапах. Например, как-то я выступала с докладом об интеграционном тестировании. Ну или статью вот можно написать =)
Глубокое погружение в системы и бизнес-процессы
В нашей компании действительно большой IT-блок, уже более 340 инженеров, и постоянно я работаю только с какой-то одной его частью. Но, благодаря интеграционным тестированиям, я знакомлюсь с системами, которые поддерживают и развивают другие команды, и даже поучаствовала в их тестировании в моменты, когда у тех команд была сложность с ресурсами на это. И это снова то самое разнообразие, которое я люблю в своей работе.
Еще мне очень важно, что я могу заглянуть внутрь всех процессов, которые выстроены в системе. Например, есть возможность понаблюдать за работой операторов колл-центра. Что для меня, как тестировщика колл-центра, оказалось очень полезным — мне удалось лучше понять бизнес-логику некоторых кейсов, а также увидеть слабые места в приложении и рассказать о них команде, чтобы сделать доработки в ближайшее время.
Я попала на интервал работы оператора, когда ему поступали много звонков от клиентов с просьбой о продлении срока хранения заказа на ПВЗ (пункт выдачи заказов). Оператор пояснил мне, что каждый день около 17:00 идет рассылка sms клиентам с оповещением о том, что заканчивается период хранения заказа на ПВЗ. После получения этой sms клиенты, конечно же, начинают массово звонить в колл-центр с просьбой продлить срок хранения, потому что не успевают забрать заказ. Конечно, такой кейс хочется автоматизировать, например, дать возможность клиенту в ответ на sms отправить нужный ему вариант – продлить хранение заказа еще на день или отказаться.
Участие в собеседованиях и возможность влиять на состав своей команды
В последние несколько месяцев я присоединилась к ребятам, которые проводят интервью для поиска новых QA инженеров в наши команды бэкенда. Это тоже оказалось очень полезным: я прокачала софт скилы и даже почерпнула от кандидатов новые технические штуки. Плюс было очень приятно помогать найти действительно классных специалистов своего дела, с такими же горящими глазами, как у меня, с которыми потом вместе работать в кайф.
Недавно у меня произошел переход из одной команды в другую, и мне хотелось оставить систему и все свои наработки в надежных руках. Поэтому для меня было особенно важно в этот момент, что я могу лично собеседовать новых кандидатов и выбрать лучшего из них.
Что, собственно, я тестировала все это время?
В начале я попала в команду системы Order Processing по хранению и обработке заказов (подробнее про эту систему коллега рассказывал в статье). В тот момент это был очень большой монолит, написанный на PHP, который общался с огромным количеством других систем. И, честно, поначалу тестировать его было сложно и больно. Никогда до того я не встречалась с подобными системами. На протяжении 3-4 месяцев тестирование каждой задачи начиналось практически с чистого листа – они все касались абсолютно разной функциональности, и требовали разных подходов к тестированию.
Но лично я поняла, что получаю удовольствие от таких сложных вызовов. Потому что, во-первых, не становится скучно, а во-вторых — много возможностей для развития технических навыков.
Ура, наконец-то автоматизация!
Здесь у меня наконец-то появилась возможность познакомиться с автоматизацией тестирования и заняться ею вплотную. У меня всегда был пунктик о том, что не хотелось бы забывать полученные навыки программирования.
И сейчас я занимаюсь автоматизацией тестирования на php+codeception — о том, как она устроена, мой коллега рассказывал в этой статье.
Вся команда работает над созданием интеграционных авто-тестов, стремясь к тому, чтобы в итоге тестировать руками приходилось лишь единожды при разработке новой функциональности. Регресс в моей системе уже покрыт автотестами, и это радует. Проходить одни и те же сценарии вручную из раза в раз — это, наверное, самая нелюбимая часть работы у многих тестировщиков. Гораздо приятнее проводить это время за развитием своих навыков и другими интересными занятиями.
Частые изменения — лишние сложности или возможность для развития?
Конечно, за эти три года у меня не всегда все было прекрасно.
Например, за последние несколько месяцев были изменения в команде, поддерживающей CI/CD. В этот период возникали проблемы с тестовым окружением, их решали долго, или они вовсе оставались без решения. Конечно, меня это расстраивало и делало мою работу менее приятной. Но в какой-то момент я поняла, что большое количество изменений, которые плохо поддаются предсказанию — неотъемлемая часть работы с любой действительно сложной системой. И во всем этом можно найти и плюсы. Мне удалось глубже понять свое тестовое окружение, некоторые проблемы я научилась исправлять самостоятельно.
Случалось, что контейнеры в докере после поднятия почти сразу же падали. И тут нужно было залезть в логи контейнера, понять, что именно пошло не так, и постараться локализовать своими силами или понять, кого из разработчиков можно привлечь для помощи. На тот момент этот способ был намного быстрее и эффективнее, чем ждать помощи от ребят из CI/CD.
Мой технический рост: конкретика
По сравнению с прошлыми местами работы я ощущаю, что здесь пока что профессионально расту “год за три”, настолько разными и насыщенными были мои задачи.
Какие навыки я получила за три года работы?
— Для настройки тестового окружения и деплоя веток с фичами использовала Jenkins, VirtualBox, командную строку и внутренние файлы системы с конфигами.
Затем был переезд стенда в docker, а сейчас уже и в k8s в облаке.
— Для билдов настроила джобы в Bamboo.
— Для написания автотестов на PHP+Codeception использую PHPStorm, и пул реквесты с ними создаю при помощи Git.
— Для тестов прикручены Allure отчеты.
— Для тестирования API – Postman, SoapUI, Swagger.
— Для запросов к БД SQL и Postgres – Sequel Pro и DBeaver.
— С логами работаю через Kibana, а также через консоль в файлах системы.
— Для асинхронных запросов использую RabbitMQ и Event-bus&Kafka.
— Для тестирования обменов файлами через FTP, SFTP, S3 использую Cyberduck.
— Вся работа с задачами и документацией ведется в Jira, Confluence.
— Научилась создавать и использовать заглушки в SoapUI и Wiremock.
— И так уж получилось, что именно здесь на разных проектах я узнала о тестировании обратной совместимости, проверке идемпотентности запросов и тестировании миграций.
Остановка в развитии: как удалось предотвратить повторное выгорание
Несмотря на такое вроде большое разнообразие в работе, спустя примерно 2 года я почувствовала, что снова остановилась в развитии. Задачи стали повторяющимися, мне попросту начало становиться скучно.
В итоге я открыто рассказала о своих мыслях и ощущениях своему тимлиду на встрече 1-to-1. Оказалось, что компания готова дать мне достаточно много возможностей для горизонтального развития. Спустя месяц мне предложили перейти в команду Callcenter с достаточно сильно отличающимся техническим стеком, в которой я и работаю сейчас.
Что мне дал этот переход?
С точки зрения самого объекта тестирования я опять-таки погрузилась в совершенно новую для себя область. Колл-центр — это про телефонию, там совсем другая архитектура всей системы, не похожая на все те, с которыми я работала ранее.
Сама система состоит из нескольких сервисов, которые исторически написаны на разных языках — там и PHP, и Go, и Scala, и JS Node.
Заметок и документации было очень мало, интеграционных автотестов не было.
По сути, я получила возможность выстроить с нуля тестирование для большой и сложной системы. Мы сами придумываем и налаживаем внутрикомандные процессы — как договоримся, так и будет. Так, мы решили с самого начала работать над автоматизацией тестирования, при помощи инструментов, удобных для нашей команды.
Так что проблема со скукой однозначно разрешилась, я чувствую, что совершаю сейчас огромный скачок в профессиональном развитии.
Что я чувствую сейчас?
Лично для меня удивительно, что огня в моих глазах не поубавилось за три года, проведенных в компании. Возможно, я и правда нашла то самое занятие и место в жизни, чего и всем желаю.
Здесь я не чувствую себя в изоляции. Мне постоянно доступна возможность развивать технику, тестировать разные системы, переходить в другие команды, а значит снова узнавать что-то новое и участвовать в разных общих событиях, что позволяет действительно почувствовать ценность и важность моего труда.
И как же в итоге справиться с выгоранием QA инженеру?
Нет универсального лекарства. Ведь причин, приводящих к выгоранию, может быть очень много. Но вот выводы, которые я сделала из своего опыта.
- Если тебе так же, как мне, важно в работе постоянно удовлетворять любопытство и прокачиваться технически, то ищи большие и сложные системы, с ними всегда интереснее.
- Не ограничивайся азами тестирования, развивайся вширь. Та же автоматизация — отличный инструмент для облегчения и оптимизации тестирования, а также возможность покодить, если ты скучаешь по этому занятию. Никогда не поздно знакомиться с новыми инструментами, участвовать в аналитике требований, придумывать оптимизацию процессов и просто делиться своими знаниями с другими. К тому же, быть универсальным специалистом модно и востребовано =)
- Не стоит пугаться происходящих изменений, хотя они и могут порой расстраивать. В конце концов все стабилизируется, а пока происходит какой-то треш, можно приобрести много нового хорошего опыта.
- Компании с современным и разнообразным технологическим стеком позволяют не протухать как специалисту, ведь приходится идти в ногу со временем, изучая все эти технологии.
Если ты чувствуешь усталость и раздражение, и думаешь, что тестирование больше не твое занятие — задумайся, может дело в условиях работы, а не в профессии как таковой. Вполне вероятно, что ты устал от того, что не налажены процессы, работа идет “в стол” и результаты труда не ощущаются, коммуникация в коллективе слишком сложная и отбирает много сил… Существует множество демотивирующих факторов.
Найти свое дело и свое место возможно: иногда нужно искать снаружи, иногда — договариваться внутри. Главное, четко понимать, что сейчас не так и как хотелось бы, и внятно доносить свои ожидания и хотелки.
Автор: Lyubov
