Войти
PapaHR · Mike Pritula Academy · Должности

QA-инженер (тестировщик): профиль должности, KPI и вопросы на собеседовании

QA (Quality Assurance — обеспечение качества) помогает команде замечать ошибки до того, как они навредят клиентам. Здесь собраны профиль тестировщика, ключевые показатели эффективности (KPI), вопросы для найма и план первых трёх месяцев.

Собрать профиль под свою компанию Открыть в PapaHR бесплатно →

Профили должностей, найм, адаптация и оценка — в PapaHR. Бесплатно до 25 сотрудников.

  1. Возьмите профиль ниже или соберите свой в конструкторе.
  2. В PapaHR из профиля собираются вакансия, план адаптации и цели на испытательный срок.
  3. Через 90 дней — оценка по тем же KPI и компетенциям.

Профиль должности

Зачем нужна должность

Выявлять риски и ошибки продукта до выпуска, снижая потери клиентов и расходы на исправления.

Результат через год

Ключевые действия клиентов покрыты проверками, ошибки воспроизводятся по описанию, а команда перед каждым выпуском видит результаты проверок и оставшиеся риски.

Место в структуре

  1. ПодчиняетсяРуководителю разработки или руководителю тестирования, если такая роль выделена.
  2. ПодчинённыеНет.
  3. ВзаимодействиеРазработчики: уточнение причин ошибок и проверка исправлений., Продакт-менеджер: ожидаемое поведение и важность ошибок для клиентов., Проджект-менеджер: сроки проверок и готовность к выпуску., Служба поддержки: ошибки клиентов и условия их возникновения., Дизайнер: состояния интерфейса и понятность сообщений об ошибках.
Ключевые зоны результата
  1. Ключевые действия клиентов покрыты проверками — Выполнение плана покрытия критических сценариев100% согласованных критических сценариев покрыты актуальными проверками.
  2. Проверки завершены к согласованному сроку — Выполнение плана проверок выпуска100% запланированных проверок завершены в срок.
  3. Ошибки можно воспроизвести по описанию — Доля воспроизводимых описаний ошибок100% проверенных описаний позволяют воспроизвести ошибку.
  4. Исправления подтверждены повторной проверкой — Доля исправлений, проверенных в срок100% доступных исправлений проверены в согласованный срок.
  5. Риски выпуска понятны команде — Выполнение плана заключений о готовности выпуска100% выпусков имеют полное заключение до решения о выпуске.
  6. Выпуски сохраняют работоспособность критических функций — Доля выпусков без критических ошибок100% наблюдаемых выпусков без критических ошибок.
Требования

Опыт: Опыт ручного тестирования веб-продукта от требований до проверки исправлений.

Формально: Профильный диплом необязателен; нужны понятные примеры проверок и описаний ошибок.

Нужно знать

  • Этапы разработки и роль тестирования в подготовке выпуска.
  • Граничные значения и разделение входных данных на группы.
  • Повторная проверка исправлений и проверка ранее работавших функций.
  • Программные интерфейсы (API) и способы проверки ответов.
  • Язык запросов к базам данных (SQL) на уровне чтения.
  • Разница между серьёзностью ошибки и срочностью исправления.

Должен уметь

  • Превращать требование в проверяемые сценарии.
  • Находить неоднозначности до начала проверки.
  • Фиксировать условия ошибки и собирать подтверждения.
  • Читать сообщения браузера и ответы программных интерфейсов.
  • Выбирать проверки с учётом риска и доступного времени.
  • Объяснять последствия ошибки понятным для бизнеса языком.
Компетенции — три уровня

Анализ требований и сценариев

Помогает найти пробелы в поведении продукта до затрат на исправления.

  1. Проверяет основной сценарий по описанию, задаёт вопросы о непонятных условиях.базовый
  2. Выделяет границы, неверные данные, состояния и зависимости между функциями.уверенный
  3. Находит противоречия между требованиями и помогает команде согласовать проверяемый результат.сильный

