Есть, но не для балбесов.
https://habr.com/ru/post/666930/ Суть профессии
Профессия тестировщика подойдет тем, кто хочет работать в ИТ, но не готов погружаться в тонкости разработки. Выучиться на тестировщика куда проще, чем на программиста. Эта работа не требует специфических навыков, достаточно хорошей соображалки и элементарной компьютерной грамотности: нужно владеть «Вордом» и «Экселем», уметь гуглить информацию. Если знаешь Atlassian — Confluence, Jira, — это плюс.
Сейчас есть много курсов для тестировщиков, главное — иметь желание и понимать, что надо трудиться, преподаватель свои мозги в голову студента не положит. Еще многое зависит от склада и гибкости ума. У меня есть коллега, он работал видеооператором, а потом ему надоело, он поучился на курсах и сейчас тестит что-то про блокчейн. А есть знакомая фармацевт, которая загорелась идеей заняться ИТ, но курсы ей не зашли, она постоянно жаловалась, что ничего не понимает, в итоге забросила.
/programmist-ili-net-test/
Сможете ли вы стать программистом и зарабатывать миллион в секунду?
Знание любого языка программирования тестировщику тоже не помешает, ведь многие ручные операции можно и нужно автоматизировать, не отвлекая разработчиков от их дел. В одних компаниях автоматизация — это обязательное условие для тестировщика: например, в «Гугле» ручного тестирования нет в принципе. В других — по желанию, но больше получают те, кто автоматизирует. Не повредят и общие технические знания: как работают сети, что такое HTTP-протокол, какая бывает архитектура приложений.
Технических сложностей в тестировании нет, тут все просто. Самое трудное — это разобраться в том, как работает твой сервис или продукт. Сейчас тестировщики нужны везде. Многие компании, не выпускающие программы вовне, все равно имеют какое-то внутреннее ПО, свои CRM, их тоже должен кто-то поддерживать. Мне иногда приходят приглашения на собеседования из совершенно разных компаний: это и банки, и интернет-магазины, и даже ставки на спорт.
Хорошо, когда у тебя есть знания в сфере работы компании и понимание бизнес-процессов: так проще воссоздать портрет потенциального пользователя. Он помогает понять, какие функции нужны клиенту и как он их будет использовать. Например, сейчас я работаю в банке, и для нас стало открытием, что у многих из наших клиентов смартфоны старых моделей. Теперь мы тщательнее тестируем приложение на устройствах с небольшим экраном.
Еще одна сложность — это работа в условиях недостатка документации, то есть технического задания. Разработчик пишет код на основе ТЗ, а тестировщик с ним сверяется при проверке. Если задания нет или оно недостаточно конкретное, разработчик понимает его по-своему, тестировщик — по-своему, что выливается в разногласия и споры.
У меня недавно была ситуация: банк предлагает два типа кредитов — назовем их кредит-1 и кредит-2. Чтобы получить кредит-1, нужно заполнить анкету в приложении — и деньги тут же приходят на счет. А кредит-2 можно оформить только в отделении. Соответственно, когда клиент нажимает в приложении баннер кредита-1, ему должна открываться анкета, а когда нажимает на баннер кредита-2 — экран с обратным звонком. Все это обговорили устно, но нигде не зафиксировали. В итоге разработчик забыл про этот нюанс, и в его реализации анкета открывалась и для кредита-1, и для кредита-2. Он потратил время на ненужную работу, просто потому что не было ТЗ.