С чего начать автоматизацию Джуну на проекте? 🤔

В комментариях на этот вопрос резонно указали: нужна ли автоматизация на проекте?

Всему свое время. Так же, как о наличии тестировщиков начинают задумываться тогда, когда продукт прошел фазу, в которой выясняется, что он действительно нужен и востребован, когда минимально работающий и необходимый функционал реализован, и пришло время задумываться о качестве.

То же самое и с автоматизацией: если у вас продукт на ранней стадии, динамично меняющийся интерфейс, контракты и логика, автотесты будут слишком часто ломаться, а их поддержка станет очень дорогой. Вообще, некоторое время разработчики могут самостоятельно поддерживать автоматизацию на уровне юнит-тестов. 🛠

Поэтому во многих случаях введение автоматизации тестирования может оказаться не рентабельным.

Существует и другая ситуация: продукт стабилен, но технологический стек очень устарел, иногда лучше в это дело даже не ввязываться. 😅

Однако есть и третий момент, когда, вроде бы, никто не против, и продукт в целом стабилен, но никто не готов выделять на это ресурсы.

Поэтому нужно определиться:
1. Готова ли компания вложиться в автоматизацию?
2. Готов ли ты вложиться в автоматизацию и нужно ли это тебе? 🤔
3. Насколько технологический стек продукта подходит для автоматизации?
4. Какие аспекты можно автоматизировать в принципе?

Положительный ответ на первый вопрос совсем не обязателен, если есть положительный ответ на второй вопрос, потому что, ну кто тебе запретит развиваться и овертаймить?

Теперь перейдем к третьему вопросу. Мое мнение: если у тебя проект с нераспространенным или очень старым стеком, нужно очень хорошо задуматься, нужно ли это тебе вообще. 🤔

Если нужно, проанализируй существующие инструменты для автоматизации того, что тебе необходимо, и насколько хорошо они поддерживаются. Если с этим дела обстоят плохо, то автоматизация — это не обязательно автотесты, это любая рутина: подготовка тестовых данных, анализ данных (например, логов), развертывание нужного окружения и т. д. — это тоже автоматизация. 🔄

Допустим — у тебя обычный веб и огромное желание. 💡
Я больше люблю бэк, так как он быстрее и стабильнее, поэтому буду говорить о нем. 🚀

📚 Первое, что стоит сделать, — это выучить хотя бы базовые знания по языку программирования, который тебе нравится. Сейчас есть ChatGPT, который может помочь ничуть не хуже разработчика, особенно на старте.

🔍 Второе — пиши простой и понятный код. Главное, чтобы ты его понимал, потому что возиться с автотестами будешь тоже ты, потом отрефачишь.

🐳 Третье — после того как ты написал хоть что-то рабочее, что приносит пользу, учись запускать это в каком-нибудь Docker.

🚀 Четвертое — отладил Docker — беги внедрять это в пайплайн.

От тестов есть польза только тогда, когда они работают, и чем раньше они будут выполняться, тем лучше. 😃 Лучше иметь один-два стабильных теста, которые уже сейчас работают в пайплайне, чем локально иметь десяток тестов, которые никто кроме тебя не может запустить и которые постоянно падают.

Не нужно писать миллиард тестов на одну ручку; пусть у тебя будет хотя бы по одному позитивному кейсу на каждый метод для смоков, потом уже будешь расширять.

И вот только после того, как это всё запустится и будет работать, прикручивай Allure-отчет, потому что, исходя из практики, чаще всего его смотреть будешь именно ты. Разработчиков и других больше интересует бинарный результат: прошли / не прошли. ✅

К моменту, когда ты всё это сделаешь, твой код обрастет такой большой портянкой вспомогательных функций, методов, логов и марок, что ты уже сам придешь к тому моменту, что пора это говно рефачить. 😂

В кратце как-то так. 😉
Ну, а если хочешь научиться писать код так, чтобы все это было поддерживаемо, читаемо, красиво и удобно. Делать отчеты, уведомления и запускать всё это добро в пайплайнах.

🎓 Приходи на обучение!

Ссылка на обучение 👇🏻

TG-сообщество | Обучение |Отзывы