Выбор проверок по риску

Направляет ограниченное время на ошибки, угрожающие оплате, данным и работе клиентов.

  1. Начинает с согласованных критических сценариев и сообщает о нехватке времени.базовый
  2. Меняет порядок проверок с учётом последствий ошибки и затронутых функций.уверенный
  3. Предлагает объём проверок выпуска и объясняет команде оставшийся риск.сильный

Разбор и описание ошибок

Сокращает время разработчика на уточнения и повторный поиск проблемы.

  1. Записывает шаги, данные, версию продукта и видимый результат ошибки.базовый
  2. Сужает условия воспроизведения и прикладывает полезные сообщения системы.уверенный
  3. Находит закономерности редких сбоев и отделяет проблему продукта от условий среды.сильный

Системность проверок

Позволяет видеть реальную готовность выпуска и повторять важные проверки.

  1. Фиксирует результат каждой проверки и отличает пропуск от успешного прохождения.базовый
  2. Обновляет проверки после изменений и проверяет влияние исправлений на соседние функции.уверенный
  3. Убирает устаревшие проверки, закрывает пробелы и делает результаты понятными команде.сильный

Обсуждение качества с командой

Помогает принимать решения о выпуске на основании последствий и фактов.

  1. Описывает проблему спокойно, отделяет наблюдение от предположения.базовый
  2. Обосновывает важность ошибки последствиями для клиента и обсуждает варианты действий.уверенный
  3. Разрешает спор о готовности выпуска, фиксируя решение, ответственного и принятый риск.сильный

Улучшение процесса тестирования

Помогает предотвращать повторные ошибки и сокращать бесполезные ручные действия.

  1. Разбирает пропущенную ошибку и добавляет соответствующую проверку.базовый
  2. Замечает повторяющиеся причины пропусков и предлагает изменение процесса.уверенный
  3. Проверяет эффект улучшения по времени и пропускам, распространяет удачное решение.сильный
Конструктор

Соберите профиль под свою компанию

Отметьте, что делает этот человек у вас. Справа — готовый профиль: скопируйте его или откройте в PapaHR.

QA-инженер (тестировщик)

Выявлять риски и ошибки продукта до выпуска, снижая потери клиентов и расходы на исправления.

Функционал
  1. Уточнять ожидаемое поведение функций до начала разработки.
  2. Выделять сценарии, где ошибка остановит работу клиента или оплату.
  3. Составлять списки проверок новых функций и связанных изменений.
  4. Готовить тестовые данные и проверять готовность тестовой среды.
  5. Проверять интерфейс и обмен данными через программные интерфейсы.
  6. Проверять граничные значения, неверный ввод и права доступа.
  7. Описывать ошибки: шаги, условия, ожидаемый и фактический результат.
  8. Повторно проверять исправления и соседние функции после изменений.
  9. Передавать команде результаты проверок и риски перед выпуском.
  10. Дополнять проверки сценариями ошибок, с которыми столкнулись клиенты.
  11. Автоматизировать стабильные повторяющиеся проверки при наличии подходящих навыков.
  12. Проверять скорость работы под согласованной нагрузкой.
  13. Проверять удобство работы с клавиатурой и средствами чтения экрана.
  14. Проверять продукт на дополнительных устройствах и версиях браузеров.
  15. Сверять данные после переноса между версиями системы.
  16. Проверять переводы интерфейса, форматы дат и денежных сумм.
  17. Помогать поддержке воспроизводить редкие ошибки на обезличенных данных.
Открыть профиль в PapaHR

