Привет, Хабр!
На связи снова я – и после моих рассказов о сохранении качества тестирования с приходом новичка и бесконечном регрессионном тестировании в этой статье будет описан пилотный проект оценки тестировщика по его текущим знаниям.
Предисловия, или Размышления о том, как много тестировщиков в IT
Спойлер: очень много. Все они проходят курсы, чтобы войти в мир тестирования, но и проверка знаний новых специалистов заканчивается на моменте сдачи экзаменов на курсах и далее при собеседовании. А что дальше? Вспомнит ли тестировщик тот материал, который проштудировал во время обучения через 1 год? А через 3 года?
Если в компании не применяются мероприятия по аттестации сотрудника и/или сотрудник не применяет полученные знания в работе, то память тестировщика может очень сильно подвести. И более того, это может сказаться также и на качестве тестирования («и далее, как снежный ком…»). При этом проблема может возникнуть не только в отрицательную сторону, где тестер забыл весь пройденный курс обучения, но и в положительную – специалист повысил свои навыки и знания в тестировании, а руководители недооценили своего подчиненного (И как долго недооцененный сотрудник продержится в компании? А ведь это давит морально на эмплоера).
Поэтому такую проблему нужно решать.
В пилотном проекте, который я организовала совместно с
линейным руководителем, проводили аттестацию тестировщиков на начальных этапах
(опыт работы до 1 года), так как оценивать тестеров более высокого уровня – еще
рано, и при этом и сложнее.
Начало работ
Первым шагом работы на проекте аттестации стало составление плана:
какие знания хотим проверить;
в какой области знаний необходима проверка;
какие инструменты нужно применить, чтобы проверить срез знаний и скиллов;
какие участники аттестации требуются;
калькулятор оценки по баллам и т. д.
Всё это необходимо, чтобы удостовериться в не только в хард- , но и софт-скиллах. Исходя из этого, в качестве следующего шага наметили оценку текущих знаний тестера.
Определение набора знаний тестировщика 1 категории
Учитывая, что в нашей компании инженеры делятся на категории, нам следовало определить необходимый набор знаний и навыков тестировщика в начале карьеры.
Конечно, невозможно требовать от тестировщика, работающего в этой области до 1 года, большой спектр скиллов. А значит, требования нужно упростить.
Минимальный набор скиллов тестировщика 1-го уровня:
Составлять тесты и выполнять тестирование по готовым тестам;
Записывать результаты тестирования в соответствии с установленным планом тестирования на проекте;
Регистрировать инциденты, обнаруженные во время тестирования;
Формировать и предоставлять отчет по результатам тестирования (количество тестов успешных/не успешных);
Уметь работать в команде;
Иметь знания основ тестирования;
Понимать, что такое жизненный цикл не только разработки ПО (SDLC), жизненный цикл тестирования (STLC), а также участие в этих процессах;
Уметь работать с инструментами тестирования (TestRail, Zephyr, Test Management и т. д.);
Иметь возможности продемонстрировать навыки развития:
a.Трассировку требований;
b. Самостоятельное написание тестов на основе требований и опыта;
c. Составление тестов с применением техник тест-дизайна;
d. Проведение ручного API-тестирования;
e. Написание простых SQL-запросов;
f. Коммуникативные навыки для получения консультации в различных вопросах, связанные с тестируемым ПО.
Вывод: нужно составить план, по областям которых и будет проходиться оценка среза знаний
План оценивания по текущему грейду
Предметные области для оценивания:
Базовые знания тестирования;
Базовые знания о проекте, в котором участвует тестировщик:
a. Бизнес-разработка;
Тестирование:
a. Выполнение и понимание готовых тестов;
b. Специализация (по видам тестирования);
Тест-менеджмент;
Баг-репорт;
Отчетность.
Следовательно, по данным областям и следует составить список проверок. В нашем случае это было:
проведение устного теста;
проведение опроса экспертов (участников команды тестировщика);
оценка присланного материала (тест-кейсы, баг-репорты, отчеты и прочее).
Схема устного тестирования знаний
Ранее в моих планах было составить тест с несколькими вариантами ответа, но такая задумка не прошла успешно проверку руководителем, потому что оцениваемые тестировщики с легкостью сообщат ответы и другим тестерам, кроме того, верный вариант "гуглится" в интернете. Поэтому было решено задавать вопросы устно, а ответы уже оценивать по вероятности попадания в правильный ответ. Далее подсчет баллов происходит следующим образом.
Например, у нас имеется общее количество вопросов 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. Поэтому было решено опираться на оценку тест-кейсов и баг-репортов.
Критерии, которым должны соответствовать объекты тест-кейсов и баг-репортов:
Заголовок – важная часть. Поэтому в нем должен указываться функционал, который тестируется, локация, переменные или атрибуты (если они есть). Сам же заголовок должен иметь логический вид, краткость и полноту. Это делается для того (в случае баг-репорта), чтобы разработчик не тратил время на понимание баг-репорта, а сразу по заголовку мог понять, что за проблема, в какой функциональности, где именно, и при каких условия и/или атрибутах возникает, и только для уточнения нахождения бага зашел в описание отчета.
Референсы – необязательный атрибут, который содержит в себе ссылки, наименование окружения, версию ПО и прочее.
Предусловие – этот критерий является дополняющим, и поэтому здесь указываются предварительные действия, приводящие к шагам тестирования, также обязательно следует указать локацию, возможно, примеры (если они используются). Предусловие должно иметь логичный и структурированный вид.
Шаги – более подробное описание теста или бага, где нужно указывать тестируемый функционал, локацию, примеры переменных или наименования объектов, которые используются при тестировании («важное составляющее шагов»). Аналогично с заголовком, шаги должны иметь логический и структурированный вид, в которых прослеживается последовательность действий одного функционала, без мешанины с другими тестами.
Ожидаемый результат – должен соответствовать требованиям, ТЗ и прочим документам, которые предоставляют аналитики после общения с заказчиком. Ожидаемый результат имеет локализованный характер и описан в окончательном виде.
Фактический результат (используется в баг-репортах, но не в тест-кейсах) – здесь указывается несоответствие с требуемым результатом, или, другими словами, «баг». Локация уже указана в ожидаемом результате, но, если локации полученного результата и ожидаемого отличаются, то следует указать (хотя отличий быть не должно). И последний критерий – фактический результат указывается в окончательном виде.
Аттачи – различные скриншоты, логи, настройки INI, файлы для загрузки и прочие приложения в зависимости от ПО.
Постусловие – как и предусловие, не является обязательным, но его следует использовать в случае, если необходимо удалить данные, что были внесены в базу данных, чтобы тест-кейс имел рабочий вид.
Комментарий – последний, дополняющий критерий, который содержит в себе различные уточнения и/или (в тест-кейсах и/или в баг-репортах), рекомендации по исправлению бага.
Подсчет таких материалов проводится следующим образом: 100 делится на количество составляющих в критериях (например, если заголовок имеет 5 составляющих, шаги аналогично 5 критериев, то 100/10).
Не стоит забывать, что оцениваемый тестировщик 1-го уровня не всегда пишет 100% идеальный тест-кейс или баг-репорт, поэтому в этом случае балл занижается:
Балл / 1,5 – за более-менее хорошее описание;
Балл / 2 – за плохое описание;
Балл / 3 – очень плохое описание;
Балл / балл – составляющее критерия не указано, хотя предусмотрено (например, тестировщик не указал локацию, где нашел баг).
Заголовок
Так была проведена первая часть пилотного проекта аттестации тестировщика по текущим знаниям.
И скажу, что самим тестировщикам понравилась аттестация. Хоть для них это и был стресс, сотрудники увидели, в каких моментах имеют пробелы в знаниях, а где-то получили идею для улучшения качества тестирования на своем проекте. И еще больше скажу: не только тестеры, но и аналитики увидели другой подход рабочего процесса, который повышает качество уже самого программного продукта.
Не спорю, что в этом проекте аттестации можно найти кучу замечаний, но на то и программа является пилотной, которая в дальнейшем будет оптимизироваться.
Спасибо, что прочитали первую часть статьи, вторая часть будет посвящена знаниям инженера для повышения грейда.