«Всегда есть страх, что упустила баг»: как я стала тестировщицей

Я долго вынашивала идею перейти на удаленный формат работы.

Для меня удаленка — это прежде всего не тратить время на дорогу до офиса и деньги на дресс-код. Кроме того, я хронически опаздываю. Вдохновляет, что можно работать из кафе, любуясь красивым видом.

Когда я пошла учиться на юриста, была уверена, что буду работать по профессии. В 2015 году, окончив бакалавриат, поступила на заочное отделение магистратуры. Я была гражданкой Казахстана, целью моего пребывания в стране была учеба, и по закону я могла официально работать только в пределах вуза. Поэтому моя карьера началась с работы лаборантом на своей кафедре. Затем заместитель директора по учебной работе забрала меня к себе на должность секретаря. А к моменту защиты магистерской диссертации я уже работала в отделе образовательной политики и решила остаться там до получения российского паспорта.

Сейчас я занимаю должность специалиста учебной части. В мои обязанности входит разработка и проверка электронных макетов учебных планов всех направлений и специальностей, календарных графиков учебного процесса, расписания занятий; расчет нагрузки преподавателей на год; внесение данных в Федеральный реестр документов об образовании, ФРДО, заполнение статистических отчетов и другое.

Особой выгоды от продвижения по карьерной лестнице в сфере образования не вижу. Надо мной — начальник отдела, еще выше — заместители директора. Между должностями специалиста и начальника отдела разница в доходе не очень большая, а в уровне ответственности — колоссальная. Мне не особо важна статусность, скорее хочется интересных проектов и задач.

Моя зарплата сейчас — около 40 000 ₽. Чтобы в рамках этой системы кардинально ее повысить, нужно менять образовательное учреждение, например переезжать в Москву, где другой порядок и цен, и зарплат. Либо менять вектор деятельности — уходить в науку или преподавание, но мне это неинтересно. А к переезду в более холодный климат я не готова, очень люблю Сочи и море. Поэтому нужно было искать третий вариант.

Изначально я хотела перейти в графический дизайн, потом решила попробовать себя в моушен-дизайне, находила бесплатные курсы. Пыталась свою любовь к рисованию превратить во что-то более серьезное, но на практике оказалось, что лучше пусть хобби остается хобби, иначе пропадает весь запал.

Тогда я стала ходить на пробные занятия на разных известных онлайн-платформах. И мне понравился урок из курса по тестированию. Появился жгучий интерес копнуть глубже. Я в принципе люблю учиться, а тут сама себе поставила планку освоить нечто совершенно новое. В итоге выбрала формат профессиональной переподготовки, так как по окончании программы получаешь диплом государственного образца, внесенный в ФРДО, тебе присваивается конкретная квалификация с указанием количества часов обучения.

Обучение началось 27 октября и стоило около 80 тысяч рублей. Можно было оформить рассрочку на 36 месяцев, но была бы переплата. Поэтому решила расчехлить подушку безопасности. Первый проект — по основам тестирования — я сдавала в январе. Второй — по тестированию Application Programming Interface, API, — в апреле. Дипломный проект сдавала в июне. И уже в июле получила диплом.

Программа дала мне очень много, абсолютно не жалею о своем решении. Нравилось, что лекции были в записи, так как это давало возможность конспектировать их в своем темпе. Еще нас собирали онлайн в «Зуме» на воркшопы, и параллельно мы работали в небольших командах на платформе Miro. Каждую среду открывался новый урок, и к нему давалось домашнее задание с дедлайном. В случае просрочки приходил куратор и спрашивал, нужна ли помощь. Это дисциплинировало, ведь при удаленном формате обучения велик соблазн все забросить. Если оставались вопросы, всегда можно было задать их кураторам, и на онлайн-встречах тоже обсуждали разные сложные моменты.

Училась я в основном в выходные. Иногда брала отгулы на работе, чтобы вовремя закончить курсовые и дипломный проект.

Через три месяца после начала обучения я сдавала свой первый курсовой проект. Очень волновалась. Нужно было протестировать программный продукт, используя все полученные на этом этапе знания: какие уровни тестирования бывают, как оформляется отчет о дефекте — баг-репорт, как выглядит тест-дизайн, как составляются чек-листы и так далее. Тестировала новую фичу под названием «Личные события» на вкладке «Расписание» в личном кабинете учителя на сайте курсов английского языка. Ее придумали, чтобы педагог мог, сверяясь с учебным планом, вносить в расписание другие свои дела.

Проект состоял из нескольких этапов.