KPI QA-инженера (тестировщика)

  1. Выполнение плана покрытия критических сценариев — Критические сценарии с актуальными проверками / план сценариев × 100%. Ошибка: Считать наличие списка проверок доказательством их выполнения.вес 20% · месяц
  2. Выполнение плана проверок выпуска — Завершённые к сроку проверки / план проверок × 100%. Ошибка: Засчитывать недоступные проверки как успешно завершённые.вес 20% · месяц
  3. Доля воспроизводимых описаний ошибок — Воспроизводимые описания ошибок / проверенные описания × 100%. Ошибка: Исключать сложные ошибки из оценки ради красивого показателя.вес 15% · месяц
  4. Доля исправлений, проверенных в срок — Вовремя проверенные исправления / исправления к проверке за период × 100%. Ошибка: Засчитывать исправления как проверенные без повторного тестирования.вес 15% · месяц
  5. Выполнение плана заключений о готовности выпуска — Полные заключения до решения о выпуске / план заключений × 100%. Ошибка: Считать полным отчёт без непроверенных сценариев и открытых рисков.вес 10% · месяц
  6. Доля выпусков без критических ошибок — Выпуски без критических ошибок / выпуски за согласованное время наблюдения × 100%. Ошибка: Оценивать только тестировщика или скрывать ошибки ради показателя.вес 20% · квартал
Калькулятор

Посчитайте премию по KPI

Впишите выполнение каждого показателя в процентах и сумму премии при 100%. Веса можно поменять.

ПоказательВес, %Выполнение, %Вклад
Выполнение плана покрытия критических сценариев
Выполнение плана проверок выпуска
Доля воспроизводимых описаний ошибок
Доля исправлений, проверенных в срок
Выполнение плана заключений о готовности выпуска
Доля выпусков без критических ошибок
Итог по KPI
Премия
Сумма весов

Веса в примере — ориентир. Сумма весов должна быть 100%.

Вопросы на собеседовании

Оценочный лист

Проведите собеседование и получите итог

Ставьте оценку 1–5 после каждого ответа: итог посчитается по компетенциям. Страницу удобно держать на телефоне прямо на собеседовании.

Анализ требований и сценариев

Расскажите о требовании с неоднозначным поведением: что вы уточнили, какие проверки выбрали и что изменилось?

✓ Что услышать: Конкретная неоднозначность, личные вопросы, согласованное поведение и результат проверки.

⚑ Красный флаг: Проверял по собственному предположению, ожидаемое поведение ни с кем не согласовал.

Вспомните ошибку на границе допустимых значений: как вы выбрали данные, нашли проблему и подтвердили исправление?

✓ Что услышать: Обоснованный выбор значений, найденное отличие и повторная проверка.

⚑ Красный флаг: Называет термины, но не может восстановить свои действия.

Выбор проверок по риску

Вспомните выпуск, когда времени на все проверки не хватало: что вы проверили первым и как сообщили об оставшемся риске?

✓ Что услышать: Приоритет по ущербу клиенту, явные пропуски и согласованное решение.

⚑ Красный флаг: Выбирал только быстрые проверки и не сообщил об остальных.

Расскажите, когда новая информация заставила вас изменить план тестирования: что вы пересмотрели и к чему это привело?

✓ Что услышать: Новые данные, связь с риском, изменение проверок и наблюдаемый результат.

⚑ Красный флаг: Продолжал исходный план, хотя узнал об угрозе ключевой функции.

Разбор и описание ошибок

Расскажите об ошибке, которую разработчик сначала не смог повторить: что вы выяснили, добавили в описание и получили в результате?

✓ Что услышать: Проверка среды, данных и версии, уточнение шагов, подтверждённое воспроизведение.

⚑ Красный флаг: Повторял, что ошибка существует, без дополнительных условий и подтверждений.

Вспомните редкий сбой: как вы собирали факты, сужали условия и передавали результат разработчику?

✓ Что услышать: Последовательные гипотезы, проверенные условия и полезные подтверждения.

⚑ Красный флаг: Выдал предположение о причине за установленный факт.

Системность проверок

Расскажите об исправлении, затронувшем соседнюю функцию: какие проверки вы добавили и как убедились в результате?

✓ Что услышать: Связь функций, дополнительные сценарии и зафиксированные результаты.

