Ученик Артёма, автора и преподавателя нашего курса, начал путь в тестировании полтора года назад, после того как он ушёл из продаж в b2b сегменте. Он почувствовал, что достиг потолка в своей работе, и сначала открыл свой бизнес, но это не принесло ему удовлетворения. После он решил попробовать себя в IT и прошел курс по тестированию. К концу курса ученик получил предложение о работе. На проекте, куда он попал сразу после окончания курса, ему пришлось работать без готовой документации. Проект был стартапом без реальных пользователей и релизов, и многие процессы были не отлажены.
Он поделился с нами своей историей перехода в тестирование, а также рассказал об особенностях и сложностях работы. За это время на проекте он уже помог бизнесу сэкономить деньги, внедрив новый инструмент.
— Как ты пришел в тестирование? — Я пришёл в IT полтора года назад, чуть раньше с учётом обучения. До этого 10 лет занимался продажами в b2b сегменте. Общался с компаниями на уровне руководителей. Достиг определённого потолка, и стало скучно. Попутно я открыл небольшой бизнес — точку с фастфудом. И всё равно оставалось ощущение, что я занимаюсь чем-то не тем. Это было захватывающе с интеллектуальной точки зрения. Но повторялись одни и те же процессы, и поэтому стало скучно. Так получилось, что у меня есть друзья из IT-сферы, причём на разных позициях: от разработки до менеджеров, но мне всегда казалось, что я сделан из какого-то другого теста, что для меня это сложно. Я не знал, с какой стороны подойти.
И видимо, настал тот момент, когда я решил себе сделать небольшое испытание, попробовать всё-таки вкатиться. Начал с бесплатных курсов на YouTube. В какой-то момент понял, что нужно систематизировать знания, потому что так можно бесконечно что-то слушать и читать, но так и не понимать момент, когда ты уже готов выходить на рынок. Поэтому интуитивно я выбрал курс и познакомился с Артёмом.
К окончанию курса Артём предложил мне работу в Quality League. Курс давался мне легко, думаю, как большинство и других курсов для человека, который настроен. И мне казалось, что мне не хватает знаний, было такое сомнение: «А точно ли этого хватит, чтобы получить оффер?». Но сразу скажу: то, что даёт Артём, 100% хватит.
Выйдя на работу как выпускник вчерашних курсов, я встречал людей, у которых опыт был больше, но их скиллы были меньше уровнем, чем мои. Поэтому не переживайте. Всегда есть такое ощущение, что ты ещё не готов и нужно что-то ещё изучить. Но чем раньше начнёшь работать, тем быстрее пойдёт твой прогресс.
То, о чём я сегодня буду рассказывать, это не какие-то золотые правила, это просто реальные истории из проектов. Что-то может пригодится, что-то, наоборот, можно сказать, что бывает так, но лучше сделать по-другому. Я попал на проект сразу на приёмочное тестирование.
И вот я прихожу. Условно вчера ещё учился, и мне говорят: «Вот нужно сделать приёмочное тестирование по такой-то части продукта. И ты будешь один». В команде тестирования был еще тимлид. Но он сам глубоко не касался этой части продукта.
Первый совет, который я дам сегодня, это не паниковать, потому что у меня было такое ощущение, что я один брошен у моря и мне срочно нужно во всём разобраться.
— Расскажи про проект. — Это проект, который связан со сбором данных с открытых источников для проверки потенциальных контрагентов. Проект под NDA, поэтому особо глубоко рассказать его не могу. Такими продуктами пользуются банки для оценки кредитоспособности человека, HR, сотрудники службы безопасности. Такие продукты уже есть на рынке, и они достаточно востребованы.
Команда условно у нас разделена на фронт и бэк. Так получилось, что я пришел, когда было уже готово 70% продукта и была задача сделать новый фронт. Я как раз попал на разработку и внедрение нового фронта. Несмотря на то что я относился больше к команде фронта, бэк всё равно приходилось тестировать. А так у нас было примерно две одинаковые команды. В команде 6–7 разработчиков фронта, аналитик, 1–2 тестировщика, один дизайнер на проект. И то же самое со стороны бэка. Сейчас получается как раз таки стадия, когда мы объединяем две команды и синхронизируем коммуникацию. Так как могло произойти такое, что я мог не контактировать со стороной бэка по несколько месяцев.
— Расскажи про первое впечатление: вот ты пришёл на проект, тебя поставили на приёмочное тестирование. Как это выглядело, какие это сложности вызвало? — Основная сложность была в отсутствии документации. Наш проект я бы больше отнёс к стартапу. У нас до сих пор нет реальных пользователей и не было каких-то настоящих релизов. Многие процессы были не отлажены, что-то успели сделать, что-то не успели. Получается, что я пришёл и рос вместе с проектом. Если появлялись вопросы, то оказывалось, что на них нет ещё ответа. Мы находили ответы и дополняли документацию.
Когда я пришёл, с документацией было совсем сложно. Тот функционал, который мне нужно было протестировать, был достаточно сложным, потому что он показывал связи между различными компаниями, лицами и так далее. Всё это выводилось в граф, где это всё связывалось различными линиями.
Во-первых, нужно было понять, как это работает внутри, чего ожидать, потому что макеты были неполные, документация была неполная. Это приводило к тому, что сами субподрядчики не всегда всё делали так, как хотелось заказчику. В какие-то моменты они опирались на свои личные ощущения.
Во-вторых, это приводило к тому, что на этапе тестирования я не знал, на что мне опереться. Я мог какой-то личный свой опыт применить, и в целом это приводило к большому количеству коммуникаций. То есть сначала мне нужно было обсудить, как это это видит подрядчик, почему они именно так сделали. Разговаривал с нашей стороной, со стороной заказчика, как это видит тот же аналитик. И пытался всё это свести вместе. Часто было просто непонимание между двумя сторонами, я выступал условно как посредник, который всё это сводил к единому видению, и финальный результат мы получали в процессе доработок.
Второй момент, который я подсвечу: отсутствие понятной документации приводит к большим затратам. В конце концов, финансовым. Потому что это тратит время на разработку, а каждый разработчик получает зарплату. Соответственно, лучше потратить время на составление документации и отдать её тестировщику. На этапе тестирования документации можно выявить многие недостатки в постановке задач. И это бы сэкономило деньги. Раннее тестирование и тестирование документации — очень полезная штука не только в теории.
— Расскажи с точки зрения заказчика. У них же тоже были тестировщики. Допускали они какие-нибудь баги? — Конкретно в этой ситуации был один тестировщик. Он тестировал и вел такой документ, в котором он описывал функционал, который протестировал, и результат, который он получил. Но я до конца так и не понял, то ли это был разработчик, который в том числе и тестировал. То ли это был не очень опытный тестировщик. У него мы находили очень много багов, не только связанных с непониманием требований, но и просто от банальных опечаток до неработающей логики.
— Вот ты находил баги. Как ты их заводил и как ты их передавал? — Мы пользовались YouTrack. Была отдельно доска для этой части продукта. И на эту доску я заводил все баги. Разработчики субподрядчика забирали в работу, и баг проходил обычный цикл: он создан, он закрыт, и часто возвращался на доработку, пока мы пытались понять, что конкретно нужно.
— Какие инструменты ты применял? — Вначале я опирался только на имеющуюся документацию и макеты. Я по макетам сравнивал визуальное отражение того, как на фронте должно выглядеть, по документации я проверял логику. При использовании тестовых данных смотрел наш ожидаемый результат, сравнивал с тем, что был, и на основании этого мы двигались дальше.
Когда я уже полностью перешёл в команду тестирования на этом проекте и стал тестировать не только ту часть, которую я принимал в самом начале, а весь фронт, я заметил, что тех инструментов, которые были в команде тестирования, их не хватает. То есть я пришёл, ребята провели для меня онбординг. Показали, чем они пользуются. В основном это был Postman для тестирования бэка, PgAdmin для проверки базы. В Kibana ребята смотрели логи.
Но так как я тестировал фронт, я не так часто пользовался базой и логами. Я воспринимал бэк к некую практически готовую вещь. Для меня всё-таки было важно, чтобы фронт правильно отрисовывал, то что ему передает бэк. Прежде чем мы приступили к полноценному тестированию фронта, разработчики и тестировщики, чтобы проверить расположение определённых значений в таблице и разделах на интерфейсе, использовали реальные запросы через парсинг к внешним источникам. Так они собирали информацию о потенциальных контрагентах. Все эти действия были платными и руководство предупреждало нас о том, чтобы мы не увлекались, поскольку расходы могли оказаться значительными в рамках нашего проекта.
Проект был уже год, и всё это время утекали деньги. Каждый запрос стоит денег, а таких запросов в день десятки. И я подумал, что это не совсем правильно. Для того чтобы мне найти нужные данные, приходилось идти к аналитику и спрашивать, по какому ИНН я могу посмотреть банкротство, было оно или нет, и как это отобразится. Это занимало время и деньги, поэтому я решил попробовать Charles. Это оказалось суперзолотым подспорьем, потому что через Charles я смог поменять ответы бэка таким образом, чтобы видеть те данные, которые я хочу. Хочу я посмотреть банкротство, я открываю через Charles JSON, который мне присылает бэк, и нахожу ключ для нужного мне значения.
Когда я хотел рассказать ребятам, я спросил у них, пользовались ли они Charles. Оказывается, что нет, им было достаточно тех запросов. Может быть, мой опыт предпринимательства позволил мне посмотреть шире и помочь бизнесу сэкономить деньги.
На сегодняшний я пользуюсь Postman, Charles, DevTools, Figma. Также мы задумались, где хранить тест-кейсы, при мне мы подключили Allure TestOps и уже начали нормально заводить тест-кейсы. До этого мы просто ввели чек-листы.
— Много у вас тест-кейсов и чек-листов? Какое соотношение? — Чек-листы у нас совсем отпали, у нас изменилась команда. Решили сразу писать кейсы. Сейчас до начала регресса мы решили заполнить основными кейсами Allure TestOps. У нас получилось 2200 кейсов. Мы потратили месяц на их создание. В процессе мы понимаем, что не все кейсы описаны. Мы стараемся докидывать, уточнять какие-то сценарии, которые были упущены. Из-за отсутствия нормальной документации иногда бывает такое, что ты сам не понимаешь, как это должно работать. Потому что, допустим, два года назад это было описано в какой-то задаче, и всё уже забыли.
— У вас длинные релизные циклы? — Да, у нас длинные релизные циклы, я не могу сказать, что это полноценный релиз, потому что нет конечных пользователей. У нас процесс выстроен следующим образом: аналитик, проджект, разработчик собираются и отбирают определённое количество задач на две недели. Они определяют время на все эти задачи, чтобы уложиться в цикл. На тестирование закладывается 30% от задач автоматически. Разработчики берут из todo свои задачи, делают их, задачи потом попадают на тест, часть мы закрываем, часть мы переоткрываем. К концу цикла бывает такое, что не все задачи успеваем реализовать, и стараемся делать ретро, чтобы понимать, почему неправильно оценили и как сделать так, чтобы задачи не переходили из спринта в спринт.
— Будут ли у вас автотесты? — Нас судьба к этому подводит. Когда я проходил курсы, было непонятно, как ручной тестировщик может пойти к автоматизатору и попросить его что-то автоматизировать. Я думал, как понять, что это можно автоматизировать. Это приходит с опытом. Ты уже понимаешь, что у тебя отнимает много времени и что очень легко автоматизировать.
Чтобы это лучше понимать, я сам начал погружаться в автотесты. Я не ставлю перед собой задачу стать автотестером. Но для меня это как Charles в свое время. Я для себя вижу два пути: либо я сам начну писать понемногу, так как у нас нет автотестера и когда он придёт, непонятно.
Сейчас есть классные вещи, такие как Playwright, который пишет за тебя код. Возможно, связка каких-то понятных инструментов для тестирования UI, плюс, может быть, где-то нейросети, и всё это можно и способ для того, чтобы писать стабильное и понятный тесты, которые сейчас уже могут упростить мне жизнь.
— Какие у тебя были ожидания от тестирования? Были какие-то моменты, которые тебе должны были понравиться, и что-то, что могло не оправдать твоих ожиданий. Как сейчас изменилось твоё восприятие и что тебе нравится? — В целом могу сказать, что мои ожидания примерно равны тому, что я получил, потому что я очень долго думал по поводу тестирования. Очень много общался с ребятами, со своими знакомыми и видел не только историю про большие зарплаты и удалённую работу. Видел разные стороны, поэтому мои ожидания в общем-то примерно совпали с реальностью. Понятно, есть моменты, которые тебе не очень нравятся, какая-то нудятина, например регресс или написание кейсов. Конечно, интереснее получить сложную задачу, посидеть покопаться, чем идти и в 100 таблицах проверять названия.
Я могу сравнить с предыдущими опытами работами, мне нравится то, что тебя слышат и стараются улучшить то, что тормозит тебя и команду. Это не просто отписки «не лезь не в свое дело». Из последнего могу привести пример. Ко мне в команду попали 2 джуна. И у них много вопросов, и когда начался регресс, я понял, что я не вывожу. Они требуют много внимания. Я просто написал проджекту, что хочу сдвинуть график на 2 часа, и без проблем сдвинули.
Также могут возникнуть проблемы с разработчиками, зовете 3 сторону, обсуждаете проблему, выясняете, в чем проблема, и вы решаете ее и двигаетесь дальше. Все объединены общей целью, и все препятствия быстро решаются. Это мне понравилось больше всего. Конфликты, конечно, назревают иногда, но такого открытого я не видел. Могу привести пример: пришел к нам новый разработчик, и приходит мне от него задача, и она описана очень размыто. Ее ставил аналитик, написано привести такой-то раздел в соответствии с макетом. Там не просто картинки. Там заложена определенная логика. Он реализовал частично: визуально соответствует, но не все кнопки работают. Я ему пишу, что не все работает. Он мне пишет в личку: «Откуда я мог знать, что нужно это сделать, это в задаче не написано, ты хочешь сделать из моей задачи свалку, будешь постоянно туда накидывать вещи, которые я не могу знать, что за дела?»
Я постарался в позитивной форме ему ответить, что у нас документация неполная и неточная, поэтому тут вопрос к человеку, который ее ставит. Так как задач много, их не успевают описать. Если ты не согласен, ты просто мне пишешь, и мы найдем общее решение.
Навыки общения здесь 100% пригодятся. Здесь много общения с разработчиками. Ты можешь научиться любым инструментам, но вот это либо у тебя есть, либо это надо выработать, иначе будет тяжело.
— Расскажи, как у вас с точки зрения апгрейда. Есть ли у вас Performance Review, пересмотр ЗП, как это происходит? Можно прийти и сказать «Хочу больше денег?». — Мне самому это интересно, как это должно быть. У нас всегда это спонтанно получалось. Самое главное, я вижу, что заказчик заинтересован. Первый раз это было, когда я полноценно переходил из аутсорсинга туда, мы обсудили условия и все приняли. А второй раз, когда у нас ушел один из сильных тестировщиков и у нас команда уменьшилась, а задачи нет. Они решили перестраховаться и сами пришли с предложением о поднятии зарплаты, неплохой был буст.
— Какой был буст по процентам? — 15-17 процентов. В целом не надо бояться подходить, ты чувствуешь ценность для компании и понимаешь, что ты этого стоишь на рынке. Иногда менеджеры могут этого не заметить, и нет ничего плохого прийти и подсветить даже в цифрах.
— Какое напутствие дашь ученикам? — Я уверен, что тот, кто не бросит поиски работы, тот 100% устроится. У меня маленький опыт в собеседованиях, но я успел увидеть разные стороны. Я видел ребят, которые по каким-то причинам лучше справляются с задачами, кому-то это дается сложнее, кто-то быстрее схватывает, кто-то медленнее, но побеждает тот, кто не сдается.
Я решил обучить свою жену, она не математик, не программист, такой же гуманитарий, как и я, и недавно она получила свой первый оффер. Это как минимум второй человек, который пришел из другой сферы и не видел в себе склонностей к IT-сфере. Я видел людей, которые делают по 300 откликов и потом точно так же находят работы, просто они делают больше работы, когда выходят на рынок. И я не знаю ни одного человека, который захотел, но у него не получилось. Тех, кто устроился и не прошел испыталку, таких знаю, или тех, кто сделал много откликов и их не взяли, таких знаю. Но тех, кто 2 раза не прошел испыталку, таких не знаю.
Хочу сказать, что если вас не сразу зовут, вы не проходите скрининги и технические, даже испыталку, это вообще ничего не значит, рынок огромный. Поэтому не переживайте, если не дали оффер в этом месте, значит, дадут в другом. Как только вы зацепились, вы остались на проекте, здесь уже всё только от вас зависит. Прикладывайте свои усилия, учитесь, старайтесь смотреть шире, потому что по себе знаю, что всё быстро развивается и вчерашних знаний уже может не хватать. У вас есть безграничный набор знаний в интернете, дополнительные курсы, нейросети. И вы сто процентов останетесь в обойме.
Это очень крутая сфера, в целом я ни дня не жалею, что я сюда пришел, тем более я работаю на удаленке. Мне нравится экономить свое время на передвижении от офиса и обратно. И когда я вечером выхожу прогуляться и вижу эту очередь машин в пробках в попытках добраться до дома, я думаю, как круто, что я работаю на удаленке и мне не приходится этого делать. У всех всё получится. Всем желаю получить оффер с первого раза, а если не получится, не сдавайтесь!