Как с нуля внедрить систему управления тестированием
Осознайте необходимость внедрения TMS
Внедрение нового инструмента — ресурсозатратное дело, к которому нужно быть готовым. TMS требует время на перенос, форматирование и актуализацию тестовой документации под новые условия ведения, время на онбординг сотрудников и их привыкание к новому формату работы, а также финансовые вложения.
Принимая решение о внедрении TMS, следует понимать, для каких целей она нужна команде тестирования прямо сейчас, и уметь грамотно аргументировать решение. Стоит взвесить все «за» и «против», осознать объём работ по изменению процессов и преимущества, которые проект получит после запуска работ в TMS. Исходя из этого можно будет сделать вывод, стоит ли выделять ресурсы на внедрение новой системы.
Подробно о признаках необходимости внедрения TMS мы рассказали в предыдущей статье. Главная мысль — без TMS точно не обойтись, когда проект переходит на новую ступень развития и нуждается в стандартизации процессов, наведении порядка в документации и сборе подробной аналитики по работам тестирования.
А вот несколько признаков того, что работать вы пока можете и без TMS:
- тестирование проводится по однотипным или неизменяемым сценариям — большинство лендингов и малостраничных сайтов можно тестировать по несколькими чек-листам даже из блокнота;
- тестирование в команде еще не налажено как процесс, и на него не выделяются бюджеты;
- тестирование проводится сторонней командой — не стоит дублировать документацию в разных инструментах, достаточно по результатам запрашивать тестовые артефакты, в том числе тестовые сценарии. Это позволит быстрее завести документацию в собственную TMS, когда будет принято решение организовать внутреннее тестирование.
Объясните команде, почему с 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, то не было и метрик качества. Значит, не было объективного понимания того, как именно работают сотрудники, каков объем тестового покрытия, насколько «здоров» продукт.
