Автор — Нина Полторакова (Агеева)
При написании статьи использовались материалы А.Смирновой, подготовленные в рамках конференции тестировщиков «Котэ»
Тестирование – очень динамичная сфера, которая постоянно развивается; каждый день появляются новые инструменты, материалы и подходы. Тестировщик – это «универсальный солдат», зачастую объединяющий в себе различные навыки: написание кода, управление ресурсами, владение основами дизайна и верстки, а также знания в более узких прикладных областях. Руководители проектных команд стараются повышать квалификацию своих ребят, отправляя их на всевозможные курсы и тренинги. Но как быть со стажерами, с «проектными новобранцами»? Как правильно, а главное, чему именно нужно научить стажеров (особенно в распределенной команде), чтобы у них не пропал интерес к профессии, и чтобы это обучение принесло пользу не только «новобранцу», но и всему проекту? Об этом мы и расскажем в нашей статье.
Распределенная команда
У нас в компании все сотрудники: и закаленные проектами «универсальные солдаты», и совсем новехонькие стажеры – удаленные специалисты, и руководители проектов – управляют распределенными командами и выстраивают все процессы с учетом этого факта.
Обучение осложняется тем, что мы не видим наших стажеров, не можем пообщаться с ними лично и наметить оптимальные пути развития. Однако, из любой ситуации есть выход, и мы нашли его в разработке несколько документов, способных максимально быстро и безболезненно погрузить наших новичков в проект, обучить их и отправить в большое плаванье по тестированию релизов и сложных задач.
Обучение: общая база и приоритетные направления развития
Основная команда нашего проекта занимается комплексной оценкой качества страхового программного обеспечения заказчика, а это непростой узконаправленный функционал, имеющий свои особенности. Именно этим особенностям нам и нужно обучать стажеров для того, чтобы они могли выполнять «боевые» задачи заказчика на достойном (и это важно!) уровне.
Не будем забегать вперед, подробно расскажем о том, что нам пришлось предпринять.
Сопоставление приоритетов проекта и навыков стажеров
Для начала нам предстояло выделить навыки, которые необходимы для успешной работы над проектом. Как? Здесь все достаточно просто – были проанализировали текущие задачи, и составлен подробный список навыков.
Мы определили четыре варианта приоритетов:
- Приоритет 1 – навыки, без которых выполнять текущие проектные задачи невозможно или очень сложно;
- Приоритет 2 – навыки и знания, которые требуются для более качественного выполнения задач, встающих перед специалистом на проекте;
- Приоритет 3 – навыки, которые являются не обязательными, но желательными для изучения, так как они найдут применение в текущих рабочих задачах;
- Приоритет 4 – навыки, которые в соответствии с текущими задачами не будут использоваться на проекте.
После этого были расставлены приоритеты по каждому навыку для каждого члена команды, включая стажеров. Приоритеты зависели от задач, которые предстояло выполнять новичкам. В нашем случае для всех новобранцев приоритеты были одинаковы (все они готовились на позицию ручных тестировщиков), мы выделили для них три навыка с Приоритетом 1:
- тест-дизайн (постигаем основные техники тест-дизайна, учимся писать тест-кейсы и чек-листы);
- ручное тестирование (изучаем скриптовое и исследовательское тестирование, мнемоники и эвристики);
- работа с баг-трекинговыми системами (учим новичка работать с используемым на проекте БТ, локализовывать и заводить дефекты).
Отметим, что эти приоритеты со временем могут меняться: все будет зависеть от задач, выполняемых нашими новобранцами, а также от направления, в котором они хотят развиваться.
По клику на картинку откроется полная версия.
Комментарии к рисунку:
По клику на картинку откроется полная версия.
Для дальнейшей работы со стажерами нам предстояло сопоставить навыки ребят с необходимыми компетенциями на проекте. Это было нетрудно – мы дали стажерам таблицу с навыками и попросили оценить их знания, исходя из определенных для проекта пяти вариантов оценки:
- отлично знаю – эксперт;
- средний уровень – успешно использовал на проектах;
- изучаю – прохожу курсы / изучаю самостоятельно;
- поверхностные знания – есть общее представление;
- совсем не знаю – нет знаний.
После того, как стажеры (да и основная команда заодно) заполнили информацию, все стало наглядно и понятно.
По клику на картинку откроется полная версия.
Основываясь на полученной информации, были составлены индивидуальные планы обучения (ИПР). Теперь, когда мы имели план развития и знали, чему и как учить новичка, можно было начинать погружение в проект.
Инструкция для стажеров и другие полезные документы
Для того, чтобы погружение прошло безболезненно, но в то же время не растянулось надолго, мы разработали документацию, помогающую оптимизировать процесс погружения и параллельного обучения стажеров.
Одним из ключевых документов стал план-инструкция «Салют, новобранец!», написанный в user-friendly формате. Основной ее принцип – сопоставление ответов на вопросы «что делать», «у кого спросить», «что посмотреть».
По клику на картинку откроется полная версия.
В инструкции мы по дням расписали, что именно необходимо изучить, где можно посмотреть информацию перед тем, как задать вопрос кому-то из коллег, и к кому и по какому функциональному блоку продукта можно обратиться. В качестве дополнительного был добавлен столбец «статус», который дал возможность оперативно отслеживать, на каком этапе находятся наши новобранцы.
SMART-задачи
Следующий важный документ, который помогает нам с обучением и погружением стажеров в особенности проекта, – это smart-задачи.
Очевидно, стоит подробнее рассказать о принципе SMART и о том, почему он нам так нравится. Вообще, SMART – это мнемоническая аббревиатура, которую используют руководители разных уровней при постановке задач своим подчиненным. Каждая буква аббревиатуры имеет свою расшифровку:
- Specific – конкретный. Ставя задачу, мы должны четко понимать, какого результата хотим достичь; результат должен быть однозначным и понятным всем участникам процесса – как стажеру, так и руководителю.
- Measurable – измеримый. Нам нужны такие задачи, которые могут быть измерены, а измеримость предполагает наличие критериев – измерителей, показателей выполнения.
- Attainable – достижимый. В данном случае определение «достижимый» мы бы заменили на «доступный» для выполнения определенным сотрудником со своим уровнем подготовки и квалификации. Эта характеристика как раз подходит нашим стажерам, ведь сразу нельзя «выпускать» новобранцев на серьезные «боевые» задачи.
- Relevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Чему научится стажер, если решит эту задачу?
- Time-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент может увидеть прогресс выполнения по задаче, скорректировать и направить новичка в нужное русло.
Что из себя представляют smart-задачи? Это кратко описанные задания для стажеров, которые необходимо пройти, написать расширенные тест-кейсы, создать и приложить тестовые сущности.
По клику на картинку откроется полная версия.
Почему нельзя давать новичку в работу сразу «боевые» задачи? Все довольно просто. Во-первых, клиент платит нам деньги за тестирование – соответственно, если новичок наломает дров, то платить клиенту будем мы. Во-вторых, боевые задачи более сложные, чем тренировочные. В-третьих, на тренировочных задачах новички чувствуют себя более комфортно, не боятся задавать вопросы и совершать ошибки, и это немаловажно.
Чем хороши smart-задачи? Тем, что они схожи с «боевыми» и предполагают разный уровень подготовки стажеров. Мы разработали порядка двадцати «смартов» и по мере погружения новичка в проект выдавали все более и более сложные задачи. Таким образом, наши стажеры смогли достаточно быстро разобраться с основными функциональными блоками тестируемого продукта и взять в работу настоящие боевые задачи.
Интересные подходы к обучению
В «Лаборатории качества» и у себя на проекте мы считаем, что тестирование – сфера творческая, поэтому помимо стандартного подхода к изучению базового необходимого для проекта материала и тренировки новобранцев мы разработали ряд своих интересных «упражнений», которые помогли новичкам. Речь пойдет о domain-specific мнемониках в исследовательском тестировании.
Что такое domain-specific тестовые мнемоники? Термин «domain-specific» означает, что данные мнемоники были созданы специально для конкретного проекта с учетом особенностей функционала тестируемого продукта.
Для своих новобранцев мы разработали мнемоники, с помощью которых начинающие специалисты запоминают не только правильную последовательность действий в системе, но и знакомятся с особенностями программного обеспечения. Кроме того, эти мнемоники также рассчитаны на разный уровень подготовки новобранцев.
Наши domain-specific мнемоники: КАДР, КИС, А-ПЯТЬ, СПИК и USTA.
Мнемоника USTA (наш «домашний» аналог всем известной MUTTI) хорошо подходит для первого знакомства с продуктом, пользователями, сервисами и переходами сущностей из одного состояния в другое. Достаточно простые КАДР и КИС направлены на знакомство с функциональным блоком по добавлению и редактированию контрагентов. Более сложная А-ПЯТЬ исходит из того, что стажер уже познакомился с основными функциональными блоками и готов к последовательному выполнению ряда действий. СПИК – самая сложная на текущий момент мнемоника, предполагающая уверенные знания продукта и выполнение ряда прикладных действий.
Почему важен нестандартный подход к обучению и погружению?
Итак, мы хотим еще раз напомнить, что даже в обучении и погружении стажеров можно использовать творческий подход, а не только гонять ребят по проектной документации (она, безусловно, нужна, но подчас слишком скучна и монотонна). Мы стараемся использовать интересные и нестандартные методы. В чем их польза? В том, что наши стажеры не только учатся работать с прикладной областью (изучая в интересной форме особенности исследовательского тестирования в целом и продукта в частности), но и менее чем за две недели становятся «универсальными солдатами» и выходят на настоящие «боевые» задачи, помогают основной проектной команде с тестированием релизов и хот-фиксов. Более того, они сами начинают писать инструкции, а также поддерживают тестовую документацию в актуальном состоянии!
