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

Если вы заметили тревожные признаки, указывающие на то, что пора внедрять 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.

Оцените объем работ по переносу тестовой документации в систему

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

Установите иерархию доступов к TMS

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

Перенесите в TMS тестовую документацию

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

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

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

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

Оцените эффективность внедрения TMS

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

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

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

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

Но после внедрения TMS «Я не понимаю, чем занимается тестирование» превращается в «У меня есть четкое представление о том, как именно тестирование обеспечивает качество продукта, и насколько продукт надежен». Открывается возможность делать выводы о продукте, работе команды и стоимости тестирования, исходя из видимости того, как тестирование осуществляется.

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

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