Привет, Хабр!

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

Начало работ

Вторая часть описания аналогична первой, но изменения в том, что оценка скиллов имеет пометку «на повышение»:

• какие знания хотим проверить;

• в какой области знаний необходима проверка;

• какие инструменты нужно применить, чтобы проверить срез знаний и скиллов;

• какие участники аттестации требуются;

• калькулятор оценки по баллам и т. д.

Определение набора знаний тестировщика 2 категории

Так как тестировщик 1 категории имеет полный набор скиллов своего уровня и может продемонстрировать навыки выше текущей категории, то необходимо оценить и данный уровень знаний. Но дам небольшое отступление, что тестер 1 категории с повышенным набором скиллов – не равно инженер-тестировщик 2 категории со 100% количеством компетенций.

Поэтому на данном этапе оценивания необходимо определить ту область, которая будет считаться достаточной для повышения сотрудника именно в компании:

1. Адаптация на проекте;

2. Работа с первичными документами проекта (требования, ТЗ, постановки и т. д.);

3. Расширенные технические знания:

a. API-тестирование;

b. Запросы SQL.

4. Коммуникативные навыки;

5. Ситуационные вопросы (например, что будет делать тестировщик в ситуации, если программист отказывается исправлять баг, ссылаясь на фичу?)

Отсюда следует, что нужен план оценки среза повышенных скиллов аналогичный плану оценивания по текущему грейду. А значит самое время составить план плана!

План оценивания для повышения грейда

Области оценивания следующие:

1. Адаптация на проекте

2. Функциональное тестирование

3. Тест-анализ

4. Тест-дизайн

5. Технические навыки в тестировании

6. Поддержка коммуникаций

Проверки, которые можно отнести к оцениванию:

• Проведение устного теста для выявления шагов тестировщика для быстрой и качественной адаптации на проекте, проверка знаний тестировщика в функциональном тестировании, понимание тест-анализа и работа с первичными документами, знание и применение тест-дизайна на проекте, оценка технических навыков (например, методы тестирования API) и последнее – это коммуникативные навыки, которые имеют одну из ценностей, атмосферу внутри команды разработки;

• Проведение опроса экспертов по тем же областям оценивания, кроме тест-дизайна;

• Письменный тест технических навыков (например, написание SQL-запроса).

Подсчет результатов устных проверок

В первой части я привела примеры, как делается расчет баллов для устного тестирования и для опроса экспертов. В этой части подсчет баллов аналогичен.

Подсчет результатов письменных тестов

Так как в нашем пилотном проекте решили ограничиться временем проверки скиллов тестировщика в 2 часа (*на самом деле ушло на 15 минут больше*), то и письменный тест не должен являться большим, но и не стоит забывать, что тестировщик 1 категории, который претендует на повышение грейда, имеет опыт в тестировании более 1 года. Поэтому мы ограничились тремя SQL-запросами по степени сложности (легкий, средний, сложный) с ограниченным временем написания.

И подсчет баллов к этой части аналогичен с устной частью.

Не стоит путать данный подсчет как «100 / 3», потому что устная часть и практическая калькулируются в одной таблице, где как раз-таки вопросы о написании SQL-запроса входят в состав «20 вопросов» из примера выше.

Подсчет суммы баллов всех тестов

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

Заключение

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

Например, если тестер 1-го уровня прошел аттестацию текущего грейда со 100% результатом, а в оценке повышенного уровня (от суммы всей компетенции, а не её части) набрал  50%, то следует ли его повышать, при минимальном пороге 60%, или оставить на текущем грейде, но повысить зарплату на 50%? Или еще пример, по текущим знаниям у тестера набралось 90% и в знаниях на повышение – 30%, то недостающие до стопроцентного результата 10% отнимаются от 30% и прибавляются к 90% ((30% — 10%) + 90%)? Который покрывает пробел текущего грейда (чтобы по текущим знаниям был стопроцентный результат)?

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

Хочу выразить благодарность читателям за интерес к моим статьям. Я буду очень рада, если мои наработки станут полезными для вас!

P.S. Возможно я вернусь к написанию 3 части, где уже буду описывать какие улучшения были внесены в программу аттестации, и какой эффект мы получили.