Первый и самый важный этап — тест-план проекта, который постепенно дополняется в процессе тестирования. В нашем случае это был файл doc, в котором было прописано, как должны выглядеть эти личные события, как они будут добавляться, редактироваться, удаляться.

На этом этапе мы внимательно знакомимся с требованиями к проекту, они же «спецификация» или «спека», и задаем уточняющие вопросы, если что-то непонятно или есть противоречия. Иногда к проекту прикладывается макет — рисунок, где указано, как расположены ссылки, каким шрифтом они выполнены, как выглядят кнопки: их цвет, размер, названия и так далее. Но в описании под макетом название или цвет кнопки могут быть другие. Или, скажем, на макете у кнопки с выпадающим списком нарисованы три позиции выбора, а в тексте спецификации указаны четыре. Если на реальном сайте в выпадающем списке будет три позиции — это баг или нет? Тестировщику нужно знать, на что опираться во время проверки.

Чтобы выполнить качественное тестирование, нужно знать, на каком окружении оно должно проводиться. То есть в каком браузере, если у нас веб-приложение, например в Google Chrome, Firefox, Mozilla, «Яндексе», или на какой операционной системе, если приложение десктопное, — Windows, Mac, Linux. Это важно, потому что на разных ОС и в разных браузерах поведение программы может различаться.

Сюда же входит и декомпозиция программного продукта — интеллект-карта, где мы раскладываем каждую кнопочку, каждую ссылку, каждую картинку на отдельные единицы. Это нужно для более полного покрытия тестами. Так мы наглядно можем увидеть всю композицию, проследить все переходы от одной страницы к другой, если мы говорим о вебе.

На проект отводилось две недели, и можно было отправить работу на предварительную проверку наставнику еще на первом этапе, чтобы в самом начале определить, есть ли какие-то сложности и непонимание.

Второй этап — составление тестовой документации. Когда мы определились, что, когда, зачем и на каком окружении тестируем, можно готовить чек-листы проверок. С помощью чек-листа, который покрывает все функциональные требования, мы проверяем, как реализованы функции программы или системы, как она работает и соответствует ли ее поведение нашей тестовой документации.

Третий этап — это, собственно, само тестирование. На этом этапе мы проводим проверки, опираясь на подготовленную ранее документацию, и ищем баги в системе. Когда обнаруживаем баг, заводим на него специальный отчет — баг-репорт. В нем мы описываем шаги, по которым любой специалист, задействованный в проекте, сможет воспроизвести ошибку, будет знать фактический результат и ожидаемое поведение системы. Моя задача — обнаружить дефект и задокументировать его, завести в баг-трекинговую систему. А уже разработчик будет этот баг править, то есть вносить изменения в код.

Эти дефекты видит не только разработчик, но и бизнес-аналитик, иногда заказчик. Когда баг исправлен, статус внутри отчета меняется на «Поправлено». Тестировщик идет и снова проверяет. Если все в порядке, баг «закрывается».

Сайты, приложения и любой иной программный продукт — это определенная часть бизнес-процесса. И от качества этого продукта будет зависеть и впечатление пользователей, и уровень оборота товаров. Например, любые сбои в системе интернет-магазина могут оставить владельца бизнеса без прибыли, а пользователи, которые не смогли совершить покупку из-за бага на сайте, будут разочарованы и вряд ли придут еще раз. Моя задача как тестировщицы таких ситуаций не допускать.

Например, все мы знаем такие поля для ввода, как логин и пароль. Предположим, к паролю есть требование — не менее трех и не более восьми символов и только латинские буквы. Тестировщик сперва проверит, примет ли форма данные, подходящие под условия. Потом выяснит, как будет вести себя система, если ввести больше восьми символов. А если меньше трех? А если ввести кириллицу? А если ничего не вводить? А что насчет иероглифов? А что будет, если я скопирую пароль из текстового документа? Если пароль не будет соответствовать требованиям, а система его примет — поздравляю, вы нашли баг!

И второе — пользователю должно быть комфортно. Тестировщик проверяет, насколько удобный интерфейс, есть ли опечатки, соответствует ли дизайн программного продукта его макету. Он также может вносить предложения по улучшению какой-либо части продукта.

Тестировщик — как прораб на стройке. Прежде чем сдать дом, то есть отправить программу в релиз, проводится сверка с планом дома, то есть технической документацией, проверки как в части визуала, так и в части функциональности. Если находим недочет, то есть баг, — отправляем на доработку. Хозяин может сказать, мол, зачем мне прораб, я сам сейчас все посмотрю. Но если не знать нюансов, можно очень круто ошибиться.

Четвертый этап — отчет о тестировании. На этом этапе нужно было принять решение о готовности раздела «Личные события», написать развернутый и аргументированный ответ, можно ли выпускать продукт в релиз, приложив статистику по найденным дефектам.

