В одной команде, да и в целой компании невозможно найти сотрудников с абсолютно идентичными знаниями. Кто-то знает больше, кто-то меньше; одни больше понимают в исследовательском и скриптовом тестировании, а другие мастерски владеют навыками тест-дизайна и умением грамотно разработать тест-кейсы. Практически каждый сотрудник чего-нибудь не знает, каждый желает подтянуть свои знания, но, к сожалению, не имеет времени на обучение вне работы. В своей статье я хочу на примере нашей распределенной команды рассказать о том, как можно постепенно прокачивать навыки, затрачивая минимум усилий.
Про неформальное общение
Для начала мне хочется указать на одну очень простую вещь – на общение. Ваша команда должна общаться между собой не только по рабочим вопросам, но и «обо всем на свете». Неформальное общение расслабляет человека и увеличивает шанс того, что при возникновении вопросов или проблем он придет к своим коллегам и попросит совета. А это своего рода прокачка 🙂
Я начала работу в «Лаборатории качества» совсем зеленым тестировщиком, имея за плечами теоретические знания и лишь немного практики. Конечно, в голове постоянно крутились вопросы «а как правильно?» и «а как лучше?». И вот мой первый проект, первый дефект… первая паника («как лучше описать дефект в баг-трекере?»). После написания черновика мне очень хотелось проконсультироваться с кем-то более опытным и понять, все ли хорошо, и не вернут ли мне разработчики мой дефект с грозными замечаниями. Как вы помните, мы говорим о распределенной команде, в которой все общение происходило в скайпе. Я зашла в наш проектный чат и поняла, что вопросы есть не у меня одной, а более опытные коллеги спокойно отвечают и дают советы. В ответ на свой вопрос я получила ответ и рекомендации, и это уже была пусть и небольшая, но прокачка моих навыков.
Меняем ответственных
Вернемся к нашей команде.
С самого начала проекта перед тестировщиками стояли следующие задачи: ознакомиться с документацией и продуктом, разработать тест-кейсы и прогонять их на каждом релизе, тестировать продукт с использованием реальных юзер-сторис.
Тестируемый продукт состоял из более чем 10 модулей, распределенных и проработанных тестировщиками. На выходе мы получали индивидуальный фронт работ для каждого члена команды. В таком распределении были свои минусы – тестировщики хорошо знали модули, которые они прорабатывали сами, и имели очень поверхностное представление об остальных модулях; из-за этого возникали проблемы с взаимозаменяемостью тестировщиков в том случае, если кто-то заболевал или уходил в отпуск.
Для избавления от пробелов в знании продукта мы стали каждые 2 недели рандомно менять ответственных за модули. Что нам это дало? Во-первых, у всех тестировщиков сложилась цельная картинка тестируемого продукта, все стали взаимозаменяемыми. Во-вторых, свежий взгляд на уже проработанные тест-кейсы повлек за собой редактирование чужих тест-кейсов «на ходу», так как функционал модулей продукта был связан между собой.
Испорченные тест-кейсы
Продолжая тему тест-кейсов, хочу поделиться еще одним лайфхаком, который вы можете использовать для совсем неопытных тестировщиков. В готовые тест-кейсы необходимо внести ошибки или удалить часть данных. Таким образом, начинающие тестировщики в момент прохождения тест-кейсов смогут самостоятельно прокачаться в доработке и правке документации «на лету», а также научатся смотреть «по сторонам» от прогоняемых тестов.
Обучающие пятнадцати минутки
Хорошо, с тест-кейсами и модулями было все понятно. Но спустя какое-то время, помимо регресса, мы стали получать и другие, более сложные задачи. Например, необходимо было тестировать интеграцию двух систем, а для этого требовались базовые знания SQL. Один из наших тестировщиков изучил основы SQL и приступил к выполнению задачи. Мы вновь столкнулись с отсутствием взаимозаменяемости, так как остальные тестировщики не были знакомы с SQL и не могли выполнять задачи по проверке интеграции. В итоге была написана подробная инструкция по работе с задачей и запросами к БД, проведена демонстрация для коллег, и записан видео-пример по работе с «боевой» задачей.
Таким образом, вся команда тестировщиков смогла познакомиться с основами SQL и получила возможность в любой момент взять в работу задачу по интеграции.
Тема с демонстрацией работы с задачей не оставила нас равнодушными: спустя какое-то время точно таким же способом один из наших тестировщиков научил всю команду работать с soapUI. Со временем эта активность и вовсе стала регулярной – каждую пятницу мы стали проводить обучающие пятнадцатиминутки. Мы создали таблицу и вписали туда все темы, в которых нам хотелось бы прокачаться.
Основной идеей было брать небольшие темы, про которые можно рассказать в течение 15 минут. И конечно, речь шла исключительно о базовой информации, так как за 15 минут стать профи в какой-либо области невозможно. Темы добровольно распределялись между тестировщиками; каждый брал ту тему, в которой он хорошо разбирался. Далее готовилась небольшая презентация, а в пятницу утром мы созванивались, слушали докладчика и задавали вопросы.
Чем хороша такая активность? Докладчик не только дает новую информацию своим коллегам, но и сам прокачивается в ней (повторение – мать учения) при подготовке к презентации, а также во время ответов на вопросы своих коллег. И еще один огромный плюс – чаще всего выбранная тема применима к текущему проекту, и тестировщики получают не только теорию, но и возможность применить полученные знания на своем проекте и что-то улучшить.
Заключение
Итак, мы рассмотрели следующие активности: смена ответственных на тест-кейсах, испорченные кейсы и обучающие пятнадцати минутки.
Думаю, вы убедились на наших примерах, что не всегда обучение сотрудников требует высоких временных затрат; даже небольшие активности могут принести огромную пользу вашей команде.
