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

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

В первые дни на новом проекте были лишь две документации, одна из которых отлично помогла узнать тестируемое приложение – это тест-кейсы и инструкции. Тест-кейсы были оставлены тестировщиком год назад, а последнее обновление документации было в 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% меньше, чем предыдущий тестировщик, который адаптировался без проекта, но с куратором.

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

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