Идея добавления тестовых атрибутов напрямую силами AQA действительно интересная, но, на мой взгляд, слабо применима в условиях enterprise-проектов. В таких компаниях команды разработки и тестирования, как правило, разделены, и внесение изменений в кодовую базу (особенно фронта или монорепозитория) требует утверждения и ревью, на которое вряд ли кто-то согласится — не из вредности, а из-за процессов и приоритетов.
Как альтернатива — можно формализовать необходимость добавления таких атрибутов на этапе постановки требований. Например, на основании макетов или заранее подготовленных тест-кейсов закрепить требование на добавление подобных атрибутов как часть спецификации. В таком случае реализация ляжет на разработчика, и всё будет прозрачно и официально.
P.S.
Безопасно ли это?
Также из интересных причин, по которым не хотят внедрять подобный подход, которые я слышал - это "мы упростим работу ботам, которые парсят наш сайт"))
Не понимаю, к чему тут ирония насчет «больших» проектов и то что у других читателей они тоже есть, по моему совсем неуместно, и на ваш первый вопрос я ответил.
Что касается пункта «оценки ретеста задач, основанном на логировании времени на функциональное тестирование» - мы не основываемся на легировании времени, затраченного на функциональное тестирование, рекомендую ознакомится в 4 раз. Мы основываем оценку на артефактах тестирования, созданных в рамках функционального тестирования на qa стенде, а не на залогированном времени, в статье это прописано.
По поводу пункта с оценкой ДО функционального тестирования - в статье также описано (точка с оценкой по спецификации) - можно в 5 раз ознакомиться. Суть заключается в том, что нам достаточно верхнеуровневой оценки на данном этапе и что мы пробовали применить метод декомпозиции - но он себя, в нашем случае, не оправдал.
У нас более 8 продуктовых команд, и иногда еще релизятся проекты. Вначале все задачи на релиз (и проекты) тестируются изолированно у себя на стендах, чтобы найти и исправить все баги своего функционала. После этого (когда все баги исправлены, НТ и UAT, если надо, пройдены), все это добро со всех команд мержится в Release Candidate ветку и заливается на стейдж. Как раз на стейдж данная оценка и нужна, т.к. Релиз тестируется 2 недели всеми командами, которые подали задачи в него и данным командам необходимо учесть, хватит ли им ресурса на тестирование их задач в рамках определенного релиза. Также там проходит общее НТ, общий регресс, отлаживаются автотесты и т.д..
Вполне допускаю, да и сам встречал, что на небольших проектах не требуется такое усложнение и достаточно тестирования на одном стенде, после чего можно сразу в прод идти. Но для нашего кейса - использование Release Candidate branching оправдано, т.к. у нас много команд с различным функционалом и могут возникнуть мерж конфликты, а также всплыть неучтенные моменты, при разработке в разных командах фичей по смежному функционалу, а также есть другие интеграционные системы, которые тоже релизятся параллельно и без доп. тестирования тут не обойтись.
Спасибо за статью!
Идея добавления тестовых атрибутов напрямую силами AQA действительно интересная, но, на мой взгляд, слабо применима в условиях enterprise-проектов. В таких компаниях команды разработки и тестирования, как правило, разделены, и внесение изменений в кодовую базу (особенно фронта или монорепозитория) требует утверждения и ревью, на которое вряд ли кто-то согласится — не из вредности, а из-за процессов и приоритетов.
Как альтернатива — можно формализовать необходимость добавления таких атрибутов на этапе постановки требований. Например, на основании макетов или заранее подготовленных тест-кейсов закрепить требование на добавление подобных атрибутов как часть спецификации. В таком случае реализация ляжет на разработчика, и всё будет прозрачно и официально.
P.S.
Также из интересных причин, по которым не хотят внедрять подобный подход, которые я слышал - это "мы упростим работу ботам, которые парсят наш сайт"))
Спасибо за комментарий! Рад, что идея оказалась полезной!
Не понимаю, к чему тут ирония насчет «больших» проектов и то что у других читателей они тоже есть, по моему совсем неуместно, и на ваш первый вопрос я ответил.
Что касается пункта «оценки ретеста задач, основанном на логировании времени на функциональное тестирование» - мы не основываемся на легировании времени, затраченного на функциональное тестирование, рекомендую ознакомится в 4 раз. Мы основываем оценку на артефактах тестирования, созданных в рамках функционального тестирования на qa стенде, а не на залогированном времени, в статье это прописано.
По поводу пункта с оценкой ДО функционального тестирования - в статье также описано (точка с оценкой по спецификации) - можно в 5 раз ознакомиться. Суть заключается в том, что нам достаточно верхнеуровневой оценки на данном этапе и что мы пробовали применить метод декомпозиции - но он себя, в нашем случае, не оправдал.
У нас более 8 продуктовых команд, и иногда еще релизятся проекты. Вначале все задачи на релиз (и проекты) тестируются изолированно у себя на стендах, чтобы найти и исправить все баги своего функционала. После этого (когда все баги исправлены, НТ и UAT, если надо, пройдены), все это добро со всех команд мержится в Release Candidate ветку и заливается на стейдж. Как раз на стейдж данная оценка и нужна, т.к. Релиз тестируется 2 недели всеми командами, которые подали задачи в него и данным командам необходимо учесть, хватит ли им ресурса на тестирование их задач в рамках определенного релиза. Также там проходит общее НТ, общий регресс, отлаживаются автотесты и т.д..
Вполне допускаю, да и сам встречал, что на небольших проектах не требуется такое усложнение и достаточно тестирования на одном стенде, после чего можно сразу в прод идти. Но для нашего кейса - использование Release Candidate branching оправдано, т.к. у нас много команд с различным функционалом и могут возникнуть мерж конфликты, а также всплыть неучтенные моменты, при разработке в разных командах фичей по смежному функционалу, а также есть другие интеграционные системы, которые тоже релизятся параллельно и без доп. тестирования тут не обойтись.