Home

Автор: Юлия Ковшова
Оригинальная публикация в блоге YADRO на Хабре

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

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

Мой путь в профессию начинался с СПбГУ. Специальность «Прикладная математика», 2013 год выпуска. В 2015 году я прошла курсы по тестированию и попала на стажировку, где начала заниматься автотестированием. 

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

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

Первая практика в тестировании

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

SauceDemo

SauceDemo — тестовый интернет-магазин. Чтобы начать работу, перейдите на сайт и воспользуйтесь одной из тестовых учетных записей. Самый популярный вариант: 

username: standard_user

password: secret_sauce 

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

Вот несколько направлений, в которых можно искать баги:

• Корректность отображения товаров, например фото, названия, цены.

• Использование разных аккаунтов и сравнение различий в поведении сайта.

• Анализ ошибок в консоли браузера через DevTools (F12).

• Попытка оформить заказ с пустой корзиной.

• Тестирование на разных браузерах (кроссбраузерность).

• Сохранение содержимого корзины после обновления страницы.

DemoQA

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

• Elements — базовые элементы интерфейса: чекбоксы, радиокнопки, таблицы, кнопки и др.

• Forms — формы для заполнения и проверки валидации данных.

• Alerts, Frame & Windows — работа с всплывающими окнами, фреймами и вкладками.

• Widgets — интерактивные элементы: слайдеры, календари, автозаполнение и т. п.

• Interactions — перетаскивание объектов, выбор из списков, изменение размеров и другие действия.

• Book Store Application — небольшое демо-приложение книжного магазина для комплексного тестирования.

Выберите интересующий раздел — и можете сразу начинать тестировать.

DemoQA отлично подходит для тренировки разных элементов:

• Формы: проверка обязательных и необязательных полей, валидации, поведения при вводе некорректных данных.

• Кнопки: тестирование различных событий (одинарный, двойной, правый клик).

• Алерты: проверка всплывающих окон и их обработки.

• Фреймы и окна: взаимодействие с вложенными фреймами и новыми вкладками.

• Виджеты: взаимодействие с выпадающими списками, календарями, ползунками и т. д.

• Интерактивность: тестирование drag-and-drop, выделения элементов, динамических изменений размеров.

• Работа с каталогом: проверка поиска, логина, добавления книг в избранное и других пользовательских действий.

OrangeHRM

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

Username: Admin

Password: admin123

После входа вы попадаете на главную панель. Убедись, что:

• отображаются виджеты (Leave, Time at Work, My Actions),

• работает боковое меню, 

• доступна информация о текущем пользователе (в правом верхнем углу).

Дальше перейдите в раздел PIM (Personnel Information Management), слева нажмите на вкладку PIM. Здесь можно: просматривать список сотрудников, добавлять нового сотрудника (кнопка Add), искать сотрудников по ID, имени, статусу и т. д.

Пример действий:

• Нажмите Add.

• Введите имя (например, «Test»), фамилию (например, «User»).

• Сохраните форму.

• Найдите этого сотрудника через поиск.

Можно проверить работу с пользователями:

• Перейдите в Admin → User Management → Users и убедитесь, что таблица пользователей загружается.

• Попробуйте использовать фильтры: User Role, Status, Employee Name.

• Нажмите Add, заполните форму нового пользователя, выберите роль и привяжите к существующему сотруднику.

Проверка Time (учет времени):

• Перейдите в Time → Timesheets.

• Попробуйте создать новый табель (Fill Timesheet) и введите часы, проекты, комментарии.

• Сохраните и отправьте на подтверждение.

Проверка логина/логаута и безопасности:

• Выйдите из системы через меню (иконка пользователя → Logout).

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

• Проверьте, появляется ли сообщение об ошибке.

Что можно дополнительно протестировать:

• Валидация форм (например, попытка сохранить сотрудника без обязательных полей).

• Корректность фильтров и поиска.

• Реакция на ввод невалидных данных.

• Отображение на мобильных устройствах (responsive дизайн).

• Проверка локализации (язык интерфейса).

• Проверка консоли и сетевых запросов через DevTools.

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

Такое «игровое» тестирование поможет на практике понять, кто такой QA-специалист. Это не просто человек, который «проставляет галочки» по чек-листу. Тестировщик — специалист, который ищет несоответствия между тем, как должно работать, и тем, как работает на самом деле.

На этом этапе не требуется глубоких знаний — достаточно большого интереса к тестированию. Параллельно я бы рекомендовала начать читать профильную литературу, например книгу Романа Савина «Тестирование dot com». Если вы только начинаете путь в тестировании, обратите внимание на YouTube-канал Лёши Маршала. Он простым языком разбирает основы профессии и дает практические советы для новичков.

