Почему в QA не нужно уметь программировать?
В головах многих из нас стоят чёткие установки:
В принципе, для становления разработчиком это абсолютная правда. Конечно, сейчас есть ещё такие вещи как нейронки аля v0, cursor и другие, которые изменили эту игру, но сегодня не о них. Для QA не нужно программировать и достаточно 2-3 месяцев для вката. Почему?
Для это мы разберём примерный стек обязанностей тестировщика:
1) Анализ задачи
Ты получаешь задачу от разработчиков, например, «добавить новый фильтр в каталог товаров».
Твоя задача - понять, как эта штука должна работать. Читаешь описание, общаешься с продакт-менеджером или разработчиком. Спрашиваешь:
- А как должно быть в случае X?
- А если я введу вот это?
- А что должно произойти, если пользователь ничего не выберет?
Ты проясняешь все сценарии. Даже те, которые могли не учесть.
2) Составление чек-листа
Ты записываешь в список все проверки, которые нужно сделать:
- Что будет, если выбрать один фильтр?
- Несколько?
- А если пользователь на телефоне?
- А если у него медленный интернет?
Например, на нашей работе мы видим какое-то требование, например, скидка 10%. Записываем в чек лист - "скидка должна быть 10%"
Или фича должна быть доступна для пользователя, который:
- зареган в приложении
- имеет рейтинг >10
- не имеет неоплаченного штрафа на аккаунте
Проверки:
1. доступна ли фича для не зарегистрированного пользователя
2. Доступна ли с рейтингом 9, 10, 11?
3. С / без штрафом
3) Тестирование
Ты открываешь продукт и начинаешь буквально пытаться его сломать.
Кликаешь, переключаешь, вводишь всё что угодно в поля, обновляешь страницу, делаешь то, чего не ожидали разработчики.
Но сначала делаем положительную проверку = проверяем, что все работает так, как описано в требованиях. Например, задача - проверить поле регистрации. Можно 10 часов потратить на то, чтобы в поле email вводить разный бред. А потом откажется, что кнопка «зарегистрироваться» вообще не работает.
4) Регресс и повторное тестирование
Разработчик исправил баг - теперь ты проверяешь, что он реально пофиксил и ничего не сломал по пути.
Потому что один фикс может потянуть за собой новый баг - это нормально. И твоя задача - выловить такие штуки до релиза.
5) Коммуникация
Ты общаешься с разработчиками, продактами, менеджерами.
Тебе не нужно уметь программировать, но нужно понимать логику, уметь задавать вопросы и объяснять проблему так, чтобы тебя поняли.
Конечно, без знаний, как работают запросы, браузеры, инструменты разработчика (DevTools), API и многого другого не обойтись, но это не программирование.
Но можно зарабатывать еще больше. Есть такая штука как AQA - тут ты уже пишешь софт, который сам за тебя тестирует что нужно. Обычно для таких целей используют Selenium и Playwright. Вкатываются сюда обычно после ручного тестирования.
Всё.
В головах многих из нас стоят чёткие установки:
- В IT без кода — никак
- Срок входа — минимум год
В принципе, для становления разработчиком это абсолютная правда. Конечно, сейчас есть ещё такие вещи как нейронки аля v0, cursor и другие, которые изменили эту игру, но сегодня не о них. Для QA не нужно программировать и достаточно 2-3 месяцев для вката. Почему?
Для это мы разберём примерный стек обязанностей тестировщика:
1) Анализ задачи
Ты получаешь задачу от разработчиков, например, «добавить новый фильтр в каталог товаров».
Твоя задача - понять, как эта штука должна работать. Читаешь описание, общаешься с продакт-менеджером или разработчиком. Спрашиваешь:
- А как должно быть в случае X?
- А если я введу вот это?
- А что должно произойти, если пользователь ничего не выберет?
Ты проясняешь все сценарии. Даже те, которые могли не учесть.
2) Составление чек-листа
Ты записываешь в список все проверки, которые нужно сделать:
- Что будет, если выбрать один фильтр?
- Несколько?
- А если пользователь на телефоне?
- А если у него медленный интернет?
Например, на нашей работе мы видим какое-то требование, например, скидка 10%. Записываем в чек лист - "скидка должна быть 10%"
Или фича должна быть доступна для пользователя, который:
- зареган в приложении
- имеет рейтинг >10
- не имеет неоплаченного штрафа на аккаунте
Проверки:
1. доступна ли фича для не зарегистрированного пользователя
2. Доступна ли с рейтингом 9, 10, 11?
3. С / без штрафом
3) Тестирование
Ты открываешь продукт и начинаешь буквально пытаться его сломать.
Кликаешь, переключаешь, вводишь всё что угодно в поля, обновляешь страницу, делаешь то, чего не ожидали разработчики.
Но сначала делаем положительную проверку = проверяем, что все работает так, как описано в требованиях. Например, задача - проверить поле регистрации. Можно 10 часов потратить на то, чтобы в поле email вводить разный бред. А потом откажется, что кнопка «зарегистрироваться» вообще не работает.
4) Регресс и повторное тестирование
Разработчик исправил баг - теперь ты проверяешь, что он реально пофиксил и ничего не сломал по пути.
Потому что один фикс может потянуть за собой новый баг - это нормально. И твоя задача - выловить такие штуки до релиза.
5) Коммуникация
Ты общаешься с разработчиками, продактами, менеджерами.
Тебе не нужно уметь программировать, но нужно понимать логику, уметь задавать вопросы и объяснять проблему так, чтобы тебя поняли.
Конечно, без знаний, как работают запросы, браузеры, инструменты разработчика (DevTools), API и многого другого не обойтись, но это не программирование.
Но можно зарабатывать еще больше. Есть такая штука как AQA - тут ты уже пишешь софт, который сам за тебя тестирует что нужно. Обычно для таких целей используют Selenium и Playwright. Вкатываются сюда обычно после ручного тестирования.
Всё.