Начать карьеру в тестировании — задача не из простых, особенно когда за плечами только теория и пройденные курсы, а в портфолио нет ни одного реального проекта. Большинство вакансий требуют опыт, которого у новичка еще нет, и именно на этом этапе часто возникает ступор: где взять кейсы, если тебя еще никуда не взяли.
Я Юлия Ковшова, руководитель группы компонентного тестирования защиты данных в 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-грейдинг — это сильно упорядочит работу.
Недостаточно коммуникации. Бывает, что баг оказался критичным, но разработчика не предупредили, или требования остались неясными. Полезно выработать привычку. Есть сомнения — задайте вопрос, нашли баг — обсудите его с разработчиком. Чем активнее вы уточняете ожидания и меньше боитесь делать фоллоу-ап, тем качественней ваша работа и крепче доверие внутри команды.
Работа в компании часто становится поворотным моментом, когда приходит осознание себя как профессионала. Тестировщик понимает: он уже не просто учится, а действительно влияет на продукт, защищает интересы пользователей и отвечает за качество. Такой опыт помогает почувствовать свою ценность в команде и увидеть реальный результат своей работы.
А с какими трудностями сталкивались вы? Вспомните себя в начале пути: что казалось самым сложным? Где застревали чего боялись или, наоборот, что помогло почувствовать уверенность? Поделитесь своим опытом — возможно, ваш комментарий поможет кому-то сделать следующий шаг.