Когда вы одновременно исследуете песочницу и изучаете теоретические материалы, мозг начинает работать в нужном направлении. Так можно научиться задавать себе важные вопросы: 

• Что будет, если нажать эту кнопку? 

• А если ввести невалидные данные, например буквы вместо цифр в поле «возраст» или эмодзи вместо имени? 

• А если обмануть систему и отправить запрос напрямую, минуя интерфейс?

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

Как понять, что пора двигаться дальше

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

Ориентир для начинающего практика может быть примерно такой:

• Нашли десяток багов.

• Поняли базовые техники: классы эквивалентности, граничные значения.

• Начали применять теорию на практике.

Если все это есть, то можно выходить из тренажерного зала на реальные соревнования. 

Опыт с open source-проектами: тестируем по-взрослому

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

Сначала кажется, что в open source пускают только профи, которые на «ты» с Git, умеют писать юнит-тесты и делают pull request'ы во сне. Но на самом деле там всегда не хватает людей, в том числе тестировщиков. Особенно таких, кто готов смотреть на продукт незамыленным взглядом пользователя.

Далее я приведу примеры популярных открытых веб-приложений, которые идеально подходят для отработки тестовых сценариев и практики.

WordPress

WordPress — система управления сайтами. Начать стоит с развертывания WordPress у себя локально. Проще всего это сделать с помощью LocalWP — это приложение, которое за пару кликов установит локальный сайт. Кроме того, можно воспользоваться Docker или XAMPP, чтобы поднять сервер вручную. Ваша цель на этом этапе — получить полностью рабочую установку WordPress, с которой можно экспериментировать.

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

Чтобы подключиться к реальной работе, стоит посмотреть, какие задачи нуждаются в тестировании. В баг-трекере WordPress, Trac, есть специальная метка good-first-bug — это баги, с которых удобно начинать новичкам. Обычно к таким задачам уже есть описание и пример воспроизведения, так что останется установить соответствующую версию WordPress, повторить шаги, описанные в задаче, и проверить, воспроизводится ли проблема. Если найдете баг или подтвердите уже найденный, можно оставить комментарий или составить отчет о тестировании.

Очень важная часть участия в open source — это взаимодействие с сообществом. У WordPress есть свой сервер Slack, где проходят регулярные встречи тестовой команды. На таких митингах обсуждают приоритетные задачи, новые релизы и тест-планы. Присоединиться просто — в make.wordpress.org/test нужно найти канал #core-test. Общение открытое и дружелюбное, новичкам всегда рады.

Nextcloud

Nextcloud — это личное и корпоративное облачное хранилище с богатым функционалом для совместной работы (файлы, календари, звонки, задачи и т. д.), поэтому тестировать здесь можно как интерфейсные элементы, так и глубоко интегрированные функции.

Так же, как и с предыдущим веб-приложением, сначала нужно развернуть локальную установку с помощью Docker. В репозитории nextcloud/docker есть готовые конфигурации. Как и с WordPress, важно наличие рабочего инстанса с правами администратора, чтобы свободно устанавливать приложения и включать/отключать функции.

Далее стоит перейти к GitHub. Основная активность по разработке ведется там: публикуются баги, задачи, обсуждения и пулл-реквесты. Раздел Issues — это главный источник задач для тестирования. Для начала советую искать по меткам bug, high, 2-review, а также good first issue, если нужно вкатиться в проект мягко.

Для общения с сообществом у Nextcloud есть форум и обсуждения прямо в GitHub. Если готовы брать на себя тестовые задачи, можете подписаться на релизные анонсы или принять участие в тестировании бета-версий — такие призывы регулярно появляются в форуме и GitHub.

LibreOffice

LibreOffice — офисный пакет, альтернативный Microsoft Office, с модулями для работы с текстом, таблицами, презентациями, формулами и базами данных.

Первое, что нужно сделать, — это установить последнюю из ежедневных сборок LibreOffice. В отличие от WordPress, здесь не принято развертывать что-то «локально» в классическом смысле — требуется установить десктопное приложение. На официальном сайте есть стабильные версии, но для участия в тестировании лучше использовать nightly-сборки или бета-релизы. Их можно скачать на странице разработчиков. Обычно они не требуют установки — просто запускаются из папки.

После установки имеет смысл изучить QA Documentation на вики-портале проекта. Это центр всей информации, связанной с тестированием LibreOffice. Здесь описаны роли участников, этапы тестирования, оформление баг-репортов, участие в тестировании релизов и многое другое. Есть также полезный QA Dashboard — там отслеживаются отчеты о багах и приоритетные задачи.

