Comments 6
Спасибо, интресно было почитать.
После прочтения сложилось впечатление, что чинили автотесты, а не QA-отдел) Но опыт интересный, спасибо что поделились.
Правильно поняла из контекста, на GO переезжали только интеграционные автотесты? Или Web-тесты тоже переписывали?
Посмотрев на наши инциденты и влияние автотестов на качество - вот тут возникает вопрос, как оценивали влияние автотестов, которые "лежат", на качество?
Дописываю просто сейчас вторую часть статьи, поэтому действительно слегка отошел от заголовка.) Благодарю за интерес.
Да, на go мы перевозили только тесты бэкенда. Фронтовой стек у нас живет несколько отдельно - это TS/JS, и это физически другая команда со своими проблемами и другим стеком, Go все-таки больше не про фронтенд.
"Влияние автотестов на качество" - это координация дефектов при инцидент-менеджменте, о чем как раз планирую написать. В рамках каждого разбора аварии на проду мы смотрели, почему наши тесты не реагировали на проблему в релизе - и обнаружили, что простые проверки работоспособности всех ручек сервиса в отрыве от бизнес-сценария нам ничего не дают. Т.е. ручки всегда отдадут 200 в таком тесте, в том числе, если сломается логика, а это - основная часть наших инцидентов.
Вкратце: мы когда-то потратили бюджеты сделали и использовали один фреймфорк который проходил некие заскриптованные сценарии, делал непойми что, выдавал "все красное" и не использовался при разработке, а теперь мы потратили бюджеты и используем другой. А еще наши КУА теперь пишут код вместо/те с разрабами.
Переформулируем некоторые вещи:
"Теперь разработчик не только видит, что покрыто тестами" - теперь разработчик видит код заскриптованного сценария который как вы считаете при определенных условиях выполняется и выдает некий результат.
"стало возможным делегировать команде разработки часть обязанностей тестирования в те моменты, когда QA становится узким местом" - разработчики создают коды подобных заскриптованных сценариев сами. Теперь заскриптованные сценарии пишут люди не имеющие к тестированию даже косвенного отношения.
"QA тоже стали подхватывать мелкие задачки из техдолга, до которых у команды разработки могли не доходить руки долгое время." - люди которых вы наняли как тестировщиков теперь делают чужую работу.
Да, кажется, после переформулировки смысл не потерялся, все верно.
Здесь во фразу "заскриптованный сценарий", как мне показалось, вкладывается какой-то негативный контекст, но технически под этим стоит понимать "автоматизированный бизнес-сценарий", прохождение которого критически важно для успеха релиза. Да, вне зависимости от того, кто его пишет, мы стараемся максимально приблизить его к реальности, иначе это все и в самом деле не релевантно использованию в продакшн (бессмысленно).
Что касается того, что разработчики могут писать тесты/тестировщики могут писать код - в последнее время популярна концепция, которая пережила большое количество дискуссий, что за качество отвечает не команда тестирования, а вся проектная команда. Поэтому нам не страшно то, что тесты у нас где-то пишут разработчики - так как стек теперь общий, тесты проходят ревью, а оставшиеся проблемы выявляются на этапе ручного тестирования. Действительно, очевидно, что разработчик имеет меньшую экспертизу в QA, и его тесты могут не охватывать какие-то хитрые сценарии, но мы стремимся автоматизировать для начала хотя бы какую-то базовую функциональность, и разработка вполне способна с этим справиться. Она в конце концов лучше всех знакома с оригинальной задачей.
То, что QA берут в работу небольшие задачи - это не практика, а скорее побочный эффект наших изменений. Разработка состоит не только из кодирования, есть еще цели мотивации и обучения, которых мы достигаем таким образом. QA-инженер, который в состоянии самостоятельно разобраться с проблемой в коде - лучше понимает, как работает его продукт, технически быстрее справляется с основной работой (написанием автотестов) и имеет высокую мотивацию для развития (как оказалось). Не соглашусь, что QA занимаются чужой работой - если тестировщик починил, например, подсчет покрытия тестами на проекте/задачу из техподдержки, то продукт в целом стал чуточку лучше, а это совпадает с общими целями всей команды, вне зависимости от роли конкретного инженера.
"Здесь во фразу "заскриптованный сценарий", как мне показалось, вкладывается какой-то негативный контекст"
Скорее все обстоит наоборот, во фразе "теперь разработчик не только видит, что покрыто тестами..." вкладывается слишком позитивный контекст. Тут претензии можно выставить и к "видит" и "покрыто" и "тестами". Вы сами писали чуть раньше про пример где "тестами" была "покрыта" некая часть, но как оказалось они были зеленые доже когда на самом деле не работало ничего. Так откуда уверенность что и в другом случае оно "покрыто"?
Можно сказать что мы тут пытаемся протестировать собственную речь тк используя те или иные термины мы подвергаем себя влиянию предубеждения "bias". Так уж вышло что все вокруг говорят про Test Automation хотя это не "Test" и уж тем более не "Automation". Это заскриптованные сценарии которые совершают некие действия в определенном контексте и выдают некий результат, который "зеленый или красный" должен обязательно быть интерпретирован человеком. То есть "тупой" инструмент, причем затратный.
Почему я тут распыляюсь вокруг этого? Потому что вокруг нас люди с другим контекстом в голове которые во фразе "Да у нас автотестами покрыта регрессия" слышат что-то свое. В том числе эти люди распоряжаются бюджетами на разработку и тестирование.
Как починить QA-отдел, или Ещё один переезд в Go