Comments 10
GitHub Actions — новое решение для тех, кто хранит код на GitHub. Очень современный и крутой, но пока что в документации остается немало "белых пятен".
Дока конечно там с нюансами, но какие "белые пятна" вас беспокоят?
Смысл статьи не очень понятен. Чем конкретно эти инструменты отличаются от не удаленной работы? Те же самые CI/CD, те же самые чаты, докеры и так далее.
Это просто инструменты автоматизации.
В заголовке 'удаленной', но статья совсем не про это. И к QA отношение имеет только Allure Test Ops и походу это есть его реклама. Однако, отмечу, что это действительно топовое решение для автоматизации ). А ещё добавлю, что с точки зрения CI - GitLab CI идеален вместе с интеграцией с кубером. Минусить не буду, но статья кликбейтная и бесполезная.
Из специфичных для удалённой работы только Codewithme. Ожидал увидеть в статье именно про специфику...
А давайте представим, что у тестировщика есть коллеги (ну вдруг), у которых эти инструменты уже используются.
должен взять Докер и засунуть в него тестируемую систему? Серьёзно?
Или быть готовым взять используемый в разработке образ и знать, что с ним делать в CI-системе.
Суть в том, что на месте тестировщика хорошо бы понимать, как эти штуки используются и быть готовым присоединиться к стану их пользователя, а не говорить "бред какой-то".
Конечно, история с самостоятельным подъемом прод-подобной CI-системы выглядит утопично, но вы ведь привели крайний случай. И тогда порядок действий должен выглядеть как "с коллегами предложить использовать докер и дженкинс".
И всё это не осилили сделать девопсы, которым за это немалые деньги платят, а тестировщик такой - хоба! - и сделал? Серьёзно?
Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".
Или осилили, а тестировщику непонятно, зачем в это лезть, ведь "девопсы за много денег" сами разберутся, пусть работают".
В нормальном случае, девопсы настраивают инструменты так, что у тестировщика не будет прав влезть своими неумелыми руками и все поломать, потому что он знает как продукт тестируется, но не знает про все остальные интеграции с внешними системами, откуда берутся ресурсы и кто за них платит и как их заказывать, и как все это выводить на продакшен.
Если же тестировщик все это знает, то его позиция называется тестировщиком весьма условна.
5 инструментов для удаленной команды Automation QA