Далее стоит завести аккаунт на Bugzilla LibreOffice, потому что баги и фидбэки по тестированию фиксируются именно там. Все стандартно: нужно создать issue, описать версию, платформу, шаги для воспроизведения, фактический и ожидаемый результат. К багам приветствуется прикрепление тестовых файлов (например, .odt или .xlsx), которые демонстрируют проблему. Если вы только подтверждаете уже заведенную проблему — все равно оставьте комментарий, это помогает понять масштаб.

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

На практике вы получаете многое:

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

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

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

• И даже выход на первую стажировку или работу. Некоторые компании охотно берут джунов, у которых есть вклад в open source.

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

Когда вы переходите на следующий этап, будьте готовы: не все будет идти гладко. Вот несколько типичных «граблей», на которые легко наступить: 

• Многие новички стремятся сразу делать «как профи»: изучить сложные баги, поразить команду знаниями. Но на старте гораздо важнее просто фиксировать все, что попадает в поле зрения.

• Будьте вежливы. В open source-комьюнити принято быть доброжелательным и уважать других. Даже если нашли критичный баг, важно не обвинять никого в плохо работающей функциональности, а помочь ее исправить.

• Не стоит тратить слишком много времени в одиночку, пытаясь разобраться с непонятными частями проекта. Если что-то не работает — проще и быстрее задать вопрос в чате сообщества. Например: «Установила проект по инструкции, но не работает шаг X — это баг или я что-то пропустила?». В большинстве случаев ответ придет за пару минут.

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

Уже получили практический опыт? Попробуйте устроиться к нам в компанию! Присоединяйтесь к команде TATLIN.FLEX и работайте над современной системой хранения данных с собственным SDS. Больше вакансий — на нашем карьерном сайте.

Уверенный уровень: переходим к тестированию продуктов

Если open source — это во многом про «поучаствовать и помочь», то коммерческий продукт — это про ответственность. Здесь все работает на бизнес: клиенты платят, заказчики ждут, сроки поджимают. Условно: в песочнице баг — это прикольно, в open source — это вклад, а в коммерческом продукте — это риски.

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

BI.ZONE Bug Bounty

BI.ZONE Bug Bounty — это российская платформа для поиска уязвимостей в системах компаний. Работает по модели классических баг-баунти платформ: исследователи находят баги, отправляют отчеты и получают вознаграждение.

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

Чтобы начать работу, нужно выбрать интересную программу из списка. Перед началом тестирования обязательно следует изучить Scope (область тестирования) — это перечень сайтов, сервисов и компонентов, на которых разрешено проводить тесты, а также список запрещенных действий. Далее проводится исследование системы на предмет уязвимостей, связанных с безопасностью: ошибки авторизации, XSS, SQL-инъекции, нарушения в логике доступа и пр. При обнаружении проблемы необходимо составить отчет через встроенную форму, описав баг, приложив шаги воспроизведения и доказательства (скриншоты, видео или PoC).

Kwork

Kwork — российский маркетплейс фриланс-услуг, где тестировщики могут предлагать свои услуги или откликаться на заказы, связанные с тестированием программного обеспечения.​

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

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

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

• Создание собственных кворков — самый стабильный способ. Нужно зайти в раздел «Мои кворки» и создать услугу, описав, что конкретно будет сделано, за какое время и какие материалы нужны от заказчика. Важно выбрать правильную категорию: например, тестировщику подойдут разделы «Тестирование» или «Тестирование и аудит сайтов», которые находятся внутри основной категории «Разработка и IT».

• Поиск активных заказов в разделе «Проекты» — это аналог биржи заданий. Он находится в верхнем меню под названием «Проекты», и именно там заказчики публикуют индивидуальные задачи. Здесь можно фильтровать проекты по тематике (например, «Тестирование», «Техническая помощь») и оставлять отклики с предложением выполнить работу. Это отличный способ начать, особенно если пока нет отзывов.

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

Что может стать для вас открытием при работе в компании:

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

• Коммуникация. Придется активно общаться: с разработчиками, продакт-менеджерами, дизайнерами. Важно не просто сообщить о баге, а уметь ясно объяснить, почему он важен, как его воспроизвести и как он повлияет на пользователя.

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

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

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

Ошибки возможны и на этом этапе. Например:

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

• Неумение расставлять приоритеты. В начале легко впасть в желание проверять все и сразу. Но куда эффективнее выстроить очередность: сначала критичное, потом важное, потом «по желанию». Рекомендую начать использовать баг-матрицы и severity/priority-грейдинг — это сильно упорядочит работу.

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

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

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

Обсудить в форуме