Комментарии 18
Спасибо за статью! Довольно интересный подход.
а где размещали их? я потому что подумываю их привязать к системе контроля версий и там уже просто файликами на маркдауне размещать, и оттуда уже смотреть понравившимся просмотрщиком, но вот думаю как оно будет работать когда количество тестов выйдет за тысячу
Добрый день!
Спасибо за ваш вопрос.
В нашей компании был выбран специализированный инструмент для ведения тестовой документации - TestRail. В нем и храним тест-кейсы.
Видится, что, если есть необходимость поддержания большого объема тестовой документации, надо учесть возможность коллективного редактирования тестовой документации.
Такая возможность есть во многих специализированных системах, предназначенных для ведения и хранения тест-кейсов.
Здравствуйте, ооочень интересно, а про автоматизацию , что нибудь будет ??)))))
Вариант подойдёт,если докой пользуются те, кто хорошо знают ui продукта,а бывает разработчики(back) хотят пройти кейсы,но зачастую не знают как именно это силами ui сделать, а в кейсе не описаны подробности...
Если я не прав - поправьте)
Но идея классная, приму на вооружение!
Добрый день!
Спасибо за то, что прочитали статью и за ваши комментарии.
На мой взгляд, такая ситуация действительно возможна, если разработчики не знакомы с ui.
Если в команде так сложилось, что разработчики время от времени все равно читают тест-кейсы и проверяют что-то сами ручками, то, безусловно, стоит это учитывать и наполнять кейсы описанием. Согласна с Вами.
Хочу дополнительно отметить, что посыла статьи писать тест-кейсы без подробностей - не было. Имелось ввиду, что, если необходимо или вы не располагаете временем, то есть варианты:
остановиться только на названиях
емко сократить предложения в шагах (пример с авторизацией)
вынести шаги, не связанные с самой проверкой, в предусловия
Мы используем похожую структуру на проекте, деля функционал на модули. Очень удобно. А для описания работы с базовыми сценариями, вроде регистрации или проведения исходящего рубевого платежа, была создана отдельная папка с пошаговыми кейсами. Их потеря таким образом была минимизирована и правки всегда были в одном месте. Но сейчас мы все равно думаем перенести воспроизведение на ресурс общего доступа. Тогда с ним смогут работать не только тестировщики, но и другие члены команды.
Хорошая статья. Спасибо!
Спасибо было интересно узнать о вашем подходе! Мы используем Allure TO, но некоторые кейсы действительно очень сложны, но и система у нас очень сложная! Предложу коллегам ваш вариант, посмотрим что скажут!
С тех пор как я нашел Cucumber Studio (ранше Hip Test), считаю plain text документацию и TMS где описания тестов хранятсся в текстовой форме (а таких больше 99%) - пережитком прошлого.
В Cucumber Studio есть Gherkin Style BDD с возможностью выделять, переиспользовать и отслеживать общие шаги и последовательности.
пара иллюстраций
Систему можно попробовать самому, она принимает логин через гитхаб аккаунт.
Тест-кейсы по полочкам — как в библиотеке! Наводим порядок в структуре и содержании тестовой документации