Как с нуля внедрить TMS в работу команды тестирования

Если вы заметили тревожные признаки, указывающие на то, что пора внедрять TMS, может возникнуть логичный вопрос: как подступиться к выбору системы и что делать в первую очередь? QA-специалисты IT Test и TMS DoQA составили пошаговую инструкцию.

Внедрение нового инструмента — ресурсозатратное дело, к которому нужно быть готовым. TMS требует время на перенос, форматирование и актуализацию тестовой документации под новые условия ведения, время на онбординг сотрудников и их привыкание к новому формату работы, а также финансовые вложения.

Принимая решение о внедрении TMS, следует понимать, для каких целей она нужна команде тестирования прямо сейчас, и уметь грамотно аргументировать решение. Стоит взвесить все «за» и «против», осознать объём работ по изменению процессов и преимущества, которые проект получит после запуска работ в TMS. Исходя из этого можно будет сделать вывод, стоит ли выделять ресурсы на внедрение новой системы.

Подробно о признаках необходимости внедрения TMS мы рассказали в предыдущей статье. Главная мысль — без TMS точно не обойтись, когда проект переходит на новую ступень развития и нуждается в стандартизации процессов, наведении порядка в документации и сборе подробной аналитики по работам тестирования.

А вот несколько признаков того, что работать вы пока можете и без TMS:

Чаще всего любые нововведения в слаженной команде с устоявшимися процессами и рабочими традициями воспринимаются болезненно.

Расставаться со знакомым способом выполнять задачи непросто. Важно донести до членов команды, что TMS — инструмент, который позволит им лучше понимать проект и улучшать процессы.

Если тестировщики всегда работали прикладными средствами и использовали неподходящие инструменты, потому что специализированных не было, ввод TMS сделает их жизнь проще. Можно будет больше не «закручивать шурупы молотком», а применять специально созданный для тестирования сервис.

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

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

По итогу следует сформировать чек-лист, согласно которому вы будете выбирать подходящий инструмент. Особое внимание уделите целям работы с TMS — опираясь на них, вы позже оцените эффективность внедрения сервиса.

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

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

Хорошая идея уточнить у разработчиков системы, готовы ли они подстроиться и сделать что-то для вас индивидуально, если в TMS пока не хватает необходимого вам функционала. Менять впоследствии инструмент только из-за того, что вам не хватило какой-то мелочи, неудобно и трудозатратно. К тому же постоянные переходы с одного сервиса на другой не оценит ни одна команда.

Прежде чем принять решение о покупке конкретной системы, стоит сделать пилотный проект, то есть взять триал-версию подходящей под ваши требования TMS и посмотреть, соответствует ли она вашим ожиданиям, как вы сможете с ее помощью улучшить процессы. Живые данные при этом переносить в систему необязательно.

Перед этим проведите обучение и подготовку команды тестирования. Расскажите, почему вы выбрали именно эту TMS, какие у нее особенности и фичи, как именно она будет использоваться с учетом принятых в компании стандартов. Например, вы можете решить создавать смоук-тесты в формате чек-листов, а полный регрессионный набор тестов — в виде тест-кейсов. Объясните, как использовать теги, и как в этой системе организуется хранение данных: по проектам и спейсам, в папках и так далее.

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

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

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

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

Скорее всего, работая в Google Docs, трекерах, Notion и других неподходящих инструментах, тестировщики этого не делали. Какую-то тестовую документацию придется создавать заново. Это может быть неприятно, но это нужно пережить. Пока тестировщики будут заводить документацию в TMS, они приведут ее к единому стандарту, обновят, актуализируют. То есть сделают то, до чего не доходили руки.

После того, как вся документация окажется в TMS, работать с ней станет проще, так как кейсы будут представлены наглядно, а действия с ними можно будет выполнять легко и быстро.

Итак, работа в TMS запущена. Когда и как имеет смысл оценивать ее эффективность?

Информацию о том, как TMS изменила жизнь проекта, вы получите сразу после ее внедрения — как правило, сразу улучшается читаемость кейсов, и становится видно, каким объемом проверок покрывается каждая функция. Уже можно составлять матрицу трассировки и подсчитывать объём тестового покрытия. Теги и фильтрация дают понимание, сколько кейсов написано на каждую функцию.

Следующий объем данных будет получен после ближайшего прогона. Даже если это будет приемка какого-то отдельного функционала, можно будет в точности понять, какие именно проверки были выполнены, и достигнуть определенной степени уверенности в продукте.

Скорее всего, если раньше у команды не было TMS, то не было и метрик качества. Значит, не было объективного понимания того, как именно работают сотрудники, каков объем тестового покрытия, насколько «здоров» продукт.

Радикальный совет: попробуйте внедрить TMS, попользоваться ей пару месяцев, а после протестировать что-нибудь по старинке. Разница будет разительной.

Авторы статьи: Андрей Бракоренко, Евгения Федорова, Евгений Шейкин.

Попробуйте TMS DoQA, чтобы увидеть, как наша система увеличивает эффективность процессов тестирования. Мы предоставим бесплатный доступ к сервису без ограничений на 14 дней: полный функционал и любое количество тестировщиков на проекте.