⚑ Красный флаг: Проверил только исчезновение исходной ошибки, хотя знал о связанных изменениях.

Вспомните устаревший набор проверок: как вы его пересмотрели и что стало удобнее команде?

✓ Что услышать: Удаление лишнего, закрытие пробелов и понятный способ поддерживать актуальность.

⚑ Красный флаг: Добавлял новые пункты, не разбираясь с противоречиями и дублями.

Обсуждение качества с командой

Расскажите о споре по серьёзности ошибки: какие факты вы привели, какое решение приняли и что произошло после выпуска?

✓ Что услышать: Последствия для клиента, аргументы сторон, зафиксированное решение и результат.

⚑ Красный флаг: Ссылается на должность или авторитет вместо последствий ошибки.

Вспомните выпуск с известной ошибкой: как вы описали риск, кому передали решение и как отслеживали последствия?

✓ Что услышать: Понятное ограничение, ответственный за решение, план исправления и наблюдение.

⚑ Красный флаг: Скрыл ошибку или считает решение о выпуске исключительно своей ответственностью.

Улучшение процесса тестирования

Расскажите об ошибке, пропущенной к клиенту: что вы изменили в проверках и как оценили пользу изменения?

✓ Что услышать: Разбор причины пропуска, конкретное изменение и проверка его применения.

⚑ Красный флаг: Ищет виновного и ограничивается обещанием быть внимательнее.

Вспомните повторяющуюся ручную проверку, которую вы улучшили: что сделали лично и как изменились время или надёжность?

✓ Что услышать: Исходная проблема, собственные действия и сравнение результата до и после.

⚑ Красный флаг: Автоматизировал нестабильный сценарий, но не проверял пользу и стоимость поддержки.

Оцените хотя бы один ответ — здесь появится итог. ·
Вести кандидатов в PapaHR

Тестовое задание

Проверка оформления заказа на учебном стенде · 2 часа

Выдайте кандидату учебный стенд, тестовую учётную запись и краткое описание оформления заказа. Учебные правила: количество товара — целое положительное число; скидка применяется только при выполнении указанного условия; повторное нажатие кнопки не создаёт второй заказ. Кандидат составляет список проверок, выделяет самые рискованные, выполняет доступные проверки и оформляет найденные ошибки. В конце пишет короткое заключение о готовности к выпуску с непроверенными сценариями. Если ошибка не найдена, достаточно результатов проверок; придумывать её не нужно. Используются только тестовые данные и имитация оплаты; после двух часов кандидат сдаёт сделанное и отмечает ограничения.

Как оценить

  • Покрыты основной путь, границы количества и условия скидки.
  • Приоритет учитывает повторный заказ и неверную сумму оплаты.
  • Ошибки содержат шаги, условия, ожидаемый и фактический результат.
  • Выводы подтверждены наблюдениями, предположения отмечены отдельно.
  • Пройденные, неуспешные и невыполненные проверки различимы.
  • Заключение объясняет риски выпуска и ограничения проверки.

Готовый текст вакансии

QA-инженер (тестировщик) в [компания]

Проверять [продукт], находить ошибки и объяснять риски перед выпуском.

Задачи

  • Разбирать требования и уточнять спорные сценарии вместе с командой.
  • Проверять новые функции, исправления и связанные части продукта.
  • Описывать ошибки так, чтобы разработчик мог их повторить.
  • Поддерживать проверки основных действий клиентов.
  • Проверять API и данные в пределах своей задачи.
  • Сообщать о готовности выпуска и оставшихся рисках.

Требования

  • Опыт ручного тестирования веб-продуктов [нужный опыт].
  • Умение подбирать проверки и объяснять их приоритет.
  • Понятные описания ошибок и внимательность к условиям воспроизведения.
  • Навыки проверки API и чтения данных через SQL.
  • Умение обсуждать ошибки с разработчиками без поиска виноватых.
  • Автоматизация проверок будет преимуществом, если нужна в [команда].

