Интервью с учеником: с Junior QA до тимлида за 1,5 года
До тестирования ученик Артема, автора и преподавателя курса, работал в торговле в своем небольшом магазинчике. Но желание работать удаленно заставило его посмотреть в сторону тестирования. Свой первый опыт работы он получил на англоязычном агрегаторе еще в середине курса. После обучения будучи джуном он попал на сложный проект, но уже через полтора года стал тимлидом.
Он поделился с нами своей историей роста и рассказал про проект: процессы, сложности и их решение, технологии. В конце интервью дал напутствия новичкам в сфере тестирования.
— Расскажи о себе: чем до этого занимался, как пришел в тестирование? — Сначала занимался торговлей, у нас был небольшой магазинчик с мамой по всяким товарам для клининга. В 2022-м году захотелось найти удалённую работу. Долго думал, изучал, чем можно заниматься. Поглядывал в сторону IT. Понял, что у меня по жизни как-то неплохо получалось локализовать проблемы. Что-то сломалось в компе, взял, попробовал по-другому подключить, какую-то одну деталь поменял, и всё заработало. Я подумал, что было бы неплохо с этого денег срубить. И так я узнал, что есть такая профессия, как тестировщик. Стал смотреть в эту сторону. Изучал, какие есть курсы. И вот как-то так вкатился.
На середине курса был перерыв в неделю поискать какие-то фриланс-проекты на всяких агрегаторах. Мне повезло, я был в Турции. Работал на проекте для фриланса UTest. Он из России недоступен. Только через VPN, но это запрещено. Мне повезло, что там были всякие проекты для Турции, видеохостинг и прочее. Мне удалось поработать в англоязычных командах и заработать свои первые 50 баксов.
— Расскажи как там начать работать? — Повторюсь, за VPN там наказывают, и в России это недоступно, проектов для России там нет. Но если вы за рубежом, можете попробовать.
Ты регистрируешься, вводишь, какие у тебя есть девайсы. Там есть общедоступные какие-то проекты, на которые ты можешь подаваться. Время от времени ты там висишь со своими заполненными данными, и если появляется проект, в котором нужны люди из той локации с теми девайсами, которые есть, тогда приходит инвайт либо запрос указать дополнительные данные. Получил инвайт, прочитал инструкцию, нашел тесты, чаще всего там какое-то исследовательское тестирование.
Платят за баги в зависимости от того, насколько они серьезные. Иногда бывают проекты, где нужно выполнить тест-кейс или test suite, где нужно проверить функционал, и тебе за это заплатят. Там есть своя академия, на которой ты можешь освежить свои знания. Даже если ты ничему не учился.
Там очень серьезные требования к написанию баг-репортов. Поэтому я прокачался в этом. Потому что если что-то не так, тебе это вернут.
— Ты сейчас берешь оттуда заказы? — Нет, сейчас я не беру оттуда заказы, но до того как я устроился на постоянный проект, когда у меня были только подработки, я там мониторил регулярно. Там не будет постоянных кучи проектов.
— Я взял тебя на проект к себе джуном. Расскажи про первые дни на проекте. — Вообще сначала, если помнишь, ты мне подгонял парочку одноразовых подработок, то есть там протестить UI и ещё что-то. И потом уже попал на постоянный проект.
Вкратце про проект: сложная система, много бэкенда, мало фронтенда, соотношение 80 к 20, всё завязано на БД и на бэкенде. Это омниканальная система менеджмента заказа называется по-умному, грубо говоря, продавец одежды продает свой товар на 10 маркетплейсах, на своем сайте и ещё где-то.
Ему это надо менеджить, следить за складами, доставкой и всем прочим. Это всё делать неудобно, мы это делаем удобно, собираем всё в одном месте, чтобы, если что, менеджеры спокойно могли условно сидеть в 1С и менеджить все заказы, следить, что где пришло клиентам.
Пришёл я на проект, была команда из четырёх тестеров. Очень всё было по-дружески, по-семейному, не возникло никаких проблем с онбордингом, все помогали. Мне были готовы подсказать что-то, потому что все понимали, что проект сложный.
— Что казалось тебе сложным первое время? Что, может быть, казалось непривычным? То, что было неожиданностью увидеть на реальном проекте с точки зрения технологий, подходов? — На курсе хорошо было приближено к реальной работе. В ходе обучения на курсе я использовал DevTools и Postman. Примерно так же я работал и над проектом. Никаких сложностей не возникло. Самая большая сложность на проекте была именно с инструментом, которым пользуются там. Но этому, естественно, тебя никто не научит на курсе, потому что это специфика проекта. Инструмент называется «Camunda» для управления бизнес-процессами. Когда вы сидите в интернет-магазине, закинули товар в корзину и не купили, вам приходит там пуш «Вы забыли купить» или вы купили товары и вам пришла SMS-ка об операции. Вот это всё делается на проекте с помощью этого инструмента. Там схемы о том, как движется заказ. В это было сразу вкатиться сложно. Я не понимал, что за что отвечает и где. Мне потребовалось месяца три, чтобы разобраться с этим.
— А команда у вас большая? — Не очень большая, порядка 40 человек. Поддержка, аналитики, разработчики, тестеры, менеджеры. У нас есть разделения по командам, но в целом все со всеми контактируют. Есть команды, которые отвечают за сам продукт, за улучшение. Есть команды, которые отвечают за какие-то проекты, за каких-то клиентов, потому что от клиентов тоже есть доработки. Ими тоже нужно заниматься. Так что есть продуктовая команда и проектная.
— А вот с точки зрения тестирования, может, что-то было сложным. Может, какие-то ситуации? — Я бы сказал, что самая сложная задача, это где написано в задаче или тебе говорят: «Ой, зайди в БД, там просто статус поменяй заказу». И БД огромная, несколько баз. Там микросервисная архитектура, для каждого микросервиса своя база данных. И помимо того, что штук 20 баз данных, и ещё в каждой 50–100 таблиц. И ты там: «Ага, мне там нужна таблица Order или Order details или Order_t». Не везде можно было найти логичную привязку какой-то сущности к заказу.
Я рад, что в инструменте, с помощью которого я работаю с базами данных, есть мощный интерфейс. Чаще всего мне не приходится писать запросы вручную. Можно нажать на столбец, и он отсортирует по столбцу, не нужно писать «order by». Это облегчило работу. Но в целом, чтобы разобраться, где и какие данные хранятся в базе данных, потребовалось немало времени. Мы даже потом записывали с сотрудниками техподдержки небольшой видео гайд об основных таблицах, которые нужно знать тестировщику, и что в них находится, и как с этим работать. Этого мне не хватало, когда я пришёл.
— То есть в документации с требованиями, я так понимаю, были какие-то пробелы? — Мы работаем по agile, и, как прикольно сказали на курсе, что agile — это легализованное разгильдяйство. Готовый продукт важнее, чем исчерпывающая документация. Ну, мы так и следуем в принципе. Документация пишется, и особенно в последнее время, когда мы изменили процессы. Стараемся ничего не упускать в документации. Это всё-таки стартап, и он разрастался достаточно быстро. Не всё покрыто документацией. И часто приходилось к кому-то идти стучаться, если что-то в Confluence не нашел.
— Как часто пишете тест-кейсы? На курсе с ребятами мы проходим техники тест-дизайна, мы это исследуем, покрываем pairvise и эндпоинтами. Но говорю, что на реальном проекте у них на это времени не будет. — Да, на реальном проекте у нас нет на это времени. Скажем так, изначально тест-кейсы писались. Потом у нас осталось по некоторым причинам 2 тестировщика. У нас не осталось времени на тест-кейсы, мы поняли, что важнее тестировать фичи, доносить их до клиентов, чем писать тест-кейсы, иначе мы не получим денег. Но со временем восстановили количество тестировщиков, поэтому сейчас у нас по регламенту не только написание тест-кейсов на каждую задачу, но и ревью тест-кейсов другими тестировщиками.
Это помогает, во-первых, большему количеству людей быть в курсе какого-то функционала. Потому что ты можешь какой-то функционал вообще не потрогать на проекте из-за того, что ты его не тестил. Если ты ревьюишь тест-кейсы, ты хотя бы будешь знать, что это, и будешь способен быстрее воспроизвести этот тест-кейс потом. Ну и да, обучение людей друг друга, обсуждение тест-кейсов очень помогает.
Скажу больше, у нас даже недавно выявилась проблема, что вот повторяющиеся баги на проде, и я недоумевал, потому что я не видела эти баги. Оказывается, что у нас есть какой-то пул задач, который тестирует техподдержка. Есть пул задач, который можно протестировать только на проде, и техподдержка никак не фиксировала, что она протестила и прочее. Тест-кейсы не писали, и, соответственно, в регрессе это не прогонялось, и фикс затирался, возникал этот баг. Соответственно, техподдержка теперь тоже пишет тест-кейсы на свои протестированные баги. Потом QA ревьюит эти тест-кейсы. Мы добавляем это в регресс, и так мы вот решили эту проблему.
— Раньше у вас была автоматизация, как сейчас у вас с этим, поддерживаете? — Я учил Java, чтобы поддерживать. Потихоньку этим занимаюсь, последнее время у меня не очень много времени на это, но это в зоне моих интересов. Я сейчас запускаю эти автотесты, стараюсь поддерживать этот репозиторий, фиксить какие-то возникшие баги. Но больше никто этим не занимается, это чисто на моем это энтузиазме.
— А регрессия у вас как по времени много занимает? — Так как мы работаем по agile, у нас двухнедельные спринты, регресс каждые две недели. Раньше регресс занимал два-три дня. Потом в какой-то момент я стал пользоваться автотестами в Postman. Выяснилось, что это значительно проще, чем писать автотесты с нуля, и этим могут заниматься люди, которые не сильно разбираются в языке программирования.
Я занялся автоматизацией регрессионного run в Postman. Я автоматизировал 85% мануального run, остались только UI-тесты. UI мы не автоматизировали, потому что его мало. Так что сейчас регресс у нас занимает в пределах одного дня, в зависимости от количества возникших багов. Если не считать возможных багов, то сейчас над проектом работают три человека. В течение длительного времени один из них был занят интеграционными тестами, поэтому в команде было только два человека. Даже работая в таком составе, мы старались завершить регресс за 4 часа. Автотесты в Postman очень сильно помогли.
— Как у вас обстоят дела с оценкой времени? — Да, мы оцениваем задачи. Долгое время у нас были такие встречи, как декомпозиция. Там были аналитики, разрабы и тестеры. Поднималась какая-то задача на декомпозицию, мы все в режиме онлайн читали и ставили оценку. Со временем мы переделали процессы, и теперь у нас апрувы разделены. Сейчас у нас нет созвонов. Декомпозиция у нас есть просто для сабтаски, сначала задачу смотрит аналитик, если задача получает апрув от аналитика, то переходит к QA, это то, что называется left shift testing. Сначала тестировщики тестируют документацию. Тестер смотрит, действительно ли бизнес-требования покрывают эту задачу, пишет чек-лист проверок. Ставит свой апрув, потом уже грумит разработчик. Соответственно, если на каком-то этапе апрув не получен, то возвращается назад и там доделывается.
Это помогло в оценке, потому что когда ты на созвоне онлайн всё это делаешь, то ты понимаешь, что на тебя какое-то давление, и ты не можешь спокойно прочитать задачу и определить, сколько тебе надо. Некоторые задачи очень сложные, и там только на ознакомление с функционалом у тебя уйдет час.
— Расскажи, как стать тимлидом. Как это получилось в твоем случае, как ты с нуля на одном проекте за полтора года развился? — Наверное, софт-скилы решают. Потому что тимлид — всё больше менеджерская позиция, и тебе нужно будет решать какие-то возникающие проблемы. Нужно развивать твой отдел, смотреть, как можно оптимизировать работу, контактировать больше с другими менеджерами, с большим количеством людей. Очень важно, чтобы ты был самостоятельный, ответственный. Чтобы никому не нужно было следить за тобой, это тебе придётся следить за людьми. Ты будешь нести ответственность за то, как они работают. Будут оценивать не твою работу, а работу твоего отдела.
С этим у меня всегда было неплохо, поэтому это помогло. Также мне помогло глубокое знание проекта, в какой-то момент я просто осознал, что я никаких вопросов не спрашиваю у людей по проекту, а если я спрашиваю, мне никто не может ответить. И получилось так, что предыдущий тимлид ушел с проекта. Я был самый опытный тестировщик, и мне предложили попробовать себя в роли тимлида, собственный предыдущий тимлид меня и посоветовал. Так и получилось, где-то немножко удачи, где-то немножко случая, где-то немножко серьезной работы, вместе это всё сошлось.
— И как поменялось твоя работа, есть ли какая-то разница? — Вообще поразительно поменялась, потому что много стало всякой менеджерской работы: распределение задач, следить за трекингом команды, подводить итоги месяца. Всё меньше времени уделяю на задачи, всё больше я делегирую. В основном я занимаюсь какими-то объемными задачами, которые не могу передать другому человеку. У нас один тестировщик Junior, он на проекте три месяца, другой тестер Middle, он около полугода. В идеале у нас сейчас придет еще один тестер, которого я собеседовал. Забавный факт: первый собес в моей жизни со стороны собеседующего, а не собеседуемого.
У меня в планах делегировать ручные задачи уже команде, а самому заниматься автоматизацией и менеджерскими делами, ну и по надобности подключаться на что-то сложное.
— Давай поговорим про собесы. Много собеседований вообще провёл, как вообще с наймом? — Провел я всего два собеседования, и так получилось, что одного из кандидатов мы захотели взять. Мы искали Middle, но собеседовал кандидата, который позиционировал себя как Junior. Видно было, что парень даже если в чем-то не разбирается, то он очень хочет работать и очень интересно мыслит. На вопросы, которые связаны с какой-то логикой, он ответил отлично. В итоге мы прособесили сначала парня Junior, а потом мы собесили парня, который шел на Middle, и он очень плохо ответил. В итоге мы захотели взять первого.
— Что не нравится на проекте, что хотел, чтобы было по-другому, что присматриваешь в новых проектах? — Присматриваю в новых проектах то, что связано со спецификой моих путешествий. Мне, к сожалению или к счастью, всё меньше толку от рублей, поэтому я ищу проекты за границей и с оплатой, соответственно, в валюте. Поэтому при всей моей привязанности к текущему проекту я не думаю, что я надолго там задержусь ещё.
На проекте мне не нравится система бюджетов. Каждый отдел функционирует как небольшая организация, то есть у отдела разработчиков свой бюджет, у отдела тестировщиков свой бюджет. И когда работаешь над какой-то таской, у неё есть бюджет, который привязан. То есть вот команды такого-то проекта такого-то клиента, им нужно разработать фичу, они «нанимают» разработчика и тестера. Чем больше времени потрачено на задачи с другим бюджетом, тем выгоднее это для отдела, тем больше вы заработали денег, тем больше могут быть премии.
— Какие бы ты дал напутствие ребятам? — Я бы посоветовала две книжки, которые я прочитал. Книга Романа Савина «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах». Там как раз расписано и про поиск работы, и про продвижение по работе. Книжка очень интересно написана, очень легко, шуточная, с примерами. Если вы не будете читать, там есть очень хороший совет про продвижение по работе — когда будете работать, записывайте всё хорошее, что вы сделали. Вот вы научили кого-то пользоваться таким-то инструментом — запишите. Вы помогли там аналитику с анализом задач — запишите.
Кто-то другой на вашей работе это делает, и он получит повышение, а если вы захотите повышение, а вы это не делали, у вас спросят: «А что вы хорошего сделали на проекте?» Вы будете думать, вспоминать. Мне очень сильно помог этот совет.
Что могу посоветовать прокачивать — soft скилы. Будьте общительным и уверенным, умейте убеждать — это пригодится как и в поиске работы, так и при работе. Потому что вам мало того что не нужно будет стесняться спрашивать что-то по работе, вам обязательно нужно будет спрашивать. Это ваша работа. Если что-то вы нашли неправильно, нужно будет не стесняться сказать об этом и настаивать.
Мы работаем для того, чтобы не давать делать неправильно, даже если люди будут хотеть сделать неправильно. Для этого нужно уметь изъясняться чётко, коротко и уметь доносить свою мысль. Поэтому я советую вторую книжку: «Пиши, сокращай». Отличная книжка про текст. Вы будете писать много текста: тест-кейсы, баг-репорты, и всегда нужно писать так, чтобы вас было легко понять любому человеку вне зависимости от его образования и технических скилов. Если вы пишете неграмотно, это будет неприятно читать. Книжки читайте, будьте проактивными, изучайте новое, новые инструменты, если хотите какое-то продвижение, потому что никто не придёт и не скажет: «Я хочу дать тебе кучу денег».
Будьте лучшим специалистом, приносите компании, требуйте с неё соответствующую оплату за это. Я не говорю перерабатывать, то есть переработки — это плохо. Либо они должны быть оплачены, либо их не должно быть. Вы обязаны работать 8 часов, не больше, не меньше. Отдыхайте, отдых важен. Но свое рабочее время распределяйте так, чтобы, когда вы свободны от задач, и, предположим, не прокрастинировать, а что-то поизучайте. Вам платят за эти часы, чтобы вы стали лучше. Так потратьте его на изучение каких-то инструментов.