Как и где практиковаться начинающему тестировщику
Самый тяжёлый момент при старте новой карьеры — когда ты уже закончил обучение, но ещё не нашел первую работу. Когда открываешь вакансии, но чувствуешь, что ты к ним ещё не готов. Думаешь, что тебе нужно больше практики во всех указанных навыках, но не знаешь, где её взять без работы.
Меня зовут Никита Кулаченков, работаю тестировщиком в «Афише» и наставником на курсе «Инженер по тестированию» в Яндекс Практикуме. Много лет назад я попал в тестирование без каких-либо курсов и практикуясь самостоятельно — и с этим я собираюсь помочь и вам.
В чём проблема?
С одной стороны, если мы говорим об IT, то тестировщики находятся не в самом завидном положении, если хотят попрактиковаться. Разработчики, например, могут писать свои пэт-проекты — создавать различные приложения, придумывать и реализовывать продукты, даже если они самые простенькие. Дизайнеры могут заниматься тем же самым — открыть Photoshop / Figma / другой любимый графический редактор и начать творить. Хочешь — придумай свой вымышленный продукт с уникальным дизайном. Хочешь — попробуй улучшить чужой и положи его в портфолио со словами «смотрите, как я могу».
Тестировщик всегда завязан на работу других людей, ведь он проверяет то, что написано кем-то другим. Портфолио у тестировщика тоже звучит как нонсенс. Что он там может указать? Написанные тест-кейсы? Заведённые баги?
С другой стороны, это положение может сыграть на руку. Тестировщику не нужно тратить недели и месяцы на создание своих проектов, которые он не может создать физически ради портфолио. Так, вся практика будет сводиться к двум вещам:
Если дизайнеру нужны сильные и релевантные работы, а разработчику — хорошо написанные (с точки зрения кода) проекты, тестировщику нужно просто красиво подать себя на бумаге, а затем — на собеседовании. Но последнее сложно сделать, если дают задачки на навыки, которые вы не практиковали.
Давайте посмотрим, что с этим можно сделать.
Перед тем как начать
Исключаем очевидное
Конечно же, онлайн-курсы, которые проведут вас через тернии теории к практическим задачам на все навыки, которые могут запросить у джуна.
Так как я работаю в Практикуме, говорить буду только за него — здесь есть практика и по веб-тестированию, и по мобилкам, и по API, и по SQL, и даже блок по автоматизации есть. Если подход онлайн-школ вас устраивает — то я бы рекомендовал его. Он даёт структурированные знания с минимумом необходимости в постоянном поиске открытых ресурсов для практики.
Впрочем, это был не мой кейс. В своё время практику я искал самостоятельно и работу нашел, не прибегая к помощи курсов. Поэтому я буду рассказывать о способах, которые использовал, когда мне нужно было применить знания на практике.
Начните с собеседований
Возможно, у вас есть судорожный позыв «практиковать всё, что видел/читал/изучал». В таком случае вы, вероятно, можете потерять много времени.
Мой базовый совет всегда и для всех один — отшлифуйте резюме и отправляйте столько откликов, сколько можете. Если видите, что в целом скилы, описанные в резюме, соотносятся с тем, что вы умеете, — отправляйте отклик. И да, даже если там указано, что нужен опыт больше вашего. Моя первая работа вообще была связана с вакансией, в которой требовалось 1—3 года опыта работы и наличие высшего технического образования (ни того, ни другого у меня не было).
После первых собеседований (которые, скорее всего, будут так себе, и это нормально) вы начнёте понимать, каких именно знаний и навыков вам не хватает. Может быть, вы уже умеете делать всё, что требуется, но сыпетесь на теории. Или, наоборот, идеально знаете теорию, но когда дело доходит до практических задачек с применением определённых навыков, у вас не получается уверенно довести их до конца.
Вам важно выцепить, какие именно задачки не удалось решить и какие навыки для них требуются. После этого вы точно будете знать, что у вас проседает и на чём именно нужно сфокусироваться.
Не бойтесь откликаться и собеседоваться. Чем чаще вы это делаете, тем легче становится дальше. Вы становитесь увереннее и шанс, что вас возьмут, увеличивается. Не секрет, что уверенность и коммуникабельность нередко решают больше, чем сами навыки и опыт (который, понятное дело, у новичка будет практически отсутствовать).
Беритесь за тестовые (но только если интересно)
В вакууме к тестовым заданиям я отношусь скептически. Почему я должен тратить часы (иногда и дни) на выполнение бесплатной работы, за которую другие получают большие деньги?
Но стоит признать две вещи. Во-первых, тестовые задания дают в основном только джунам (совсем без опыта), и то нечасто. В той же сфере дизайна вплоть до синьорского уровня перед трудоустройством придется делать тестовые — и это то, с чем приходится мириться.
А во-вторых, тестовые задания — это хорошая (и часто даже интересная) практика. Они могут быть любыми — ответить на теоретический вопрос, решить задачку с SQL, протестировать приложение, найти и завести баги. Если это вызывает любопытство и занимает не больше одного вечера —, а почему бы и нет? Особенно если стоит внутренняя задача «вгрызаться зубами в любую практику».
Так, например, при поиске первой работы в одном из тестовых мне нужно было создать чек-лист для проверки основного геймплея казуальной мобильной игры:
В рамках другого тестового (тоже для мобильной) я описывал проверки по разным видам тестирования, писал отчёт со своими рекомендациями:
Приходилось и баг-репорты составлять:
Те тестовые, правда, не привели ни к какому результату — в те компании меня не взяли, но было довольно интересно позаниматься исследовательским тестированием.Итак, как практиковаться?
Исходя из моего опыта, большинство вакансий аппелируют к следующим навыкам:
Ручное тестирование (неожиданно)
Работа с тестовой документацией
Тестирование API
Тестирование БД (обычно с SQL)
Написание автотестов
В ручном тестировании
Этот навык — самый неспециализированный в списке, но несмотря на это, его сложнее практиковать без реального проекта.
Дело в том, что практически все компании тестируют свои фичи не на доступной для всех версии приложения, а на специальных тестовых окружениях — или, как их часто называют, препродах. Так, в прод (или, скажем так, публичный доступ) попадает только достаточно отполированный функционал, и найти в нём баги будет значительно сложнее, чем на реальной работе — хотя бы только потому, что это всё уже проверили тестировщики на зарплате.
Тестируя известные проекты (возьмите любой — VK, Google, Okko, YouTube), увы, максимально приблизиться к боевым условиям не получится, потому что вы видите уже готовый продукт — (достаточно) отполированную версию.
Можно попробовать сыграть в игру «Найди фичу и придумай, как бы ты её тестировал». Тинькофф, например, в своих собеседованиях любит дать задачу «Вот у нас есть вот такой экран, расскажи, как бы ты его тестировал».
Экран может быть, например, такой:
В ситуации, когда не у кого уточнить требования и есть только готовый экран, я стараюсь ответить на следующие вопросы:
Какие элементы есть на экране?
Для чего нужен каждый конкретный элемент?
Какие виды тестирования я могу применить, тестируя этот экран?
Какие проверки я могу составить исходя из подобранных видов тестирования?
Какие техники тест-дизайна помогут мне наиболее полно и правильно протестировать экран?
Исходя из ответов можно построить стратегию тестирования и составить набор тестов, а если тестируется реальное приложение, а не его скриншот — то ещё и прогнать эти тесты (по возможности) и попробовать поискать баги.
Можно попробовать поискать специальные тестовые проекты в открытом доступе — я, например, знаю проект Собаседник, где тестировщику предлагается протестировать сайт вымышленного питомника с говорящими четвероногими и найти баги —, а их там достаточно (и собачек, и дефектов).
Работа с тестовой документацией
Для начала давайте разберёмся, с чем чаще всего мы будем иметь дело:
чек-листы
тест-кейсы
баг-репорты
На самом деле этот пункт сильно пересекается с предыдущим, и мои общие рекомендации здесь будут такими же — берёте проект, берёте какой-либо его функционал и покрываете его тестами. Причем, по моим наблюдениям, чем менее популярен выбранный вами продукт, тем больше шансов, что вы найдёте баги (т.е. материал для написания баг-репортов) прямо в проде.
Главное отличие от реальной работы будет в том, что у нас нет доступа к требованиям. Без требований мы можем только догадываться, что и как работает, и не сможем найти каждую фичу, которую стоит проверить. Впрочем, составить общий список проверок, обладая знанием теории тестирования, это нам не помешает. И «завести» баг, если таковые находятся. Вы можете помочь команде проекта, если пришлете им хороший, понятный и детализированный баг-репорт. Кто знает, может быть, они позовут вас в команду? :)
Тестирование API
Когда я начинал изучать API, самой интересной частью моего обучения было тестирование публичных API.
То, что мы можем открыть сайт и проделать десяток кликов, чтобы сделать какое-то действие, а можем просто ввести запрос в Postman, передать туда нужные данные и получить такой же результат — казалось, это магия.
Если описывать API простым языком, то скажу так: представь, что можно сделать что-то на своём любимом сайте, не заходя на него. Ты просто вводишь запрос, вводишь параметры, отправляешь. Потом можешь зайти на сайт и увидеть результат!
Начать можно со специальных ресурсов, специально созданных для практики тестирования API. Например, это Reqres.in
Сам по себе сайт довольно простой — в нём есть список запросов, а также сами запросы с примерами данных на входе и на выходе.
Если вы хотите что-то посерьёзнее, я бы советовал действовать так:
Найдите сайт, который вам нравится (или который вы хорошо понимаете)
Попробуйте найти у него документацию к API
Попытайтесь найти в документации гайд по начале работы
Найдите запрос, который вы понимаете, что делает
Выполните этот запрос, следуя документации
Посмотрите результат выполнения на сайте
Когда я изучал API, я выбрал Trello — это таск-трекер, где можно создавать доски и карточки с задачами для выполнения. На самом деле в основе почти каждого IT-проекта используются подобные продукты — скажем, та же Jira.
Вот так это может выглядеть изнутри:
Есть несколько колонок, в каждой колонке — задачи. В задачах может быть текст, картинки, метки, опросы, to-do списки. В общем, очень удобно для категоризации и организации задач, целей и чего только заблагорассудится.
У Trello есть API. И этот продукт очень хорош в том, чтобы наглядно видеть результаты своих действий.
Для начала нужно разобраться с тем, как через тот же Postman подключиться к вашему аккаунту, — для этого используются ключи авторизации, о работе которых написано на странице знакомства с Trello API.
Далее можно вернуться и найти какой-нибудь простой и понятный запрос — например, создающий карточку на выбранной доске:
Слева мы видим список принимаемых параметров, каждый из которых можем раскрыть, чтобы получить пример, а справа — пример использования в разных языках программирования и ответ.
После создания карточки через запрос мы сможем её увидеть на сайте на выбранной нами доске — ну не чудеса ли?
Если вы научитесь это делать один раз, то навыки легко переносятся на реальный проект — ведь там всё так же будет документация (должна быть, по крайней мере), список запросов и принимаемые параметры. А там уже остаётся только проверять в соответствии с требованиями — какой статус, что приходит, как приходит, как реагирует фронтенд и т.д.
Работа с SQL
Вот тут нам, начинающим тестировщикам баз данных, конкретно повезло, потому что тренажёров по SQL неимоверное множество.
Выбирайте любой:
SQL-Ex — наверное, самый старый и проверенный онлайн-тренажёр для задач по SQL. И пусть вас не пугает его дизайн — переходите в раздел «Упражнения по SQL» и наслаждайтесь!
SQL Academy — сайт, где можно как научиться с нуля, так и попрактиковаться в тренажёре. Бесплатный, но есть премиум-версия, которая открывает ответы и сертификат об окончании. На доступ к задачам ограничений никаких.
LeetCode SQL 50 — литкод является самым популярным источником задач для программистов, но и для нас (тестировщиков, изучающих SQL) он может пригодиться. Можно порешать интересные задачки, и, конечно, бесплатно.
Интерактивный тренажер по SQL на Stepik — ещё один хороший тренажёр, помогающий закрепить знания на практике.
На самом деле от тестировщиков обычно требуется не очень высокий уровень знания этого языка запросов (если умеете в SELECT’ы и JOIN’ы — скорее всего, вам хватит).
Написание автотестов
Не сказал бы, что это часто встречающийся навык для джуна, но отметить его стоит. На самом деле алгоритм написания автотестов ради практики не сильно отличается от ручного тестирования и работы с тестовой документацией:
Выберите проект
Выберите функциональность
Напишите ручные тесты для выбранной функциональности
Напишите автотесты
Да, проблема нехватки требований сохраняется, но основные проверки можно провести и без них. Можете, кстати, пойти ещё дальше и автоматизировать какой-нибудь набор действий вместо того, чтобы писать тест.
Так, у меня был (и есть) сайт с модами для игр, и я почти полностью автоматизировал процесс их добавления — моя программа заходила на один сайт, копировала оттуда всю информацию, скачивала скриншоты, потом сжимала эти скриншоты через специальный сервис, а затем всю информацию копировала на мой сайт. Оставалось лишь написать уникальное описание —, но на тот момент не были развиты нейросети, так что это делал я сам. Потом своим мини-проектом я хвастался на собеседовании — может, это тоже пошло в зачёт, когда принимали решение о том, приглашать меня на работу или нет.
А можно ли всё и сразу?
Простой ответ — да. Можно, если вы пройдёте полноценную программу обучения тестированию, то всё перечисленное будет из коробки. Если понимаете, что такой формат вам не подходит или вы уже закончили обучение, но всё равно хотите практики, до трудоустройства ее придётся собирать по крупицам.
Из приятных открытий для решения задачи «А можно ли всё и сразу, да ещё и бесплатно?»: недавно я нашел платформу TestGrow — там есть тесты и практические задания на все основные навыки тестировщика. И да, это бесплатно — создатель продаёт менторство и поддержку, но в остальном задачи доступны всем без исключения.
Напомню мой основной посыл:
Закончите обучение
Хорошо поработайте над резюме
Отправляйте много откликов
Ходите на собеседования
Практикуйтесь в тех навыках, в которых вы показали себя слабее всего
Часто вам не нужно практиковать всё и сразу — скорее всего, в чём-то вы уже достаточно подкованы, а что-то требует лишь небольшого освежения. Старайтесь всегда мыслить как тестировщик, а всё остальное приложится.
