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