«Не обязательно быть дипломированным специалистом в области компьютерных наук. Не обязательно уметь писать код. Не обязательно быть гением. Любой человек может стать востребованным QA-специалистом.
Это моя дорожная карта, показывающая навыки, которые я приобрел за первый год работы тестировщиком.
Но сначала я расскажу, где я работал до того, как я получил оффер.
Перед тем тем как стать тестировщиком
- Вообще ничего не знал о QA
- 6 месяцев работал в компании, занимающейся поддержкой клиентов по имейлу (отсюда я перешел на свою первую работу в QA)
- Изучил основы веб-разработки. То есть HTML/CSS/JS/React/что-то знал о Node
- Сделал 15 фронтенд-проектов + сайт-портфолио. Благодаря самообразованию на freeCodeCamp
- Сделал 1 базовый веб-сервис на Node.js, пройдя курс обучения на freeCodeCamp
- Теория Agile (изучил по аудиокниге)
- Работал я в customer service:
- Обслуживание клиентов, связанных с приложениями или техникой
- Shipt Shopper (доставка продуктов)
- Консультировал клиентов в фотокиосках Walgreens
- Customer service по телефону:
- Прием звонков в боулинге — отвечал на вопросы и помогал составлять расписания вечеринок
- Отвечал клиентам, позвонившим в магазин Home Depot с вопросом о наличии товара на складе
- Еще опыт в розничной торговле:
- Работал кассиром в Walgreens, затем старший кассир
- Обслуживал покупателей в магазинах Home Depot и Walgreens
- Координация с поставщиками и устранение сбоев в обслуживании клиентов
- Образование: бакалавр, учитель испанского языка
- Стажировка в Испании 105 дней
- Без лицензии на преподавание, но закончил много релевантных курсов
- Полезные навыки для QA («майндсет QA»):
- Внимательность к деталям
- Любознательность
- Умение сотрудничать с людьми, быть полезным
Дорожная карта
Существуют ресурсы, наподобие этой известной дорожной карты QA Roadmap на RoadMap.sh, и там, на мой взгляд, усложняют.
Продолжение:
Такие дорожные карты могут быть полезны, если читать между строк, выбирать полезное и отбрасывать остальное. [прим.: конечно, освоить все скиллы и все инструменты на этой дорожной карте абсолютно нереально, таких людей не существует в природе.]
Что касается моей личной дорожной карты, то я всегда стремился и стремлюсь, чтобы все было просто.
Итак, этапы моего пути.
1 — Эксперименты с QA
Просто попробуйте потестировать что-то ради интереса.
- Выберите одну функцию какого-то хорошо знакомого приложения.
- Запишите действия, которые выполняет пользователь при правильном использовании функции.
- Представьте, как пользователь может использовать эту функцию неправильно: намеренно или случайно, злонамеренно или просто по ошибке, на разных девайсах и браузерах, в разных условиях. Подойдите творчески к вопросу, как можно использовать эту функцию. Фиксируйте любое нестандартное поведение приложения, возникающее в результате этого эксперимента.
- Если обнаружили ошибку или что-то в функции, что может не понравиться пользователю, или что-то, что можно улучшить, запишите это в свой отчет, с просьбой исправить ошибку или внести улучшения.
- Отправьте им свой отзыв (фидбек). Напишите в службу поддержки, если таковая имеется. Или выясните, кто является разработчиком этого приложения. Если это компания, найдите в LinkedIn человека, который работает в ней и может помочь в исправлении этой функции. Например, если речь идет о фронтенд-функции, найдите веб-разработчика, который работает в этой компании, и напишите ему.
А после этого прислушайтесь к своим ощущениям.
- Нравятся мне такие задачи?
- Что не нравится?
- Могу ли заниматься этим весь день?
- Несколько лет?
Если с самого начала не понравилось, то, возможно, вам в целом не подходит тестирование, как карьера.
Это упрощенное «введение в QA», но оно отражает ключевые задачи, которые возлагаются на QA:
- Дымовое тестирование — предварительное оценочное тестирование предполагаемого пути пользователя
- Написание тест-кейсов, хоть и в упрощенном виде — запись шагов пользовательских сценариев, чтобы в будущем можно было повторить этот «проход» (регрессионное тестирование); так мы можем с уверенностью сказать, что что-то, что когда-то работало правильно, теперь не работает
- Исследовательское тестирование — поиск проблем в User Experience с использованием «несценарного», творческого подхода, то есть «свободного поиска» багов.
- Написание отчетов об ошибках — письменное изложение, как воспроизвести найденную ошибку в приложении, чтобы помочь разработчику быстрее ее устранить.
- Коммуникация с разработчиками и передача багов — непосредственное общение с разработчиком, чтобы сообщить ему о найденной ошибке.
2 — Изучение теории QA
Ниже приведен список понятий, которые необходимо изучить в любом случае. Почитайте 1-2 статьи по каждой теме, или, если вы не визуал, а аудиал, послушайте 1-2 подкаста или видео на YouTube, посвященные фундаментальным понятиям QA. Тематических подкастов и видео — огромное количество. Не слишком усердствуйте — просто получите базовое представление о том, что означают базовые понятия, и как они связаны друг с другом:
- Agile-методологии — Scrum и Kanban
- Регрессионное тестирование, Дымовое тестирование, Санити-тестирование, Приемочное тестирование
- Планы тестирования/STLC-циклы тестирования/тест-кейсы/тест-сьюты
- Тестирование черного, белого, и серого ящика
- Ручное тестирование и автоматизированное тестирование:
- Какова конечная цель автоматизации в QA-проектах?
- Почему нужно изучать ручное QA ДО ТОГО как изучать автоматизацию и ЯП
- Как соотносятся между собой жизненный цикл разработки программного обеспечения (SDLC) и жизненный цикл тестирования (STLC) (прим.: здесь на одном рисунке)
- Пирамида тестирования
- Менталитет разработчика по сравнению с менталитетом тестировщика (а здесь статья о том, как они общаются)
- Frontend и Backend тестирование
- Лучшие практики в QA
Ссылок автор статьи не дает, считая, что:
- Тяжело назвать самый лучший информационный ресурс в сфере QA, их огромное количество
- Вполне возможно, что есть отличные ресурсы, о которых автор не знает
- Ресурсы могут устареть или перестать быть нерелевантными
- И главное, с чем поспорить трудно, «если вы хотите добиться успеха в IT, вы должны быть готовы к самостоятельному поиску информации — даже сеньоры целыми днями гуглят»
3 — Диверсифицируйте свой QA экспириэнс
Далее применяйте то, что узнали о теории и лучших практиках QA, чтобы начать набирать опыт.
Рекомендую свой стартер-кит, чтобы начать тестирование:
- Мобильное приложение — будет лучше, если у вас есть смартфон и Android, и iPhone, но в принципе достаточно чего-то одного
- Статический веб-сайт — информационный сайт, без регистрации пользователей и подобного сложного
- Веб-приложение — сайт посложнее, на котором можно создавать учетные записи, сохранять данные и т.п.
- Тестирование API — много бесплатных публичных API есть в интернете (в частности в блоге автора их список)
Если не знаете, с чего начать, найдите в интернете специализированный сайт, посвященный например мобильному тестированию, тестированию API и так далее.
Не нужно усложнять и перегружать себя излишней информацией. Вы пока — простой пользователь. Какие функции есть в этом приложении? Что я должен сделать с этой функцией? Как я могу неправильно использовать эту функцию? Как я буду фиксировать результаты тестирования, чтобы любой человек после меня мог повторно проверить то же самое через месяц? Как четко описать найденные баги, чтобы разработчик мог воспроизвести их у себя.
4 — Создание портфолио
Чтобы быть конкурентоспособным в 2023 году вы должны быть хоть в какой-то мере публичным лицом.
Сделайте себе сайт на Squarespace или в другом конструкторе сайтов, чтобы не тратить время на создание сайта.
Расскажите о своем опыте в разделе «Проекты»:
- Посты в блоге по теории QA
- Мини-туториалы, чтобы кто-то мог чему-то научиться по вашему опыту
- Тест-кейсы, написанные вами для реальных приложений
- Баг-репорты, написанные вами по реальным ошибкам
Создайте аккаунт в социальных сетях X или LinkedIn и пишите:
- Краткие посты по теории QA
- И дублируйте что-то как шортсы на YouTube
- Посты о ваших интересных тасках
- Большие подробные посты-размышления
- Создайте свою мини-сеть из людей, тоже изучающих QA
- Обращайтесь к разработчикам, которые создают инди-приложения, чтобы потестировать их бесплатно, чтобы получить опыт
5 — Изучайте автоматизацию
Да, чтобы получить первую работу ручного тестировщика/QA-аналитика, не обязательно уметь кодить или изучать фреймворки.
Но знание ЯП и фреймворков поможет получить первую работу.
На самом деле, чтобы устроиться на работу автоматизатором QA, вам не обязательно знать ручное QA. Но в любом случае лучше знать, чем не знать. Вы найдете работу намного быстрее.
Если вы умеете программировать, формируйте свои гугл-запросы так:
«QA Automation test framework <язык программирования, который вы знаете> <тип приложения (web/API/mobile/etc.)>».
Это даст вам несколько подсказок по путям развития.
Если вы (еще) не умеете программировать, формируйте запрос так:
«QA Automation no-code test framework free»,
и вы что-то найдете.
Нужно понимать, что вам рано или поздно придется выучить один из языков программирования. Да, существуют no-code-инструменты и low-code-инструменты, но вы же не хотите, чтобы вас ограничивало неумение писать код. Это приведет к тому, что вы навсегда застрянете на trainee- или junior-уровне, потому что не сможете создавать собственную инфраструктуру для решения задач, недоступных для этих no-code и low-code инструментов.
Вам достаточно освоить хотя бы один из этих языков:
- TypeScript (сначала изучите JavaScript, затем TypeScript)
- (Вы сможете использовать TypeScript в любых инструментах автоматизации, поддерживающих Node.js)
- Java
- C#
- Ruby
- Python
Большинство инструментов автоматизации поддерживают эти языки. Каждый говорит, что его любимый язык — лучший; я работал с TypeScript, Ruby и Python, и у каждого из этих ЯП есть свои плюсы и минусы. Просто выберите тот, который, по вашему мнению, вам будет легче изучить. Лично я являюсь поклонником TypeScript, а большая часть индустрии, похоже, ориентирована на Java, но работа найдется для знающих любой из пяти этих языков. Важен не язык, а умение эффективно пользоваться им для решения задач.
Автоматизация — это то, что должно быть всегда в поле вашего зрения. Нравится вам это или не нравится, но на любых руководящих должностях в QA, как правило, требуется хотя бы некоторое знание ЯП и опыт автоматизации, поскольку отрасль QA движется именно в этом направлении. Ручник будет нужен ВСЕГДА, но по мере развития технологий все большее количество рутинных тестов может быть, и будет автоматизировано. По крайней мере, вы сможете сделать свою жизнь легче, автоматизировав некоторые свои задачи, даже если формально автоматизация не входит в ваши должностные обязанности.
Ну и строчка в резюме о знании ЯП.
6 — Apply, Network, Build
К этому моменту вы уже знаете, что делать. У вас уже есть скиллы, есть крепкое понимание базовых концепций, и есть опыт, и вы можете строить свою собственную дорожную карту.
Создавайте и укрепляйте личные связи в социальных сетях.
Доработайте свое резюме с помощью карьерных коучей или консультантов… и с помощью AI — а как же.
Подавайте заявки на вакансии, если вы соответствуете хотя бы 50% требований, если вы уже имели какую-то практику, или более-менее разбираетесь.
Показывайте свою работу и знания в портфолио, не забывайте обновлять его. Продолжайте пополнять портфолио, пока не получите оффер.
Создавайте свой интересный контент для органичного формирования сети людей, которые могут предложить вам работу. Сотрудничайте с другими QA, устраивайте кофе-чаты в Google Meets, Zoom или еще где-нибудь, старайтесь быть всеобщим знакомым и полезным человеком.
Чего избегать
Вам нельзя:
- Прекращать обучение надолго
- Сокращать круг общения
- Терять веру в то, что у вас есть шанс
- Прекращать рекламировать свою ценность как специалиста
Это долгий путь. Но, по моему личному опыту, путь в QA сейчас короче, чем в разработчики. И, как мне кажется, почти никто не занимается публичной презентацией себя как хорошего QA-специалиста, поэтому у вас будет преимущество.
Будет тяжело, но вы справитесь.»
Источник. Автор работал в небольших компаниях, за год поднялся к должности SDET. Есть сертификат ISTQB Agile Tester (CTFL-AT). Хобби — паркур. Живет в США, в провинции (Висконсин).
