Осторожно, новичок! Как сохранить качество тестирования с приходом нового специалиста

Предыстория

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

Нужно было что-то делать, и такого рода ассимиляция была приказана быть быстрой, своевременной и продуктивной для каждого участника процесса. А получилось ли желаемое воплотить в реальность, и какие итоги я получила из опыта реализации микропроекта адаптации нового тестировщика, расскажу в конце этой статьи.

Первая фаза работ: Анализируем ситуацию

Первый этап. Планирование работ для нового тестировщика

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

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

1. - Предоставить сотруднику необходимые доступы к инструментам, к документации, к таск и баг-трекинговым системам, к самому тестируемому продукту, к календарю звонков и конференций и прочее для работы в проекте;
   - Знакомство с командой участников проекта (ФИО сотрудника, должность и область ответственности);
   - Знакомство с инструментами: логирование времени, баг-трекеры, назначение задач в таск-трекере, Kanban-доска, инструменты для тестирования и прочее;
   - Инструктаж: как открыть тестовую среду программного продукта (тоже есть особенности в этом);
   - Начало работы с тестируемым программным обеспечением;
   - Действия, если тестируемое ПО не запускается;
   - Функционал в программном продукте, который часто нужно проверять в регрессионном тестировании;
   - Ответы по техническим вопросам с ПО;
   - Коммуникации при возникновении сложностей на проекте и в организационном процессе.

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

Здесь тестировщик должен был:

1. - Получить доступы, которые нужны на текущем проекте;
   - Познакомиться с командой разработки;
   - Познакомиться с сотрудниками вне команды, которые необходимы во время тестирования приложения;
   - Узнать подробнее о методологии управления проектами, которая применяется внутри команды;
   - Получить инструктажи, руководство пользователя, требования, тест-кейсы и другие документы по работе с тестируемым программным продуктом;
   - Начать обучаться по приоритетным операциям в программном обеспечении, применяя инструкции, функциональные тест-кейсы;
   - Получить список тестовых данных для тестирования ПО;
   - Узнать об обходных решениях при отсутствии инструкций по работе с программой;
   - Начать тестировать программный продукт по приоритетному функционалу приложения, основываясь на функциональные тест-кейсы;
   - Составить тесты верхнего уровня по требованиям (без подробного описания шагов внутри тестов);
   - Актуализировать существующие тесты, если есть устаревшие;
   - Составить список вопросов куратору-тестировщику по работе с программным продуктом;
   - Составить список вопросов куратору-тестировщику и/или руководителю проекта по организационному процессу.

Важно было помнить: новый сотрудник при такой задаче на две-три недели обеспечен работой точно – но на этом адаптация тестировщика не заканчивается.

Второй этап: Углубление

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

• - Протестировать программный продукт, включая внутреннюю модульную интеграцию;
  
• - Составить тесты для модульной интеграции (а это уже описание шагов и вытекающее внутри теста);
• - Протестировать программное обеспечение, включая системную интеграцию между другими связанными ПО;
• - Составить тесты для системной интеграции;
• - Составить список возникших вопросов куратору-тестировщику в работе с программным продуктом;
• - Составить список возникших вопросов куратору-тестировщику по организационному процессу.
• 
  

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

Третий этап: Полезный вклад от нового сотрудника

Здесь более погруженному и опытному тестировщику следует внести свой вклад и в тестирование программного продукта, и в проект по адаптации. Новичок был должен:

• - Составить недостающую или обновить существующую организационную инструкцию и различные материалы, которые помогают лучше понять тестируемое ПО;
  - Пройти опрос – какие тесты следует оптимизировать, для более качественного тестирования.

Итак, план для новичка составлен, но это только начало – ведь наш адаптационный проект нужно пополнять материалами. Получалось так, что задача для тестировщика есть, а информации для пополнения проектными знаниями того самого сотрудника – нет.

Продолжение читайте в блоге ICL Services на Хабр.