Мы предлагаем

  • Зарплата: [зарплата] долларов, условия пересмотра: [условия].
  • Формат работы: [удалённо/офис/гибрид], город: [город].
  • График: [график], рабочий часовой пояс: [часовой пояс].
  • Команда: [состав команды], руководитель: [должность руководителя].
  • Оборудование и доступ к тестовой среде: [условия].
  • Обучение и развитие навыков тестирования: [условия].

В PapaHR этот текст становится вакансией с карьерной страницей и воронкой кандидатов.

План адаптации на 90 дней

До выхода

  1. Согласовать выход с кадровой службой (HR) и технической поддержкой (IT).HR
  2. Подготовить тестовую среду, учётные записи и минимально необходимые права.IT
  3. Выбрать первую функцию для проверки и назначить наставника.Руководитель
  4. Подготовить описание продукта, список известных ошибок и ближайших изменений.Наставник

Первый день

  1. Показать ключевые действия клиентов и последствия их отказа.Руководитель
  2. Показать путь изменения от требования до выпуска.Наставник
  3. Проверить доступы и выполнить основной сценарий в тестовой среде.Новичок
  4. Согласовать критерии критической ошибки и порядок сообщения о ней.Руководитель

Первая неделя

  1. Составить проверки первой функции и записать вопросы к требованиям.Новичок
  2. Разобрать полноту проверок и качество первого описания ошибки.Наставник
  3. Провести повторную проверку исправления вместе с наставником.Новичок
  4. Согласовать цели испытательного срока и правила расчёта показателей.Руководитель

30 дней

  1. Самостоятельно проверить изменение в закреплённой части продукта.Новичок
  2. Подготовить заключение: результаты, открытые ошибки и непроверенные сценарии.Новичок
  3. Проверить воспроизводимость описанных ошибок без устных подсказок.Наставник
  4. Разобрать трудности с окружением, требованиями и взаимодействием с разработчиками.Руководитель

60 дней

  1. Обновить проверки критических сценариев закреплённой части продукта.Новичок
  2. Провести проверки выпуска и согласовать оставшиеся риски.Новичок
  3. Разобрать ошибку клиента и добавить проверку против повторного пропуска.Новичок
  4. Оценить самостоятельность и точность приоритетов на реальных изменениях.Руководитель

90 дней

  1. Провести полный цикл проверки изменения без сопровождения наставника.Новичок
  2. Показать результаты целей и нерешённые ограничения тестовой среды.Новичок
  3. Проверить полезность одного улучшения процесса тестирования.Руководитель
  4. Обсудить результат испытательного срока и следующий участок ответственности.Руководитель

Цели на испытательный срок

  1. Освоить полный цикл проверки изменения.К 90-му дню самостоятельно провести один цикл: требования, проверки, ошибки, исправления, заключение.
  2. Подготовить проверки ключевых действий клиентов.К 60-му дню описать и выполнить все согласованные критические сценарии закреплённой части продукта.
  3. Описывать ошибки без потери условий воспроизведения.К 60-му дню наставник воспроизводит три выбранные ошибки по описанию без устных уточнений.
  4. Устранить один повторяющийся пробел в проверках.К 90-му дню внедрить одно согласованное улучшение и показать его применение на следующем изменении.

Карьерный путь

Младший тестировщик

Проверяет ограниченные изменения с помощью наставника, учится описывать ошибки и задавать вопросы.

Для перехода: Самостоятельно провести цикл проверки функции и объяснить выбранные сценарии и риски.

QA-инженер

Отвечает за проверки части продукта, уточняет требования и сообщает о готовности изменений.

Для перехода: Планировать проверки связанных функций, разбирать пропуски и помогать менее опытным коллегам.

Старший QA-инженер

Ведёт проверки сложных изменений, улучшает подходы и выбирает задачи для автоматизации.

Для перехода: Показать опыт координации проверок, наставничества и согласования приоритетов между командами.

Руководитель тестирования

