Очень интересное решение! До сих пор я лично пользуюсь матрицей трассировки в xlsx-формате, которая генерируется автоматически на основе двух csv-таблиц. Csv-шки заполняются уже вручную. Первая содержит описание областей покрытия (чаще всего постраничное) сопоставляемое с требованиями. Вторя - это словарь покрытия, где каждое требование расписано в виде "синонимов", буквально отражающих названия БДД-сценариев из тестов.
Буквально неделю назад уволился с такой работы, где микроменеджмент и борьба с ветряными мельницами победили над здравым смыслом. И таймтракинг ради таймтракинга стал одним из пунктов почему я предпочел уйти.
Считаю, что QA - это таки и есть часть разработки. И в нормальной компании эволюционировать в программиста им не следует. Более того, по хард- скиллам мидл QA авто сравним с мидл лвл программиста или devops. Зачастую их заменяет при необходимости: на личном опыте и баги сам чинил и ci/cd с нуля настраивал. И спрашивается зачем свою сферу применимости сужать, если можно доказать свои компетенции и получать одинаковую по уровню з/п никуда не свитчась.
А чем собственно Postman не подошел? Ручные тестировщики с этим инструментом знакомы, и экспорт коллекции как раз таки осуществляется в формате очень похожим на вашу задумку, только json. Коллекцию затем можно запускать в оффлайн используя newman. Ну или скажем, другой готовый инструмент - httpYac, если Postman безопасники зарещают.
По сути ты делаешь импорт отчёта. И это тоже работает. Но есть нюансы. Я пол года назад полноценный адаптер Постмана для Test It написал на Node.Js. Постараюсь до конца 2024 года опубликовать. Задача не тривиальная.
Очень интересное решение! До сих пор я лично пользуюсь матрицей трассировки в xlsx-формате, которая генерируется автоматически на основе двух csv-таблиц. Csv-шки заполняются уже вручную. Первая содержит описание областей покрытия (чаще всего постраничное) сопоставляемое с требованиями. Вторя - это словарь покрытия, где каждое требование расписано в виде "синонимов", буквально отражающих названия БДД-сценариев из тестов.
Буквально неделю назад уволился с такой работы, где микроменеджмент и борьба с ветряными мельницами победили над здравым смыслом. И таймтракинг ради таймтракинга стал одним из пунктов почему я предпочел уйти.
Поэтому я стараюсь как можно скорее автоматизировать рутинные проверки.
Считаю, что QA - это таки и есть часть разработки. И в нормальной компании эволюционировать в программиста им не следует. Более того, по хард- скиллам мидл QA авто сравним с мидл лвл программиста или devops. Зачастую их заменяет при необходимости: на личном опыте и баги сам чинил и ci/cd с нуля настраивал. И спрашивается зачем свою сферу применимости сужать, если можно доказать свои компетенции и получать одинаковую по уровню з/п никуда не свитчась.
А чем собственно Postman не подошел? Ручные тестировщики с этим инструментом знакомы, и экспорт коллекции как раз таки осуществляется в формате очень похожим на вашу задумку, только json. Коллекцию затем можно запускать в оффлайн используя newman. Ну или скажем, другой готовый инструмент - httpYac, если Postman безопасники зарещают.
По сути ты делаешь импорт отчёта. И это тоже работает. Но есть нюансы. Я пол года назад полноценный адаптер Постмана для Test It написал на Node.Js. Постараюсь до конца 2024 года опубликовать. Задача не тривиальная.
По вашей же табличке и критериям, Test It во всём лучше получается, разве не так? Можете с ним сравнение прояснить?