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