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

Немного истории моей адаптации

В первые дни на новом проекте были лишь две документации, одна из которых отлично помогла узнать тестируемое приложение – это тест-кейсы и инструкции. Тест-кейсы были оставлены тестировщиком год назад, а последнее обновление документации было в n-ном году. В принципе, и всё на этом.

Со второй проблемой, которой пришлось столкнуться – это доступы до всех необходимых инструментов, пространств в Confluence, организационных инструкций, задач в Jira и до самой тестовой среды (руководителю группы тестирования и проектному руководителю пришлось сильно постараться, чтобы сотрудники с отдела безопасности не затягивали с разграничением прав доступа учетной записи).

Третьей трудностью оказалось само приложение, которое нужно тестировать. Так как программный продукт я видела впервые, то и вопросы участникам команды и руководителю группы тестирования не заставили себя долго ждать. Были инструкции, но их актуальность закончилась вместе с тест-кейсами. И поэтому изучение ПО “методом тыка” являлось самым актуальным на тот момент.

Изучить инструкции

Одна из первых задач в начале работы на проекте – это прочитать, изучить инструкции, которые предоставили аналитики. Доступ к тестируемому программному обеспечению ещё отсутствовал, и поэтому применить инструкции на практике не удавалось, а изучать скучные документы нужно (*плачет*). Так как было ограничение к тестируемому ПО 1,5 месяца, то и инструкции читались столько же. Соответственно, участникам команды каких-либо вопросов по работе с приложением задать невозможно.

Спойлер: после получения доступа к программному продукту наконец можно было применить прочитанные инструкции. И какое же было разочарование узнать, что руководства устарели (в смысле?).

Обновить тест-кейсы

Второй этап адаптации состоял в том, чтобы обновить тест-кейсы. Тестов достаточно много, и на их актуализацию ушел примерно год (если не больше). И не только из-за их количества, а также потому, что само ПО имела непростой интерфейс, модульную и системную интеграцию. Заданных вопросов аналитикам о том, как работает программа, наверное, было больше 10 в день, а ответ, в лучшем случае, можно было получить в течение 2 дней (да и казалось, что вопросы имели глупый характер, особенно, если они повторялись).

Сами участники команды обучали, как пользоваться тем или иным функционалом ПО (как бывает: «В одно ухо залетело, из другого вылетело»). И видеозаписей мало, потому что обучение происходило в очной форме, но были рукописные записки в тетради, к котором со временем приходило понимание. Продолжительность такого обучения фактически занимало около 4 часов свободного времени аналитиков от задач разработки. Хоть это и не было критично для жизненного цикла программного продукта, но ожидать именно этого «окна» требовалось минимум месяц.

Попытки самостоятельно изучить программу

Самостоятельное изучение программного продукта – это must have для любого тестировщика, который только-только приступил к работе. И чтобы была шпаргалка в понимании связей между внутренними и внешними компонентами программ, решила, что mind map – идеальное решение данной проблемы («Авось, там и тесты можно составить»), которое заняло около месяца работы.

С составлением mindmap приходило осознание связей программных модулей, и казалось, что есть продвижение в понимании ПО. Но новый функционал усложнял задачу, потому что нужно провести тестирование перед релизом (*голос Д. Куплинова*«Помогите…»).

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

Цели проекта адаптации нового сотрудника

Полученный мною в прошлом опыт адаптации длиною в ~1 год подтолкнул на создание проекта, который:

  • сократит период обучения и увеличит эффективность сотрудника за счет вовлечения в рабочую атмосферу не только команды, но и компании в целом,

  • сделает тестирование более качественным из-за хорошего понимания основ ПО и её интеграций,

  • и, вдобавок, уменьшит нагрузку аналитиков.

В планах было ускорить время внедрения сотрудника как минимум в 2 раза (т. е. сократить обучение до 6 месяцев).

Как адаптировался новый сотрудник

В первые дни по плану – предоставить все необходимые доступы, список которых я выписала отдельно в Confluence с пояснениями (необходимы на тот случай, если новый сотрудник задастся вопросом «А для чего нужны те или иные инструменты?»). Быстрое разграничение учетной записи сократило время с 1,5 месяцев до 1 дня, и поэтому в первый день тестировщик мог уже параллельно изучать инструкции, смотреть видео-уроки и пробовать выполнять шаги уже в программном приложении.

Не исключаю, что какие-то вопросы тестер задавал, но задавал он их мне, как куратору, а до аналитиков доходили лишь вопросы, относящиеся к бизнес-процессу, либо к бэкендовой части программы (таких вопросов было мало). Да и обращения ко мне не были частыми, потому что основная часть ответов находились на тех самых страницах Confluence. Моей миссией оставалось лишь создать задачу в Jira, расписать план выполнения работ и предоставить ссылки на пояснения.

Таким образом, по факту сотруднику потребовалось лишь 8 рабочих дней, чтобы понять минимальную и важную часть программы (модульная интеграция и системная интеграция), закрыть задачу адаптации в Jira и приступить к полноценному тестированию.

