Home

Автор: Алия Токарева, ICL Services
Оригинальная публикация

Предисловия, или Размышления о том, как много тестировщиков в IT

Спойлер: очень много. Все они проходят курсы, чтобы войти в мир тестирования, но и проверка знаний новых специалистов заканчивается на моменте сдачи экзаменов на курсах и далее при собеседовании. А что дальше? Вспомнит ли тестировщик тот материал, который проштудировал во время обучения через 1 год? А через 3 года?

Если в компании не применяются мероприятия по аттестации сотрудника и/или сотрудник не применяет полученные знания в работе, то память тестировщика может очень сильно подвести. И более того, это может сказаться также и на качестве тестирования («и далее, как снежный ком…»). При этом проблема может возникнуть не только в отрицательную сторону, где тестер забыл весь пройденный курс обучения, но и в положительную – специалист повысил свои навыки и знания в тестировании, а руководители недооценили своего подчиненного (И как долго недооцененный сотрудник продержится в компании? А ведь это давит морально на эмплоера).

Поэтому такую проблему нужно решать.

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

Начало работ

Первым шагом работы на проекте аттестации стало составление плана:

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

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

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

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

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

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

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

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

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

Минимальный набор скиллов тестировщика 1-го уровня:

1. Составлять тесты и выполнять тестирование по готовым тестам;

2. Записывать результаты тестирования в соответствии с установленным планом тестирования на проекте;

3. Регистрировать инциденты, обнаруженные во время тестирования;

4. Формировать и предоставлять отчет по результатам тестирования (количество тестов успешных/не успешных);

5. Уметь работать в команде;

6. Иметь знания основ тестирования;

7. Понимать, что такое жизненный цикл не только разработки ПО (SDLC), жизненный цикл тестирования (STLC), а также участие в этих процессах;

8. Уметь работать с инструментами тестирования (TestRail, Zephyr, Test Management и т. д.);

9. Иметь возможности продемонстрировать навыки развития:

a.Трассировку требований;

b. Самостоятельное написание тестов на основе требований и опыта;

c. Составление тестов с применением техник тест-дизайна;

d. Проведение ручного API-тестирования;

e. Написание простых SQL-запросов;

f. Коммуникативные навыки для получения консультации в различных вопросах, связанные с тестируемым ПО.

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

План оценивания по текущему грейду

Предметные области для оценивания:

1. Базовые знания тестирования;

2. Базовые знания о проекте, в котором участвует тестировщик:

a. Бизнес-разработка;

3. Тестирование:

a. Выполнение и понимание готовых тестов;

b. Специализация (по видам тестирования);

4. Тест-менеджмент;

5. Баг-репорт;

6. Отчетность.

Следовательно, по данным областям и следует составить список проверок. В нашем случае это было:

• проведение устного теста;

• проведение опроса экспертов (участников команды тестировщика);

• оценка присланного материала (тест-кейсы, баг-репорты, отчеты и прочее).

Схема устного тестирования знаний

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

Например, у нас имеется общее количество вопросов 20 с 4-мя ответами по степени градации, где высший балл за самый точный и полный ответ одного вопроса равняется 5 (100/20 = 5). Далее, эти 5 баллов делим на 4, чтобы определить разницу, на которую нужно уменьшать высший балл (5/4 = 1,25), затем минусуем (5 – 1,25 = 3,75), потом еще минусуем (3,75 – 1,25 = 2,5), и еще раз минусуем (2,5 = 1,25 = 1,25), где в результате выходит:

5 – самый высший балл за полный и верный ответ;

3,75 – балл ниже, потому что в ответе тестировщика были упущены ключевые определения;

2,5 – балл занижен из-за достаточно плохого ответа тестера на вопрос;

1,25 – балл за самый скудный ответ.

Отсюда находится и минимальный порог, где сумма самых низких баллов равняется 25 (1,25 * 20 = 25). Или вы сами можете установить минимальный проходной порог.

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

Опрос экспертов

