W
/me достал попкорн и поглядывает на ggc
Size: a a a
2021 April 24
AB
Им бы замедлиться 😁
R
1. Разработчик пишет код, какие-то автотесты ломаются, но разработчик не может их поправить, потому что это зона ответственности автотестера. Задача уходит автотестеру.
2. Автотестер смотрит автотесты и выносит вердикт, что тесты правильные, а вот код бажный, возвращает задачу разработчику.
3. Так до тех пор, пока у них не сойдется.
2. Автотестер смотрит автотесты и выносит вердикт, что тесты правильные, а вот код бажный, возвращает задачу разработчику.
3. Так до тех пор, пока у них не сойдется.
AB
У автотестера должны быть чёткие критерии приёмки ещё до начала написания кода разработчиком.
PD
Ну, у нас сделано так:
1. Разработчик не может комитить, если тесты не проходят, но может их исправить.
2. QA просматривает исправленные тесты (скорее осмысленность и полезность сценариев, нежели сам код)
В таком случае пинг-понг взяться не может.
Исключение - сложные e2e тесты, которые на копии боевой только можно запустить. Но там стандартная бага заводится.
1. Разработчик не может комитить, если тесты не проходят, но может их исправить.
2. QA просматривает исправленные тесты (скорее осмысленность и полезность сценариев, нежели сам код)
В таком случае пинг-понг взяться не может.
Исключение - сложные e2e тесты, которые на копии боевой только можно запустить. Но там стандартная бага заводится.
R
Вот как раз не могу придумать как встроить автотестеров в команду именно по причине частых релизов (но не таких частых, а раз в месяц). Но каждый релиз добавляется куча фич и половина старых переделывается. Чтобы автотестеры покрывали новые релизы тестами и актуализировали старые придется пойти на затягивание процесса и растягивание всех сроков.
АМ
3. Мяч летит в сторону Ops'ов
PD
Ну, раз в месяц - это очень редкие релизы. Но вообще сначала стоит покрыть автотестами то, что важно для клиента и с того слоя, что реже меняется - тем самым ускорив подготовку релиза.
Вообще проработка стратегии обеспечения качества - нетривиальная задача для QALead/Architect
Вообще проработка стратегии обеспечения качества - нетривиальная задача для QALead/Architect
R
Не понятно как это решает описанную мной проблему. Разве что разработчик сам будет править тесты.
АЛ
Боже мой... Сколько понаписано-то... А ведь отвернулся на минутку ;)
В чем нетривиальность задачи обеспечения качества?
В чем нетривиальность задачи обеспечения качества?
R
Все таки разработчик сам исправляет тесты. Это другое дело. Изначально то тезис был, что разработчик сам не может протестировать свой код наилучшим образом.
АЛ
Друзья, определитесь:
- что за тесты (юнит? Интеграционные? Функциональные? etc?) вы пишите и зачем?
- что делают у вас qa и зачем?
- что такое качество, и за что вы боретесь?
- цель тестирования в подготовке релиза?
- что за тесты (юнит? Интеграционные? Функциональные? etc?) вы пишите и зачем?
- что делают у вас qa и зачем?
- что такое качество, и за что вы боретесь?
- цель тестирования в подготовке релиза?
R
Ну юнит то по любому должны сами разработчики писать
АЛ
Мы когда впервые делали автоматизацию тестирования столкнулись с тем, что увольнять 100 девченок тестировщиц никто не хотел. И правильно, девченки умные и симпатишные. ;) Нельзя таким счастьем разбрасываться потому что кто то, что то там понаписал. Мало ли ;)
АЛ
А когда переписывали чуть более чем полностью движок считавший достаточно шизофреничные бизнес правила - 4000 функ тестов спасли нас от неминуемого падения в пропасть боли и унижений.
C
🌟 Andy has reached level 11!
АЛ
В общем - тесты это хорошо (в разумных пределах). А хороший qa инженер - еще лучше!
S
блин...не смущайте. Не у всех, но есть. И я гарантирую, что так можно сделать. При соблюдении некоторых условий и соглашений
PD
Исправить тесты и придумать нормальное покрытие - разные вещи.
PD
Много параметров для оптимизации и нечёткость собственно понятия 'качества'.