Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

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

Автор: Анастасия Смирнова

Оригинальная публикация: http://quality-lab.ru/can-testers-improve-the-skills-of-each-other-on-the-project/

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

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

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

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

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

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

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


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

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

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

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

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

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


Кликните на картинку для увеличения

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

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

Заключение

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

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