Ранее эксперты писали свою оценку в специально отведенных полях на внутреннем портале компании. Причем часто оценка отображала очень скудный вид, так как экспертам необходимо написать все качества (софт-скиллы, хард-скиллы), которые он увидел в сотруднике. (а это попробуй вспомнить за весь год)

Помню, как однажды на звонке один из экспертов сказал мне: «на написание оценки ушло два выходных».

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

Этот вид оценивания облегчает работу не только самому эксперту, но и руководителю, который дает заключение аттестации, потому что получает более полное описание качеств тестера. Оценивающего участника (эксперта) назначают сами тестировщики, а дальше дело за малым – это назначить встречи на не более чем 30 минут.

Подсчет баллов происходит аналогично, но в некоторых моментах градация идет не «вниз», а «вверх», например, у нас есть 20 вопросов, 5 баллов – это минимальный балл, в вопросе есть 3 варианта ответа, соответственно: 5 / 3 = 1,67, где 5 + 1,67 = 6,67, далее 6,67+1,67 = 8,34 – таким образом получается, что 8,34 балла – это высший балл.

К такой градации можно отнести вопрос «Каким образом тестировщик проводит тестирование?».

Например, какой способ применяется при тестировании программного приложения: «Черный ящик», «Серый ящик» или «Белый ящик»? Стандартное, что можно потребовать от тестировщика 1 уровня – это «Черный ящик», а вот «Серый ящик» – это уже повышение скиллов, и 3,33 балла никак нельзя поставить в оценку, если 5 – высший балл (5 – 1,67 = 3,33).

Оценка присланного материала

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

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

Критерии, которым должны соответствовать объекты тест-кейсов и баг-репортов:

1. Заголовок – важная часть. Поэтому в нем должен указываться функционал, который тестируется, локация, переменные или атрибуты (если они есть). Сам же заголовок должен иметь логический вид, краткость и полноту. Это делается для того (в случае баг-репорта), чтобы разработчик не тратил время на понимание баг-репорта, а сразу по заголовку мог понять, что за проблема, в какой функциональности, где именно, и при каких условия и/или атрибутах возникает, и только для уточнения нахождения бага зашел в описание отчета.

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

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

4. Шаги – более подробное описание теста или бага, где нужно указывать тестируемый функционал, локацию, примеры переменных или наименования объектов, которые используются при тестировании («важное составляющее шагов»). Аналогично с заголовком, шаги должны иметь логический и структурированный вид, в которых прослеживается последовательность действий одного функционала, без мешанины с другими тестами.

5. Ожидаемый результат – должен соответствовать требованиям, ТЗ и прочим документам, которые предоставляют аналитики после общения с заказчиком. Ожидаемый результат имеет локализованный характер и описан в окончательном виде.

6. Фактический результат (используется в баг-репортах, но не в тест-кейсах) – здесь указывается несоответствие с требуемым результатом, или, другими словами, «баг». Локация уже указана в ожидаемом результате, но, если локации полученного результата и ожидаемого отличаются, то следует указать (хотя отличий быть не должно). И последний критерий – фактический результат указывается в окончательном виде.

7. Аттачи – различные скриншоты, логи, настройки INI, файлы для загрузки и прочие приложения в зависимости от ПО.

8. Постусловие – как и предусловие, не является обязательным, но его следует использовать в случае, если необходимо удалить данные, что были внесены в базу данных, чтобы тест-кейс имел рабочий вид.

9. Комментарий – последний, дополняющий критерий, который содержит в себе различные уточнения и/или (в тест-кейсах и/или в баг-репортах), рекомендации по исправлению бага.

Подсчет таких материалов проводится следующим образом: 100 делится на количество составляющих в критериях (например, если заголовок имеет 5 составляющих, шаги аналогично 5 критериев, то 100/10).

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

1. Балл / 1,5 – за более-менее хорошее описание;

2. Балл / 2 – за плохое описание;

3. Балл / 3 – очень плохое описание;

4. Балл / балл – составляющее критерия не указано, хотя предусмотрено (например, тестировщик не указал локацию, где нашел баг).

Заголовок

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

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

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

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

Обсудить в форуме