И хочется похвалить Валерия за то, что он нашел уязвимость в программе, на которую не обращали внимания аналитики (знающие программу вдоль и поперек) долгие годы.

Немного цифр

В этой аналитике я решила разделить результаты на 3 части:

  1. Адаптация одного тестировщика в первый месяц работы без куратора/опытного тестировщика) и без проекта адаптации;

  2. Адаптация одного тестировщика в первый месяц работы с куратором и без проекта адаптации;

  3. Адаптация одного тестировщика на проекте в первый месяц работы с куратором и с проектом адаптации.

(данные взяты из мессенджеров и прочих программ связи, где задавались вопросы и производились звонки)

Потраченное время аналитиков в первый месяц работы нового сотрудника на проекте в часах
Потраченное время аналитиков в первый месяц работы нового сотрудника на проекте в часах

Критерии достижения за период адаптации сотрудника с применением проекта

  1. Знаком с организационной работой заказчика;

  2. Знаком с командой проекта и другими лицами вне команды;

  3. Знает проект в целом включая модульную и системную интеграцию;

  4. Изучил актуальные требования;

  5. Просмотрел инструкции и видео-уроки по взаимосвязанным программным продуктам;

  6. На протяжении периода адаптации озвучил возникшие организационные вопросы и вопросы по проекту;

  7. Составил тест-кейсы по новому функционалу;

  8. Участвовал в регрессионном тестировании на тестовой среде ПО;

  9. Нашел два серьезных бага и составил баг-репорты.

Заключение

В результате хочется сказать, что адаптация нового сотрудника – это важная часть в рабочем процессе (вспоминается поговорка: «Как корабль назовешь, так он и поплывет»). Потому что именно от первых шагов будут зависеть ресурсы проекта. Здесь стоит вспомнить, как тяжело переключаться от одной задачи к другой; а вы представьте, как переключались участники команды, получая каждые 2 часа вопросы в мессенджерах.

В итоге (данные взяты из мессенджеров и прочих программ связи, где задавались вопросы и производились звонки):

  1. Новый сотрудник успешно прошел адаптацию за 8 дней быстрее (на 93,9%), чем ожидалось (6 месяцев);

  2. Сократилось время для ответов от аналитиков на 10,4% от ожидаемого;

  3. Сократилось время аналитиков на 96% в целом, потому что обучение проводилось с проектом и куратором;

  4. С применением проекта сотрудник задавал вопросы опытному тестировщику на 55% меньше, чем предыдущий тестировщик, который адаптировался без проекта, но с куратором.

На этом всё. Хочется сказать лишь одно: не бросайте нового сотрудника, который только-только пришел на ваш проект, на произвол судьбы. Стоит уделить ему внимание в самые первые дни, потому что таким образом ваш проект сократит расходы.

Огромная благодарность моим читателям! Вы вдохновляете меня всё больше и больше открывать мой писательский талант.

Комментарии (4)


  1. aqua__vita
    27.10.2022 09:35

    Проводил собеседования на проект и так же был наставником для новичков QA на проекте ( это был первый мой подобный опыт)

    Что хочется заметить:

    1. Если ты сам задавал неправильные вопросы на интервью или не ставил тестовые задачи, связанные с проектом, то велик риск потратить много времени на обучение
    2. Когда нет аналитика на проекте( так вышло, что он ушел, а я остался), то нагрузка на наставника вырастает в разы
    3. Не всегда актуальные кейсы и инструкции помогают новичку без каких-либо визуализаций: некоторым людям сложно понять схемы интеграций на словах и гораздо удобнее показать им блок-схему/ диаграмму для понимания процессов

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

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


    1. AliyaTokareva Автор
      27.10.2022 09:42
      -1

      Спасибо за комментарий :)

      У вас очень интересный опыт, особенно с интервью. Но, что делать куратору, если он не участвовал на собеседовании? Вот прям дали нового сотрудника такого каков он есть.

      Согласна с вами, что план адаптации должен быть индивидуален :)


  1. Mike-M
    27.10.2022 13:04

    В первые дни по плану – предоставить все необходимые доступы
    Не хватает пункта о времени, которое необходимо на настройку локальной среды тестировщика (операционная система, инструментарий и т. п.).

    он нашел уязвимость в программе, на которую не обращали внимания аналитики (знающие программу вдоль и поперек) долгие годы.
    Вот она, ценность свежего взгляда!

    Нашел два серьезных бага
    А если они отсутствуют, уволите? )


  1. AliyaTokareva Автор
    27.10.2022 13:36
    -1

    А если они отсутствуют, уволите? )

    Нет, в любом случае есть различные мелкие баги. Да и цель тестирования не состоит в том, чтобы найти как можно багов :)

    Не хватает пункта о времени, которое необходимо на настройку локальной среды тестировщика (операционная система, инструментарий и т. п.).

    Да, тут не учла, спасибо. На проекте не было особых настроек, потому что уже было все настроено, достаточно предоставить доступы в виртуалке и всё :)