Распределяет работу, развивает специалистов и согласует ресурсы для управления рисками качества.

Для перехода: Расширять ответственность за качество нескольких продуктов при появлении такой потребности компании.

Вопросы для встречи 1:1

  1. Какие критические действия клиентов сейчас проверены недостаточно?
  2. Где требования чаще всего заставляют вас угадывать ожидаемое поведение?
  3. Какие ошибки разработчикам трудно повторить по вашим описаниям?
  4. Что мешает вовремя получать версию с исправлениями для проверки?
  5. Какой риск последнего выпуска стоило обсудить раньше?
  6. Какие повторяющиеся проверки отнимают время без заметной пользы?
  7. Какой пропуск в проверках мы можем устранить следующим изменением?
  8. Какая поддержка нужна вам для самостоятельной проверки более сложной функции?

Ошибки при найме и управлении

  1. Оценивать тестировщика по количеству найденных ошибок.
    Как лучше: Оценивать покрытие рисков, качество описаний и полезность информации перед выпуском.
  2. Искать автоматизатора, когда некому разбирать требования и выполнять базовые проверки.
    Как лучше: Сначала определить нужный объём ручных проверок и отдельные задачи автоматизации.
  3. Передавать изменение на проверку только перед обещанным клиенту сроком.
    Как лучше: Подключать тестировщика к требованиям и заранее выделять время на исправления.
  4. Считать любую ошибку после выпуска личной виной тестировщика.
    Как лучше: Разбирать причины вместе с командой, учитывать изменения и согласованные ограничения проверок.
  5. Давать тестовое задание на рабочем продукте с реальными платежами.
    Как лучше: Использовать учебный стенд, тестовые данные и ограничение задания двумя часами.
HR в деньгах

Сколько стоит ошибка найма QA-инженера (тестировщика)

Тот же расчёт, что в PapaHR «HR в деньгах»: стоимость подбора плюс зарплата за месяцы, пока новичок работал в полсилы.

Один уход
За год

Новичок первые месяцы даёт примерно половину результата — эту половину зарплаты компания платит за обучение. В PapaHR расчёт идёт по вашим реальным уходам.

Вопросы и ответы

Чем QA-инженер отличается от тестировщика?

В вакансиях эти названия часто описывают одну роль, поэтому смотрите на задачи. Тестирование проверяет поведение продукта, а обеспечение качества также охватывает требования и улучшение процесса разработки. В небольшой команде эти задачи может совмещать один специалист.

Должен ли QA-инженер уметь программировать?

Для роли с ручными проверками важнее анализ сценариев, поиск ошибок и понятные описания. Написание кода нужно, если сотрудник создаёт или поддерживает автоматические проверки. Проверку программных интерфейсов и чтение данных стоит оценивать отдельно от навыков программирования.

Как оценивать работу тестировщика, если ошибок найдено мало?

Посмотрите, какие риски были покрыты и насколько понятны результаты проверок. Малое число ошибок может означать как стабильный продукт, так и поверхностную проверку. Сопоставляйте результаты с планом, сложностью изменений и обращениями клиентов.

Кто принимает решение о выпуске продукта?

Тестировщик сообщает результаты проверок, открытые ошибки и ограничения. Решение принимает назначенный руководитель с учётом риска для клиентов и бизнеса. Критерии остановки выпуска и ответственного стоит определить заранее.

Как установить цели QA-инженеру в небольшой команде?

Начните с критических сценариев, сроков проверки исправлений и качества описаний ошибок. Согласуйте план до начала периода, правила выборки и окно наблюдения за ошибками после выпуска. Показатель качества выпуска оценивайте вместе с командой; при отсутствии данных показатель не рассчитывайте.

Наймите, введите в работу и оцените — в одной системе

PapaHR бесплатна до 25 сотрудников: профили должностей, вакансии, адаптация, цели, встречи 1:1 и оценка.

Открыть профиль в PapaHR У меня есть аккаунт

Похожие должности