• Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Монолит/не монолит не имеет значения в разрезе UI тестов

    Всё равно сложнее «готовить» данные — больше зависимостей, больше условий и нюансов. Да и длительность ранов другая.

    Как научили разработчиков писать локаторы? )

    Как говориться: «вода камень точит». Медленно и упорно рассказываешь и напоминаешь. А ещё лучше — дать им возможность пописать тесты самостоятельно.

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Головна ідея статті, що автоматизація — має бути культурою розробки, кожен член команди розуміє навіщо їх пишуть і як ними користуватись. І вони стають скоупом реалізації будь якої фічі чи сервісу.

    Технічні деталі не надто принпипові, якщо немає культури. Все одно вони нікому не будуть потрібні, навіть якщо код ідеальний.

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Юніт тести запускаються при білді. Але є ще компонентні, інтеграційні тести — які ти запускаєш тільки після того, як в тебе сервіс збілдився.

    Але це більше відноситься до випадків, коли тести пишуть окремі «команди автоматизаторів» і не зрозуміло для кого вони їх пишуть

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Якщо приходить задача змінити функціонал чи росширити його, то задача змінити чи дописати тести йдуть по дефолту.

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Спасибо за фидбек. Постараюсь в следующей статье раскрыть детальней специфику тестирования GUI.

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

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

  • Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

    Сколько проектов вы уже сделали именно по этой схеме?

    Больше 10-15 проектов разных размеров. Все новые проекты у нас сразу же закладываются с такой схемой.

    Ещё крайне важный фактор — этап проекта. Если цель захватить рынок, а потом причесать продукт, то время разработки гораздо важнее качества продукта. Ну и функционал часто переделывается в таком случае.

    Согласен, что быстрее выйти с MVP будет без авто-тестов. Но, на моём опыте, потом причёсывать MVP никто не хочет, так как это уже работает и «давай-давай быстрее новый функционал» подавай. А ещё если нет человека или знаний, как это сделать — то ещё будут тратить пару месяцев на хайринг, онбординг и т.д. И тут начинается тех долг с самого начала приложения и новый продукт уже сразу становиться корявым. Потому нужен баланс, как обычно)
    Но если есть опыт и капасити, можно уже рядом с МВП писать тесты (хотя бы смоуки) и это даст возможность быстрее потом отрефакторить решение.

    Количество мануальных проверок, после которого стоит автоматизировать тоже сильно зависит от продукта, в первую очередь от качества кода разработки

    Согласен, что легаси-монолиты точно не будут окупаться так быстро. Тут важно было показать, что такие цифры реальны и в это стоит вкладываться. Даже UI компоненты (веб или мобайл) могут быть достаточно тестабельными, что бы их быстро авто-тестировать.

    Вы сами себе делаете локаторы или это задача разработчиков?

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

    Поддержал: Eugene O