Как тестировщики на проекте могут повышать квалификацию друг друга

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

Про неформальное общение

Для начала мне хочется указать на одну очень простую вещь – на общение. Ваша команда должна общаться между собой не только по рабочим вопросам, но и «обо всем на свете». Неформальное общение расслабляет человека и увеличивает шанс того, что при возникновении вопросов или проблем он придет к своим коллегам и попросит совета. А это своего рода прокачка 🙂

Я начала работу в «Лаборатории качества» совсем зеленым тестировщиком, имея за плечами теоретические знания и лишь немного практики. Конечно, в голове постоянно крутились вопросы «а как правильно?» и «а как лучше?». И вот мой первый проект, первый дефект… первая паника («как лучше описать дефект в баг-трекере?»). После написания черновика мне очень хотелось проконсультироваться с кем-то более опытным и понять, все ли хорошо, и не вернут ли мне разработчики мой дефект с грозными замечаниями. Как вы помните, мы говорим о распределенной команде, в которой все общение происходило в скайпе. Я зашла в наш проектный чат и поняла, что вопросы есть не у меня одной, а более опытные коллеги спокойно отвечают и дают советы. В ответ на свой вопрос я получила ответ и рекомендации, и это уже была пусть и небольшая, но прокачка моих навыков.

Меняем ответственных

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

Тестируемый продукт состоял из более чем 10 модулей, распределенных и проработанных тестировщиками. На выходе мы получали индивидуальный фронт работ для каждого члена команды. В таком распределении были свои минусы – тестировщики хорошо знали модули, которые они прорабатывали сами, и имели очень поверхностное представление об остальных модулях; из-за этого возникали проблемы с взаимозаменяемостью тестировщиков в том случае, если кто-то заболевал или уходил в отпуск.
Для избавления от пробелов в знании продукта мы стали каждые 2 недели рандомно менять ответственных за модули. Что нам это дало? Во-первых, у всех тестировщиков сложилась цельная картинка тестируемого продукта, все стали взаимозаменяемыми. Во-вторых, свежий взгляд на уже проработанные тест-кейсы повлек за собой редактирование чужих тест-кейсов «на ходу», так как функционал модулей продукта был связан между собой.

Испорченные тест-кейсы

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

Обучающие пятнадцатиминутки

Хорошо, с тест-кейсами и модулями было все понятно. Но спустя какое-то время, помимо регресса, мы стали получать и другие, более сложные задачи. Например, необходимо было тестировать интеграцию двух систем, а для этого требовались базовые знания SQL. Один из наших тестировщиков изучил основы SQL и приступил к выполнению задачи. Мы вновь столкнулись с отсутствием взаимозаменяемости, так как остальные тестировщики не были знакомы с SQL и не могли выполнять задачи по проверке интеграции. В итоге была написана подробная инструкция по работе с задачей и запросами к БД, проведена демонстрация для коллег, и записан видео-пример по работе с «боевой» задачей.
Таким образом, вся команда тестировщиков смогла познакомиться с основами SQL и получила возможность в любой момент взять в работу задачу по интеграции.

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


Основной идеей было брать небольшие темы, про которые можно рассказать в течение 15 минут. И конечно, речь шла исключительно о базовой информации, так как за 15 минут стать профи в какой-либо области невозможно. Темы добровольно распределялись между тестировщиками; каждый брал ту тему, в которой он хорошо разбирался. Далее готовилась небольшая презентация, а в пятницу утром мы созванивались, слушали докладчика и задавали вопросы.

Чем хороша такая активность? Докладчик не только дает новую информацию своим коллегам, но и сам прокачивается в ней (повторение – мать учения) при подготовке к презентации, а также во время ответов на вопросы своих коллег. И еще один огромный плюс – чаще всего выбранная тема применима к текущему проекту, и тестировщики получают не только теорию, но и возможность применить полученные знания на своем проекте и что-то улучшить.

Заключение

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

Об авторе

В IT сфере 6 лет. За это время приняла участие в разработке более 200 веб-проектов. На текущем проекте проведено около 1000 проверок базового функционала страхового ПО.

Поиск
Облако меток
api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)ПОИНТ (2)Приёмочное тестирование (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (2)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (2)тестирование мобильных приложений (1)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (2)
Получите совет