Всем привет! Меня зовут Маша, я работаю QA-инженером в Doubletapp, и моя история в IT началась всего 1,5 года назад. Хочу поделиться своим опытом перехода в тестирование, рассказать о том, как я училась, с чего начинала, и что помогло мне сделать первый шаг. Надеюсь, этот рассказ вдохновит тех, кто только думает о профессии тестировщика.

В IT я пришла из фотографии. Раньше моя работа казалась идеальной: свободный график, творчество, интересные люди. Но вот стабильности совсем не было — это сезонная занятость. В тот год я ещё много путешествовала и без заказов осталась почти полностью. Тогда я и задумалась: а что, если попробовать себя в новой профессии? Хотелось найти что-то стабильное, с возможностью работать удалённо.

Я записалась на курс по выбору профессии в IT от Яндекс Практикума. Там мне особенно понравилось тестирование программного обеспечения. Решила двигаться в этом направлении и начала искать курсы для тестировщиков.

На YouTube оказалось много полезного контента по основам тестирования ПО. Я прошла бесплатный курс у Artsiom Rusau, посмотрела видео Леши Маршала. Ещё заглянула на каналы, где тестировщики рассказывают о работе в разных направлениях: ручное тестирование, автоматизация, gamedev и тестирование безопасности. Это помогло понять, куда можно развиваться.

Меня пугала мысль, что это техническая профессия, совсем не похожая на то, чем я занималась раньше. Но я решилась и записалась на 9-месячный курс по тестированию с нуля от Яндекс Практикума. Правда, закончить его не успела — на середине учёбы меня взяли на стажировку в Doubletapp и времени на прохождение практики на курсе не осталось, потому что я была Full-time загружена на стажировке.

Обзор полезных курсов

Artsiom Rusau. Этот курс понравился своей простотой и примерами. Артём объясняет теорию тестирования доступно, постоянно обновляет материалы. Он проводит стримы, отвечает на вопросы, показывает, как готовиться к собеседованиям.
Кроме бесплатных уроков, у Артёма есть платный курс. После каждой темы там есть тесты, которые помогают понять материал лучше. Это особенно полезно, если учитесь сами.

Лёша Маршал. У него тоже есть базовый курс по тестированию ПО, доступный бесплатно на YouTube. Лёша рассказывает, как проходит день тестировщика, даёт уроки по автоматизации.

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

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

Как найти работу

После курсов мне хотелось скорее выйти на работу. Я попробовала пройти собеседование на стажировку в Doubletapp. Там мне дали тестовое задание, с которым я справилась. Потом пригласили на собеседование, где спрашивали про теорию и проверяли soft skills.

Сейчас новичков без опыта берут реже, но есть шаги, которые могут помочь:

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

  • Практикуйтесь самостоятельно. Например, протестируйте сайт доставки пиццы. Опишите ошибки и отправьте отчёт команде сервиса. Возможно, они захотят пересмотреть штат своих QA и вы станете кандидатом на место тестировщика. 

  • Посещайте IT-конференции. Заводите знакомства, общайтесь. Если кто-то из вашего круга будет искать стажёра, он может вспомнить о вас.

  • Вместе с резюме отправьте сопроводительное письмо. Расскажите, почему хотите работать именно в этой компании, какие навыки хотите развивать, и упомяните, что готовы учиться. Такое письмо покажет вашу заинтересованность и выделит вас среди других кандидатов.

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

Семь вещей, которые я хотела бы знать на старте

1. Потратьте 15 минут на ресерч, прежде чем идти к наставнику

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

Старайтесь не отвлекать наставника и разработчиков по каждой мелочи. Вместо этого собирайте вопросы, чтобы обсудить их за раз — на созвоне или в переписке.

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

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

2. Учитесь и пробуйте новое

Тестирование — это динамичная сфера, где всё быстро меняется. Новые инструменты и подходы появляются постоянно. Не ограничивайтесь только тем, что выучили на курсах! Читайте статьи, смотрите вебинары, пробуйте новые инструменты и подходы. 

Вот небольшой список ресурсов, которые можно изучить:

Телеграм-канал ProTestingInfo
теория тестирования
тесты для закрепления знаний

Телеграм-канал Серьезный тестировщик

База знаний: QA_Bible
теория тестирования
практические задачи

Доклады: SQA Days

Форумы: software-testing.ru

Изучайте статьи на Habr, вот несколько примеров по теме тестирования:

3. Про внимательность: пишите сценарии и используйте схемы

Внимательность — основа работы тестировщика. Даже маленькая ошибка, вроде опечатки, может стать проблемой, особенно если она на главной странице сайта.

