Хорошо, когда путь специалиста по тестированию начинается в команде, где уже есть QA-специалист или даже собрана целая команда – в таком случае его развитие идет плавно и продуманно. Но что делать, если процессы тестирования на проекте еще не построены, а сам тестировщик только начинает первые шаги на этом пути? Предлагаем вам инструкцию по найму и развитию QA-специалиста.
Шаг 1. На что обратить внимание во время собеседования
Продукт должен уже выйти в продакшен, сроки горят, а количество багов все не уменьшается, и стабильность оставляет желать лучшего. Обычно в такой момент задумываются над тем, что неплохо было бы взять в команду специалиста по тестированию, который поможет искать баги и контролировать процесс вывода продукта в продакшен. Однако, нанимать специалистов с опытом построения тестовых процессов дорого и долго, поэтому проще найти новичка: он и дешевле и на рынке труда сейчас их много, а там уже как-нибудь он сам разберется и научится.
И вот решение принято, вакансия опубликована и на почту упало несколько десятков резюме. Осталось найти нужного кандидата.
Первое: подготовьте вопросы до собеседования. Не нужно спрашивать про белый и черный ящики, или как протестировать карандаш (только ленивый не загуглит ответы на эти вопросы), вы не только потратите впустую время, но и оттолкнете кандидата. Лучше придумайте кейс, который реально случился у вас на проекте, например, форма поиска или может форма обратной связи. Подготовьте несколько несложных задач на знание SQL. Если проект является веб-сервисом, то можно поговорить про REST-запросы и коды ответов. Задайте вопросы про Linux, потому что знание хотя бы основ окажется большим плюсом в снятии логов и дальнейшей работе.
Второе: смотрите, как кандидат думает, а не на его знания – основные знания можно просто зазубрить. Тот же ISQB можно сдать, просто выучив теорию. А вот думать как тестировщик сможет не каждый. Поэтому лучше посмотрите на примере, как человек будет тестировать простую форму, заодно узнаете, как он выбирает приоритеты багов.
Третье: не давите на кандидата своим авторитетом.
Шаг 2. С чего начать знакомство с тестировщиком, а тестировщика с системой
Самый достойный кандидат найден, со дня на день примет оффер и придет работать к вам в команду. Отлично! Часть работы сделана, вот только это малая часть. Любому, а тем более начинающему специалисту, нужны подсказки и заметки, которые помогут начать работу и быстро влиться в проект.
Начать следует с создания рабочей среды: какие доступы понадобятся тестировщику для начала? Доступ к самому тестируемому продукту, к системе управления проектом (например, Jira), к базе знаний, к Git? Будет ли тестировщик собирать проект локально на своем компьютере или сборка ведется на виртуальных машинах с помощью Jenkins? В таком случае туда тоже нужен будет доступ. Подготовив такой список, вы удивитесь, насколько легче принимать в команду новичков, а не только тестировщика с опытом.
Если на проекте нет тестовой документации, то сейчас есть шанс с самого начала сделать ее понятной и полезной. Подумайте, какими вы хотели бы видеть баг-отчеты, может, вам хватит стандартного шаблона, а может, проект имеет свою специфику и без какого-то определенного поля (например, логина/пароля пользователя) будет сложно воспроизводить баг. Нужна ли вам mind-map карта проекта (ее создание как раз поможет тестировщику полностью познакомиться с проектом)? Какие тесты вы хотите видеть на проекте? Будет ли время на их написание? Можно ли потом их будет переписать в документацию проекта, например в ПМИ? Решив все эти вопросы, вы значительно упростите жизнь тестировщика.
Приведенные выше советы – формальности. Следовать им или нет – ваше право. Главное – не бросайте человека одного. Пусть у него будет наставник из разработчиков или аналитиков, кто лучше знает проект. Помогите ему сгенерировать ssh ключ и подложить на сервер для снятия логов. Да, вопросов будет очень много, но, отвечая на них, вы точно не потратите время впустую.
Шаг 3. Когда начинать автоматизировать
Вот прошло несколько недель или месяцев с прихода тестировщика. Он прижился на проекте, тестовая документация в норме, баги быстро находятся и правятся. Не пора ли начать автоматизировать тесты? Ответ, скорее всего, нет.
Любая автоматизация тестирования в первое время требует больших затрат времени и сил. Чаще всего на активно развивающемся проекте их нет. Тем более, если тестировщик один. Поэтому, если вы уверены, что автоматизировать непременно нужно, то сразу же решите, какой процент времени и сил можно выделить под эту задачу в день, неделю или месяц. Если этого не сделать, то всегда будут находиться более приоритетные задачи и баги, и, в конце концов, ни одного теста вы не получите.
Если время было успешно выделено, то можно перейти к следующему этапу: выбору типа тестов, языка и архитектуры. Если опираться на пирамиду тестирования, то разумнее выбрать unit или rest-тесты.
Чаще всего unit-тесты пишут сами разработчики, но при желании этим может заниматься и опытный тестировщик. Однако если вы хотите впечатлить заказчика, то можно написать и UI-тесты, правда на их поддержку и выполнение уйдет гораздо больше времени, чем на остальные типы тестов.
Не стоит забывать про CI для тестов, потому что без окружения тесты будут лежать мертвым грузом. Так что, принимая решение об автоматизации тестирования на проекте, сразу же добавьте несколько часов работы DevOps-a.
Шаг 4. Курсы и конференции
Хотелось бы обсудить последний вопрос: это развитие тестировщика как специалиста. Развитие тестировщика важно для качества продукта. Чем больше специальных знаний имеет тестировщик, тем больше сценариев проверки он сможет придумать, больше ошибок предвидит и лучше проверит новые фичи.
В интернете есть множество инструкций по развитию QA-инженера. При желании такую инструкцию можно составить лично для человека, опираясь на его предпочтения. Способов развития есть множество. Лучшие, на наш взгляд – новые задачи, курсы и конференции.
Если с задачами все понятно, то в чем преимущество конференций и курсов? Курсы хороши тем, что сейчас туда добавляют много практики, а также создаются чаты, где можно найти собеседников своего уровня, которые чаще всего сталкиваются с такими же проблемами, что и проходящий курс тестировщик. Нужно следить, чтобы человек не начинал хаотично учиться всем направлениям одновременно, потому что в таком случае знания не успевают применяться на практике и остаются мертвым грузом.
Конференции же больше полезны для поиска новых идей. Полностью применить то, что услышала на конференциях, еще ни разу не получилось на практике, но новые идеи обязательно появлялись. Так что посмотрите, какие конференции идут в ближайшее время и отправьте на них тестировщика, он вернется с новыми идеями и готовым усовершенствовать процесс.
Пройдя все шаги, выстроив свою систему тестирования и выучив новое, станет ли человек готовым специалистом? Скорее да, чем нет. Правда стоит помнить, что путь этот не заканчивается никогда и всегда есть куда расти.
Успехов!
Комментарии