Home

Автор: Алия Токарева, ICL Services

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

Предыстория

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

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

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

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

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

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

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

2. Знакомство с командой участников проекта (ФИО сотрудника, должность и область ответственности);

3. Знакомство с инструментами: логирование времени, баг-трекеры, назначение задач в таск-трекере, Kanban-доска, инструменты для тестирования и прочее;

4. Инструктаж: как открыть тестовую среду программного продукта (тоже есть особенности в этом);

5. Начало работы с тестируемым программным обеспечением;

6. Действия, если тестируемое ПО не запускается;

7. Функционал в программном продукте, который часто нужно проверять в регрессионном тестировании;

8. Ответы по техническим вопросам с ПО;

9. Коммуникации при возникновении сложностей на проекте и в организационном процессе.

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

1. Получить доступы, которые нужны на текущем проекте;

2. Познакомиться с командой разработки;

3. Познакомиться с сотрудниками вне команды, которые необходимы во время тестирования приложения;

4. Узнать подробнее о методологии управления проектами, которая применяется внутри команды;

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

6. Начать обучаться по приоритетным операциям в программном обеспечении, применяя инструкции, функциональные тест-кейсы;

7. Получить список тестовых данных для тестирования ПО;

8. Узнать об обходных решениях при отсутствии инструкций по работе с программой;

9. Начать тестировать программный продукт по приоритетному функционалу приложения, основываясь на функциональные тест-кейсы;

10. Составить тесты верхнего уровня по требованиям (без подробного описания шагов внутри тестов);

11. Актуализировать существующие тесты, если есть устаревшие;

12. Составить список вопросов куратору-тестировщику по работе с программным продуктом;

13. Составить список вопросов куратору-тестировщику и/или руководителю проекта по организационному процессу.

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

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

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

• Протестировать программный продукт, включая внутреннюю модульную интеграцию;

• Составить тесты для модульной интеграции (а это уже описание шагов и вытекающее внутри теста);

• Протестировать программное обеспечение, включая системную интеграцию между другими связанными ПО;

• Составить тесты для системной интеграции;

• Составить список возникших вопросов куратору-тестировщику в работе с программным продуктом;

• Составить список возникших вопросов куратору-тестировщику по организационному процессу.

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

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

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

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

• Пройти опрос – какие тесты следует оптимизировать, для более качественного тестирования.

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

Вторая фаза работ: Все по сценарию

Конечно, я обратила в первую очередь внимание на инструктажи проекта. Но так ли они актуальны, и часто ли все мы заглядываем в мир «бесконечных букв»? А стоило бы.

Как истинный тестировщик, решила не погружаться в писанину томов, но сделать небольшие видео-уроки с инструкцией. Решено! Надо делать! Но быстро пришло осознание, что задача – не из простых. Кто его знает, может в видео-уроках меня унесет объяснять все подряд по цепочке? Поэтому здесь склонилась к составлению сценария, на который и буду в дальнейшем опираться.

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

 Если мы вспомним про модульную интеграцию внутри приложения, то можно понять, что какие-то тесты зависят друг от друга – и что будет, если одно звено интеграции не настроено, то второе, связанное, уже не работает.

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

Третья фаза работ: Документация

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

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

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

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

Четвертая фаза работ: Вопросы-Ответы

Помню свой первый год работы с тестируемым ПО, когда я каждый день задавала по 10 и более вопросов аналитикам и другим участникам и не участникам команды по работе с данным продуктом. Терпению их можно позавидовать. Логично подумать, что это уже второе решение в моем микропроекте: «Ответы на часто задаваемые вопросы».

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

Пролистывать всю переписку за 2,5 года было непросто. Но я выписала все вопросы и ответы на вышеописанную страницу Confluence. Конечно, участники команды и другие сотрудники проекта отвечали не на все вопросы, и с учетом моего опыта на проекте – решения прописывала самостоятельно, чтобы не образовывались вопросы без ответа.

Итоги и инициация

И завершающая фаза работ – это я сама, с полученными идеями, результатами и опытом. Не могу утверждать, что в микропроекте по адаптации новичка на проекте я собрала 100% всей информации. Но и сам программный продукт не стоит на месте, и, соответственно, ежеквартальное обновление заставляет регулярно апдейтить проект. Если не удается внести новые изменения в документ, то тестировщик беспрепятственно может задать интересующие вопросы более опытному тестировщику на проекте (т. е. мне).

Реализовав такой проект, мне удалось сэкономить время не только аналитиков и разработчиков, на плечи которых упала ноша отвечать на все возникающие вопросы, но и свое собственное – на более чем 90%. А это отличный показатель. Теперь я могу быть уверена, что участники команды выделят время важными задачам – и тем самым повысится и само качество проекта, ведь в первую очередь специалистов теперь никто не отвлекает.

На этом все. Надеюсь, что мой опыт и предложенное решение сможет помочь вашему проекту не «пострадать» (простите меня, новички!) от неопытности новых сотрудников. Всем удачи!

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