Всегда есть страх, что упустила баг, какая-то фича на самом деле не работает, а ты взяла и разрешила пользоваться продуктом. Но эти решения не принимаются интуитивно. Все дефекты имеют определенную степень критичности. И мы опираемся даже не столько на количество найденных дефектов, сколько на их критичность. Условно пять критичных багов перекрывают десять некритичных — минорных. Критичные баги, к которым относится все, что связано с деньгами и оплатой, — например, списывается больше, чем стоит товар, или, наоборот, меньше, — нужно исправлять немедленно, а некритичными, например опечатками, которые не влияют на работу системы в целом, но все равно могут оставить неприятный осадок у пользователя, займутся в последнюю очередь.

Еще через три месяца обучения я сдавала второй проект — по API-тестированию. API — это набор определенных правил, при помощи которых программы «общаются» друг с другом. Мы сталкиваемся с ними каждый день — оплачивая товары на сайте, просматривая прогноз погоды, используя агрегатор поиска билетов и так далее. Это такой незримый гонец, который носит информацию от одного приложения к другому, минуя прямое взаимодействие с пользователем. То есть он отправляет запрос на сервер, а потом возвращает его клиенту уже в виде какого-то результата. Происходит это, допустим, после нажатия кнопки на сайте. Кнопка — запрос. То, что происходит после нажатия, — ответ. За внешним фасадом сайта есть еще изнанка с такими вот запросами и ответами, которые приходят с разными статус-кодами. Пользователь, как правило, ничего не знает об этой внутренней кухне, а видит только изменения на сайте.

В первом проекте «под капот» сайта мы не заглядывали и вообще не знали, что так можно. Второй же проект касался все той же функциональности, но теперь с учетом знаний об API. Например, мы вносили изменения в календарь преподавателя не с помощью кнопок на сайте, а от противного: писали запрос в Postman и смотрели, как он отображается на сайте и какой пришел в ответ статус-код.

Дипломный проект включал все, что мы ранее изучили. В нем тестировали раздел «Видеопрактика». Предполагалось, что учитель и ученик могут созвониться во время урока по видеосвязи и в общем диалоговом окне делать задания, писать или рисовать заметки, делиться файлами. Нужно было протестировать, как происходит эта интеграция и что отображается на экранах у обоих участников.

Еще нужно было проверить, как происходит взаимодействие компьютера, если на нем работает учитель, с телефоном, который, например, использует ученик. Я была и за учителя, и за ученика: сама себе звонила и отслеживала, что происходит на экране компьютера и как это отображается на телефоне.

При мобильном тестировании приходится учитывать больше факторов: положение и поворот устройства, его заряд, скорость интернета, то, как поведет себя система, если во время урока на телефон поступит звонок, придет смс, внезапно прозвонит будильник или сработает напоминалка, если включен GPS и так далее. Очень много вводных данных, поэтому мобильное тестирование обычно занимает больше времени.

После получения диплома открывается доступ в карьерный центр. Сначала ты смотришь видеоуроки, в которых опытный эйчар рассказывает, как правильно составить резюме, подготовить самопрезентацию и на какие вопросы желательно заранее отрепетировать ответы. И реально эти вопросы один в один задавались на собеседованиях.

Советы действительно были полезными. Когда у эйчара тысячи одинаковых резюме, первое, за что цепляется взгляд, это заголовок. Нам рекомендовали писать не просто «Тестировщик», а, например, «QA Engineer, ручное тестирование, REST API, Dev tools, Postman, английский язык» — так рекрутер уже по заголовку поймет, какими инструментами вы владеете. Еще обязательно нужно подробно расписать свои достижения на прошлой работе.

Расскажу, как выглядит портфолио тестировщика. Мы просто прописываем в резюме проекты, в которых работали, и, если работодатель захочет посмотреть тестовую документацию, присылаем ее в виде файла. «Лицо» тестировщика — это тестовая документация. Другое дело, что на разных проектах она может отличаться. Но профессионал все равно увидит, как ты ведешь документацию, какие проверки применяешь.

Далее ты делаешь домашние задания по каждому видеоуроку и отправляешь свои резюме, самопрезентацию и запись ответов на проверку. Эйчар все это разбирает и дает советы. Очень полезная вещь.

Наступает этап прохождения собеседований, и надо быть готовым к тому, что отказы — это нормально. Тут как в песне: «Мы выбираем, нас выбирают…» Для хорошей конверсии рекомендуется откликаться примерно на десять вакансий в день.

