ICL Services
Новости
14 апреля 2022
Новости

Готово!

Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook

Ok

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

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

Предыстория

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новости по теме

    Свяжитесь с нами

    Контакты Пресс-службы
    Телефон 8 (800) 333-98-70

    pr@icl-services.com

    Будьте в курсе новостей

    Подпишитесь на рассылку и будьте в курсе наших последних новостей

    Подписаться на рассылку
    Спасибо, что подписались на рассылку новостей! Адрес подписки успешно добавлен! Ok
    На сайтах icl-services.com используются cookie-файлы. Оставаясь на сайте, вы даете свое согласие на использование нами cookie-файлов. Если, прочитав данное сообщение, вы не согласны, просим вас покинуть сайт.

    Задать вопрос эксперту

    Ф.И.О*
    E-mail*
    Наименование организации*
    Должность*
    Телефон*
    Вопрос*

    Заказать звонок

    Ф.И.О*
    Контактный телефон*
    E-mail
    Компания*
    Наверх