Нашли баг? Запишите его сразу. Потом обсудите с менеджером, насколько он критичен, и создайте баг-репорт.

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

Инструменты, которые могут помочь в этом:

  • MindMeister: поддерживает совместную работу в реальном времени, экспорт в различные форматы. Возможность работы в команде, шаблоны, мобильные приложения.

  • Miro: также есть возможность работы в команде, поддерживает создание майндмэпов, схем, диаграмм.

  • draw.io: совместная работа, удобно создавать блок-схемы, есть шаблоны 

Эти инструменты схожи по возможностям, но отличаются визуально, можно выбрать то, что вам больше понравится. 

Попробуйте разные варианты и выберите тот, что вам больше нравится.

4. Простая и понятная тестовая документация

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

Баг-репорт

Баг-репорт — это инструмент для документирования ошибок, найденных во время тестирования.

  • Заголовок должен быть емким и отвечать на вопросы: что? где? при каких обстоятельствах? 

  • В описании более подробно опишите дефект.

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

  • Фактический результат — то, как ПО работает сейчас.

  • Ожидаемый результат — то, как ПО должно работать по ТЗ.

  • Для наглядности прикрепите скриншот или скринкаст с демонстрацией проблемы.

  • Предусловие: если для воспроизведения бага необходимо предварительно совершить какие-то действия — опишите их. Например, если нужно залогиниться под определенным пользователем, можно оставить данные для авторизации.

  • При необходимости проставьте критичность бага.

Чек-лист

Это список кратко описанных проверок, но их тоже необходимо вести так, чтобы было понятно команде. 

  • Содержит данные о стенде и тестовом окружении.

  • Описание проверки и фактический результат

  • Если в рамках проверки был обнаружен баг, необходимо его обозначить, чтобы разработчик не пропустил, например, выделить жирным шрифтом и написать ожидаемый результат.

Тест-кейс 

Это пошаговое руководство для выполнения теста. Каждый шаг должен быть четким и понятным.

  • Емкое название, описывающее суть проверки.

  • Предусловия при необходимости.

  • Шаги проверки. 

  • Ожидаемый результат.

5. Планируйте время, чтобы избежать выгорания

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

Обсуждайте нагрузку с лидом

Регулярно обсуждайте свою загруженность с лидом QA или менеджером проекта. Это поможет избежать ситуации, когда задач становится слишком много или они требуют большего времени, чем ожидалось. Если видите, что работа накапливается, не стесняйтесь просить помощи или пересматривать приоритеты. Лид поможет распределить нагрузку так, чтобы вы справлялись с объемом и не перерабатывали.

Ранжируйте задачи по сложности

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

6. Не бойтесь ошибок

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

  • Ошибаться — нормально, важно воспринимать это как опыт и учиться на своих ошибках.

  • Обсуждайте ошибки с наставником, он подскажет, как избежать их повторения.

  • Не бойтесь задавать вопросы наставнику и команде на проекте.

  • Сфокусируйтесь на прогрессе, для этого можно ставить себе цели, по которым вы сможете отследить рост в профессии.

7. Общайтесь с командой

Умение донести информацию о проблемах до команды — важный навык для тестировщика. Вместо обвинений фокусируйтесь на решении проблемы.

  • Пишите баг-репорты нейтрально, без личных оценок.

  • В чатах не ищите виноватых — ошибки бывают у всех.

  • Если что-то вызывает конфликт, обсудите это с менеджером проекта.

Помните, что цель всех членов команды — качественный продукт, а не споры.

Заключение

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

Надеюсь, мои советы пригодятся вам на старте. Удачи в освоении новой профессии!

Комментарии (2)


  1. Emelian
    17.12.2024 14:57

    мне особенно понравилось тестирование программного обеспечения

    Я далек от тестирования, но тема, в принципе, интересная, поскольку, недавно опубликовал свой пет-проект ( https://habr.com/ru/articles/848836/ ) и, сейчас, самое время его протестировать. Естественно, делать это мне придется самому, поскольку проект абсолютно бесплатный.

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

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


  1. Sundark
    17.12.2024 14:57

    Но я решилась и записалась на 9-месячный курс по тестированию с нуля от Яндекс Практикума. Правда, закончить его не успела — на середине учёбы меня взяли на стажировку в Doubletapp и времени на прохождение практики на курсе не осталось, потому что я была Full-time загружена на стажировке.

    После курсов мне хотелось скорее выйти на работу. Я попробовала пройти собеседование на стажировку в Doubletapp.

    Хм... Что-то где-то не сходится. Так и тестируем