Приветствую! Меня зовут Игорь Ниточкин. Я руковожу агентством тестирования Qualitica. Мы активно растем и ищем новых тестировщиков. Дела идут хорошо, но эта статья не для того, чтобы хвастаться. Дело в том, что найти сотрудника в нашей сфере - большая проблема. Опытных тестировщиков немного, а точнее хороших тестеров просто нет!
Ладно, всё не так категорично:) Я расскажу, как мы справляемся с этой проблемой.
Риски найма начинающих тестировщиков?
На рынке труда очень много новичков, закончивших курсы Яндекса и SkillBox. Конечно, их учат теории и дают задачи на закрепление материала. Они заявляют, что знают рабочие инструменты, но опыта использования пока мало. На практике они не сталкивались с дефектами и ошибками.
Им дают базовые знания, например, готовые запросы, которыми можно вызвать API. Сделать что-то более сложное такие начинающие тестировщики ещё не могут.
Другая категория тестировщиков-новичков, не готовых к полномасштабной работе над коммерческим проектом клиента — асессоры. У них узкая специализация — проверка багов. Они работают над конкретной задачей, а не над всем проектом. А как правило, все запросы клиентов - это полноценные проекты, а не набор задач.
Скажете, можно обучить новичка, дать возможность поработать над внутренними проектами и вырастить себе тестировщика? Да, но на это нужно много времени, а пока такой тестировщик будет у нас «на скамейке запасных». Клиентам нельзя предоставлять «зеленых» специалистов, над коммерческими задачами у нас работают тестировщики уровня не ниже Middle
У нас большой поток проектов, требования рынка постоянно растут. Нужны специалисты с опытом работы на реальных проектах, которые смогут достаточно быстро включиться в работу. Но опыт опыту — рознь. Расскажу, из кого может получиться хороший тестировщик и среди каких специалистов его нужно искать.
Кто может стать тестировщиком?
Тестировщиком может стать специалист, который имеет технический бекграунд.
1. Разработчики
Многие думают, что бывшие разработчики — лучшие тестировщики. Но тестировщик должен перебирать и ломать систему, а разработчик привык её чинить и строить. Программисты проверяют позитивные тестовые сценарии, когда всё работает так, как заявлено в техническом задании.
Есть и преимущества:
- фронтенд-разработчики сразу видят проблемы с версткой;
- бекенд-разработчики отлично пишут автотесты, нагрузочное тестирование, стресс-тесты и могут тщательно покопаться в коде.
Хорошим тестировщиком сможет стать кодер-экстраверт, который осознал, что разработка — не совсем его. Он проще переключается, многозадачен, ему больше нравится ломать, чем строить :)
Из разработчиков могут получиться отличные специалисты по пентесту, которые находят уязвимости системы на уровне алгоритмов, узких мест. Их задача - ее сломать, например, обойти систему безопасности.
2. Тим-лиды, проджект-менеджеры
Из этих специалистов могут получиться хорошие тест-менеджеры и тест-лиды, которые возьмут на себя организацию работы команды тестирования и общение с клиентами.
Тут важно разобраться, почему они решили уйти из своего направления. Если у специалиста узкая IT-специализация или образование, а в проджект-менеджменте он оказался по стечению обстоятельств, сейчас решил вернуться к своей профессии — это одно. А вот если с менеджментом в других сферах у него не сложилось, нужных навыков нет, и он просто тянется за большими деньгами — понятно, что из такого специалиста вряд ли получится хороший тестировщик.
3. Бывшие системные администраторы
Таких специалистов приходится переучивать, потому что до этого они работали с “железом”, а не системой. Как и в случае с тим-лидами и проджект-менеджерами, важно разобраться, почему сисадмин решил сменить деятельность и стать тестировщиком.
4. Специалисты с опытом технической IT-поддержки сложных сервисов
Например, высоконагруженных систем, крупных интернет-магазинов.
Это, пожалуй, один из лучших вариантов бэкграунда для отличного тестировщика. Такие специалисты хорошо знают пользовательские сценарии, системы и с какими проблемами сталкиваются реальные пользователи, понимают, как устроен веб-продукт, как он создается, знают верстку. Как правило, у них хорошие коммуникативные навыки, и они больше других нацелены на точность получения информации, более внимательны к обратной связи.
Они следят за тем, как работает система, стремятся найти ошибки и сбои, начинают разбираться самостоятельно. Они тестируют всё вручную и отлично работают в команде разработчиков.
5. Тестировщики
Ну и, конечно, люди, которые сознательно решили развиваться именно в тестировании, изучают новые методики и инструменты, развиваются, ищут баги с азартом и стремятся улучшить программный продукт.
У нас в компании чаще всего встречаются специалисты, которые как раз нацелено решили и стали тестировщиками. Они пришли к нам уже с опытом тестирования и отлично показали себя на внутренних проектах под присмотром опытных сотрудников компании.
Наши внутренние проекты также требуются детального погружения, знаний и опыта, которые не всегда по силам новичкам, и для нас это хороший "полигон" для того, чтобы проверить нового сотрудника в реальных условиях.
Вывод
Найти опытного тестировщика, способного сразу включиться в коммерческий проект, очень сложно. Вам придется изучить множество резюме, отсеять огромное количество кандидатов, чтобы выбрать среди них одного подходящего.
Обязательно надо ориентироваться на опыт специалиста. Когда мы знаем, в какой сфере работал специалист раньше, становится понятно, куда его можно поставить в команде тестировщиков, чтобы использовать его опыт и особенности более удачно
Тестировщики бывают разные: тест-лид, тест-менеджер, тест-аналитик, тест-дизайнер и т. д. Подробнее об этом я рассказывал в статье «7 подходов к тестированию».
В любой отрасли важно подходить к подбору персонала вдумчиво. А в сфере IT нужно ещё и предугадывать потребности заказчика, высокую динамику рынка и с их учетом формировать свою команду. И главное - проверяйте каждого новичка в условиях реального проекта прежде, чем предоставить его клиенту.
"Тестировщиком может стать специалист, который имеет технический бекграунд."
Вот тут поспорил бы.
Могу на собственном примере: всю ту часть жизни, когда у меня были (и есть) компьютер и приставки, я активно тратил на игры, помимо прочих хобби. Но играя мне стало интересно, а что за процессы на "кухне"? Собственно, увлечения помогли мне стать тестировщиком игр в самом начале моего пути тестировщика - можно сказать, что работа мечты. Так что тут зависит ещё и от человека: если он захочет изучать новое, постоянно совершенствоваться, то сможет "бодаться" наравне с технарями.
Дмитрий, вам повезло, вы один из тех счастливчиком, кто смог превратить хобби в профессию
Отлично написано, а главное по делу! Но вот что грустно, что это действительно острая проблема сейчас - спрос на хорошего тестировщика превышает предложение многократно(
Комментарий недоступен
Иван, нельзя говорить что мы не берем новичков, мы их берем и стараемся обучать на внутренних проектах. Другое дело что мы новичков не предоставляем на коммерческие проекты
Комментарий недоступен
Было дело, отреактировал заголок, так как он не совсем отражает нашу реальность.
Спасибо что обратили на это внимание
Над статьей проделана хорошая работа. Ёмко и понятно. Плюс, подписка.
Спасибо, было интересно. Только где же брать опыт новичкам?
Никто не говорит что новичков брать не надо, порой взять новичка в итоге бывает выгоднее.
Джуну важно понять, какие навыки востребованы и пробовать приобретать новый опыт. Например, брать проекты на фрилансе и описывать их в резюме чуть более конкретно. Показать проекты, где была командная работа и как строилась, где были проекты, в которых тестировщик участвовал с самого начала, принимал участие в разработке документации и пр. Хотя бы так.
Согласна с автором , сама пришла в тестирование из тех.поддержки и знаю много подобных примеров
Мне подошёл 4 вариант.
Был долго техподдержке и потом перешёл в тестирование.
Тестировщиком может стать специалист, который имеет технический бекграунд.Дополнил бы:
Если говорить о тестировании в IT (Software Testing), то скорее важен опыт, увлечение, интерес, стремление именно к этому самому Software😉
Ну если выделить самую важную метрику: То это максимально быстрый поиск и оформление багов, от которых пользователи максимально страдают, или которые приносят максимальные убытки иным способом.
Техподдержка, как бэкграунд, в сравнении с остальными максимально резонирует(или по навыкам, или по мотивации) с большей частью пунктов(кроме наверное последнего). А для продуктов, которые человеко-ориентированы - эти пункты и важнее всего.
Вот кого точно не нужно брать, так это тех, кто хочет войти в IT через тестирование, а на самом деле метит в разработку - из таких хороших тестировщиков точно не получится) Им могу посоветовать сразу учиться на разработчика и искать работу джуном.
Почему-то я даже не думала, что специалисты техподдержки могли бы стать профессиональными тестерами.
Порой самые очевидные вещи не замечаешь, пока не начинаешь в это реально погружаться
Забыли только написать, что некоторые разработчики на проектах где это возможно могут многое и без тестировщиков. Потому что понимают что делают, и при запуске проверяют самые рисковые места, и могут даже место ошибки узнать. И тестировщики остаются для подстраховки и проверки на соответствие ТЗ. Но это зачастую аутсорсерам не нужно, потому что быстрей быстрей, и деньги за открытие и закрытие тасков.
Вы думаете тестировщики нужны только в тех компаниях, где разработчики не понимают, что делают?) Если следовать Вашей логике. Мне кажется, это заблуждение.
Я написал "могут многое". Шанс ошибки в продакшен будет всегда. Даже со всеми видами тестировщиков. Но разумеется тестировщики будут заниматься в основном проверкой качества, что будет повышать эту метрику, в том числе нахождение ошибок. Особенно это важно, где код один, а платформ много - разные типы браузеров, версии операционных систем. Разработчик не будет запускать везде.
Вообще моя боль души скорее в том, что тестировщики находят, а чинит зачастую не тот кто проектировал(для распространения знаний, и заменимости людей). И ошибки могут чиниться и "создаваться" по кругу, порой повторно. Просто затыкать дырку людьми, и не видеть такую экономию от лишней работы я видел часто. А всего то нужно повысить ответственность разработчиков, но тут свои риски, и нужно знать когда что перевешивается.
В некоторых компаниях на показателе количества возвратов и перевозвратов основаны KPI разработчиков) Даже если они уже работают на других проектах, это его карма)
Только этот KPI (если рассматривать как штраф) ещё бы помножить на степень влияния на процесс распределения задач(тасок). Иначе я бы уволился)
Это для случаев командной разработки, когда таска(возвращенная) может попасть случайному человеку из команды.
На соответствие тз на мой взгляд должны проверять менеджеры, тестировщики в свою очереь обеспечивают качество проукта, проверяя все возможные функциональные сценарии.
Менеджер должен протыкать все кейсы? Ну по логике рулевой должен верность дороги определять, да. Но будут слепые зоны если не привлекать тестировщиков.
Проходить тест-кейсы однозначно дожен тестировщик, но вот проконтролировать что тест-кейс соответствует требования ТЗ должен все же менеджер
То есть тут 2 процесса
1)Таска от тестировщика, который проверят и на ТЗ в случае несоответствия ТЗ проходит сначала к менеджеру, а не разработчику.
2)Менеджер сам проверяет.
Я за то что надо оба процесса одновременно, и это будет best practice из моего опыта(в котором всегда среди ролей была роль кодера(я кодер, я так вижу xD)).
А тестировщик, получается, не умеет читать? Или боится аналитика, который ТЗ/спеку писал?
В идеале, тестировщик должен тестировать документацию. Всё таки, на этапе ТЗ баги/недоработки править быстрее, чем когда написанное ПО уже в проде)
Правда, это точно не Джун должен делать.
На самом деле, как показывает практика, некоторые специалисты просто стесняются писать аналитику, причем при разборе ситуационного примера он понимает как надо действовать. Как справляться с такой ситуацией это вообще отдельный разговор.
Слишком Ж И З Н Е Н Н О.
Обычно самые приятные проекты именно те, где во время тестов появляется как раз это самое чувство азарта.
Для меня как показатель, что работа интересна и может увлечь.
Развёрнуто описано)
Мне вот тоже казалось, что бывшие разработчики — лучшие тестировщики, потому что знают код и пишут авто-тесты.
Знаю реальные истории, когда бекенд-разработчики решали стать тестировщиками.
Генрик, согласен что для автоматизатора иметь бекграунд разработчика будет несомненым плюсом, для ручного тестирования все же мне кажется будет плюсом несколько другие качества
Кроме написания автотестов, нужно их ещё читать и поддерживать и понимать в чём ошибка, что затратно если один тест не позволяет за счёт параметров покрыть много кейсов. Да и бывшим кодерам лишь бы покодить. Правда некоторые могут архитектуру тестов похлеще самого проекта замутить. Чтобы минимизировать эти затраты пишут автотесты, которые на одной кодовой базе с проектом, но их пишут практически всегда кодеры с проекта, что время, а также такие тесты могут мешать изменениям проекта или сборки.
Комментарий недоступен
На днях за час использования paypal отловил пару багов: в разделе обратной связи съезжает вёрстка при разрешении 1366*768, а ещё система выдаёт некорректные сообщения в том плане, что счёт заблокирован и без звонка в саппорт не обойтись, или переводы между российскими пользователями приостановлены, но пользователь видит одно и то же: "Приносим свои извинения. Не удаётся отработать ваш запрос. Повторите попытку позже." и вишенка на торте это разница 8% при конвертации валют usd/rub, сотрудник пояснил, что это комиссия за вывод, которая зашита в курс, а так комиссия на вывод 0%))
В целом где-либо постоянно слышу фразу: "У нас такое впервые случается", да и жена уже ничему не удивляется, я всегда считал это каким-то проклятьем будто ходячий детектор ошибок, но недавно друг посоветовал пойти в тестировщики и пазл сложился! Подскажите с чего начать, чтобы сделать мир лучше?)
В мифах и легендах древней Греции есть такие титаны, которые держали небосвод. Они его держали, потому что больше никто не мог. И не помню, но кажется им даже ещё проблем за это добавляли. У меня сложилось впечатление, что если чинить там, где очень много ошибок - то, они там скоро опять появятся, да и никто из принимающих системные решения(и сидящий на кормушке) не оценит, так как иначе этих ошибок бы уже не было. Всё упирается в процессы в компании. Реально сделать мир лучше и себе в удовольствие получится, если идти туда, где часть ошибок систематически правят до тестировщиков, а также уже есть тестировщики. Но такие места хороши при расширении штата. Если же текучка кадров - это тоже вызывает вопросы.
Комментарий удален модератором
А на стажировку к вам можно попасть?