Привет, Хабр!
Меня зовут Алия, я – инженер-тестировщик с 5-летним стажем, в повседневном рабочем процессе занимающийся тестированием банковского приложения. И в местную «Вселенную» хочу войти с историей о том, как мне однажды удалось преодолеть трудную ситуацию, связанную с уходом из команды опытного сотрудника и приходом неопытного, предложить свое решение – и преуспеть.
Предыстория
На проекте нас, тестировщиков, было двое – понятно, стабильно; но спустя какое-то время мой коллега решил покинуть проект, и я осталась одна тестировать продукт. Ситуация разрешилась довольно быстро: новый сотрудник найден, и, казалось бы, поводов для беспокойства нет. Но на деле, как это нередко случается, с приходом нового тестера моя трудовая нагрузка увеличилась вдвое. Нужно было адаптировать пришедшего к самому проекту, каким бы он ни был – стараться всегда отвечать на вопросы, показывать, как выполнять ту или иную операцию в тестируемом программном продукте, предоставлять прозрачную и доступную для новичка информацию и параллельно успевать тестировать ПО.
Нужно было что-то делать, и такого рода ассимиляция была приказана быть быстрой, своевременной и продуктивной для каждого участника процесса. А получилось ли желаемое воплотить в реальность, и какие итоги я получила из опыта реализации микропроекта адаптации нового тестировщика, расскажу в конце этой статьи.
Первая фаза работ: Анализируем ситуацию
Первый этап. Планирование работ для нового тестировщика
На первых этапах решено проанализировать, какую информацию нужно предоставить и какие задачи необходимы для выполнения сотрудником, чтобы тот быстро вошел в курс дела.
Но, хоть это было и неверным решением (потому что задача была исполнена до зачатков мыслей о микропроекте), моим первым документом для нового сотрудника стала организационная инструкция, которая содержит следующие этапы:
Предоставить сотруднику необходимые доступы к инструментам, к документации, к таск и баг-трекинговым системам, к самому тестируемому продукту, к календарю звонков и конференций и прочее для работы в проекте;
Знакомство с командой участников проекта (ФИО сотрудника, должность и область ответственности);
Знакомство с инструментами: логирование времени, баг-трекеры, назначение задач в таск-трекере, Kanban-доска, инструменты для тестирования и прочее;
Инструктаж: как открыть тестовую среду программного продукта (тоже есть особенности в этом);
Начало работы с тестируемым программным обеспечением;
Действия, если тестируемое ПО не запускается;
Функционал в программном продукте, который часто нужно проверять в регрессионном тестировании;
Ответы по техническим вопросам с ПО;
Коммуникации при возникновении сложностей на проекте и в организационном процессе.
И всё же я вернулась в верное русло – было решено составить план задач по микропроекту, исполнителем которого является новый сотрудник, и после его наращивать нужными материалами, что помогут адаптироваться ему на проекте. Так, началом такого плана послужило создание задачи по адаптации тестера в таск-трекере. Здесь тестировщик должен был:
Получить доступы, которые нужны на текущем проекте;
Познакомиться с командой разработки;
Познакомиться с сотрудниками вне команды, которые необходимы во время тестирования приложения;
Узнать подробнее о методологии управления проектами, которая применяется внутри команды;
Получить инструктажи, руководство пользователя, требования, тест-кейсы и другие документы по работе с тестируемым программным продуктом;
Начать обучаться по приоритетным операциям в программном обеспечении, применяя инструкции, функциональные тест-кейсы;
Получить список тестовых данных для тестирования ПО;
Узнать об обходных решениях при отсутствии инструкций по работе с программой;
Начать тестировать программный продукт по приоритетному функционалу приложения, основываясь на функциональные тест-кейсы;
Составить тесты верхнего уровня по требованиям (без подробного описания шагов внутри тестов);
Актуализировать существующие тесты, если есть устаревшие;
Составить список вопросов куратору-тестировщику по работе с программным продуктом;
Составить список вопросов куратору-тестировщику и/или руководителю проекта по организационному процессу.
Важно было помнить: новый сотрудник при такой задаче на две-три недели обеспечен работой точно – но на этом адаптация тестировщика не заканчивается.
Второй этап: Углубление
Было решено усложнить работу сотрудника новой задачей с новыми активностями и с более глубоким погружением в проект. Поэтому тестировщику следовало:
Протестировать программный продукт, включая внутреннюю модульную интеграцию;
Составить тесты для модульной интеграции (а это уже описание шагов и вытекающее внутри теста);
Протестировать программное обеспечение, включая системную интеграцию между другими связанными ПО;
Составить тесты для системной интеграции;
Составить список возникших вопросов куратору-тестировщику в работе с программным продуктом;
Составить список возникших вопросов куратору-тестировщику по организационному процессу.
Но вместе с тем нужно было понимать: новый тестировщик со свежим взглядом может увидеть тонкости или изъяны в проекте по адаптации. Поэтому главное – опираться на развитие не только нового проекта, но и самого тестирования.
Третий этап: Полезный вклад от нового сотрудника
Здесь более погруженному и опытному тестировщику следует внести свой вклад и в тестирование программного продукта, и в проект по адаптации. Новичок был должен:
Составить недостающую или обновить существующую организационную инструкцию и различные материалы, которые помогают лучше понять тестируемое ПО;
Пройти опрос – какие тесты следует оптимизировать, для более качественного тестирования.
Итак, план для новичка составлен, но это только начало – ведь наш адаптационный проект нужно пополнять материалами. Получалось так, что задача для тестировщика есть, а информации для пополнения проектными знаниями того самого сотрудника – нет.
Вторая фаза работ: Все по сценарию
Конечно, я обратила в первую очередь внимание на инструктажи проекта. Но так ли они актуальны, и часто ли все мы заглядываем в мир «бесконечных букв»? А стоило бы.
Как истинный тестировщик, решила не погружаться в писанину томов, но сделать небольшие видео-уроки с инструкцией. Решено! Надо делать! Но быстро пришло осознание, что задача – не из простых. Кто его знает, может в видео-уроках меня унесет объяснять все подряд по цепочке? Поэтому здесь склонилась к составлению сценария, на который и буду в дальнейшем опираться.
В этих видео-уроках я записывала не то, как работать с программным продуктом, а какие действия следует предпринять, чтобы тесты прошли успешно (не баг, а фича).
Если мы вспомним про модульную интеграцию внутри приложения, то можно понять, что какие-то тесты зависят друг от друга – и что будет, если одно звено интеграции не настроено, то второе, связанное, уже не работает.
Соответственно и описывалось решение проблем, которые помогут устранить препятствия в тестировании: например, отсутствует нужная функция в графическом интерфейсе программы – и как эту функцию отобразить, какие шаги нужно предпринять, чтобы функционал появился.
Третья фаза работ: Документация
Не забыла и про сами инструкции к программному продукту. Для этого спросила руководителя проекта о существующих инструкциях – как выяснилось, имелись не все, а те, которые есть – почти устарели. Но будем работать с тем, что есть.
Файлов оказалось много, которые содержали информацию по разделам в тестируемом программном продукте. Некоторые документы совпадали друг с другом в разделах. Логично предположить, что такой материал следовало бы упорядочить между собой, потому что так удобнее адаптироваться новому тестировщику.
Создала страницу в Confluence, внутри страницы добавила таблицу с заголовками по функциональным областям разделов и добавляла инструкции в нужные ячейки таблиц. Как итог – документы выставлены на странице в Confluence (которую могут просматривать и другие участники команды) по нужным областям, соответствующие функционалу в инструкции.
Не стоило забывать и о проблеме отсутствия документации на часть функционала, и про почти устаревший статус материалов. Выход есть – это ответы на те вопросы, которые я задавала на протяжении своего опыта работы на проекте аналитикам в команде.
Четвертая фаза работ: Вопросы-Ответы
Помню свой первый год работы с тестируемым ПО, когда я каждый день задавала по 10 и более вопросов аналитикам и другим участникам и не участникам команды по работе с данным продуктом. Терпению их можно позавидовать. Логично подумать, что это уже второе решение в моем микропроекте: «Ответы на часто задаваемые вопросы».
Перед собой поставила задачу разобрать все заданные мною и предыдущего тестировщика вопросы и ответы от участников команды в переписке из мессенджеров и электронной почты. Создала еще одну страницу в Confluence, добавила туда заголовки областей по соответствующим функционалам в виде раскрываемого текста (чтобы новому тестировщику не пришлось листать страницу, в поиске нужного ответа на вопрос) и приступила к наполнению функциональных разделов.
Пролистывать всю переписку за 2,5 года было непросто. Но я выписала все вопросы и ответы на вышеописанную страницу Confluence. Конечно, участники команды и другие сотрудники проекта отвечали не на все вопросы, и с учетом моего опыта на проекте – решения прописывала самостоятельно, чтобы не образовывались вопросы без ответа.
Итоги и инициация
И завершающая фаза работ – это я сама, с полученными идеями, результатами и опытом. Не могу утверждать, что в микропроекте по адаптации новичка на проекте я собрала 100% всей информации. Но и сам программный продукт не стоит на месте, и, соответственно, ежеквартальное обновление заставляет регулярно апдейтить проект. Если не удается внести новые изменения в документ, то тестировщик беспрепятственно может задать интересующие вопросы более опытному тестировщику на проекте (т. е. мне).
Реализовав такой проект, мне удалось сэкономить время не только аналитиков и разработчиков, на плечи которых упала ноша отвечать на все возникающие вопросы, но и свое собственное – на более чем 90%. А это отличный показатель. Теперь я могу быть уверена, что участники команды выделят время важными задачам – и тем самым повысится и само качество проекта, ведь в первую очередь специалистов теперь никто не отвлекает.
На этом все. Надеюсь, что мой опыт и предложенное решение сможет помочь вашему проекту не «пострадать» (простите меня, новички!) от неопытности новых сотрудников. Всем удачи!