Еще можно заносить в гугл-док, сколько раз ты откликнулся и сколько собеседований прошел. И если у тебя слишком много отказов, кураторы свяжутся с тобой и будут выяснять, что ты говоришь, а что нет — или говоришь неправильно. Правда, я не воспользовалась этой опцией: вести гугл-док у меня не было времени. Я откликалась сама и, наоборот, тщательно выбирала вакансии. Искала в основном на «Хедхантере» и в телеграм-каналах с подборками вакансий в ИТ.

Рынок вакансий в ИТ однозначно шире, чем в юриспруденции и сфере образования: мне приходили ежедневные уведомления о двух тысячах новых вакансий. Подход к работе более современный. Например, на первом месте, куда меня позвали на собеседование, была не удаленка, но в офисе кормили завтраками, предлагали ходить в тапочках, а вечерами заказывали для сотрудников пиццу. Я уже готова была даже переехать в Краснодар, но не прошла по конкурсу.

Потом я откликнулась на вакансию в моем городе, но в итоге отказалась сама, потому что у них не было команды тестирования. В крупных компаниях это обычно целые подразделения, над ними есть начальство. А тут предполагалось, что ты один за все отвечаешь на проекте. Плюс они много работали с зарубежными компаниями — в общем, я побоялась туда выходить.

В вакансиях часто требуется знание автоматического тестирования. Это в основном JavaScript, который я не изучала. Понимаю, что придется все равно в это влезать для повышения квалификации, но для юниора на начальном этапе достаточно пока и тех знаний, что у меня есть. Опять-таки, это нормально, что каким-то требованиям я пока не соответствую.

Третья вакансия, на которую я претендовала, была с предварительным обучением. Меня это устраивало, я никуда не спешила. Это российская аутсорсинговая компания, большинство сотрудников которой — тестировщики, работающие удаленно. Месяц я уже отучилась, осталось еще два месяца неоплачиваемой стажировки.

Неожиданной проблемой стало то, что многие иностранные трекинговые системы, например Slack, Jira, разные мессенджеры, ушли с российского рынка. Теперь все это заменяет «Яндекс», а училась-то я совсем на другом:

• баг-репорты мы заводили в баг-трекинговой системе Jira;
• чек-листы проверок — в Sitechko;
• декомпозиция проводилась в Miro;
• тестовую документацию формировали и хранили в Confluence;
• отчет о тестировании со ссылками на тестируемый программный продукт, чек-листы проверок и баг-трекинговую систему — также в Confluence.

Моя компания работает только на российском рынке и только на российских продуктах. У нас даже созвоны по «Яндекс-телемосту», а не в «Зуме». Для меня это было шоком, пришлось многое открывать для себя заново. И очень рада, что сначала попала на обучение, потому что, если бы меня сразу закинули на проект, я бы не справилась.

В случае успешного прохождения стажировки со мной заключат бессрочный трудовой договор. Зарплата на начальном этапе составит 50 000 ₽. В начале проекта я писала, что планирую увеличить доход на 30% и выше. По итогу получается на 20%, ну и фактически этот доход я буду получать уже в феврале 2023 года. Можно ли считать цель достигнутой?

Из образовательного учреждения я пока еще не уволилась, но уже предупредила начальницу, что буду переходить в ИТ. Сейчас пришлось взять месяц отпуска на старой работе, потому что с началом стажировки у меня как будто появился второй полный рабочий день: я приходила с одной работы и садилась за вторую, заканчивала за полночь. Все выходные тоже работала.

Какие-то вещи уже даются легко, но приходится работать над самодисциплиной. При работе в удаленном формате есть опасность отвлечься на домашние дела и телефон, потеряться во времени.

В новую профессию я уже вложила очень много усилий, потратила время — год и месяц, и даже есть какие-то успехи. Интерес не прошел, все время думаешь, а что дальше. Например, скоро нас будут учить взаимодействовать с заказчиками. А раз в полгода мы будем проходить спецификацию, после которой можно получить повышение.

Если у тебя опыт работы тестировщиком от двух-трех лет, ты уже мидл. Сениор управляет командой, имеет навыки автоматизированного тестирования, знает языки программирования и общается с разработчиками и бизнес-аналитиками на равных.

Тестировщик может без знания кода заглянуть в разработку и посмотреть, как все устроено, кто и что делает. Потом стать разработчиком, проджект- или продакт-менеджером, бизнес-аналитиком и так далее. Можно либо развиваться по линии тестирования, либо осваивать какую-то новую ИТ-профессию — спектр большой, вдруг еще что-то понравится. Я пока окончательно не выбрала траекторию.

На крайний случай у меня есть накопления, которых хватит примерно на три месяца безработного скитания.