В последнее время все чаще слышу от коллег из других организаций о курсе на автоматизацию. Чаще всего это выражается в обучении за счет компании всех желающих мануальных тестировщиков автотестированию, т. е. стеку технологий для написания и поддержания автотестов. Помимо языка программирования (чаще Python или Java) изучают Git, Selenium или его аналоги, Jenkins и внутренние регламенты работы с автотестами. В нашей компании так же взяли курс на автоматизацию, в связи с чем возник вопрос — а что же будет с мануальными тестировщиками, откажутся ли от них совсем или будут стремиться сократить их количество?
На данный момент прямых ответов от руководств компаний нет, звучат стандартные фразы, вроде «Пока все остается как есть». Но есть ли профит от доучивания ручных тестировщиков до автотестера, и куда уведет мечта автоматизировать все процессы в тестировании? Расскажу на своем опыте.
Привет! А вот и вторая часть поста про принципы юнит-тестирования. Если в первой мы обсудили влияние тестов на разрабатываемые продукты и познакомились с теорией юнит-тестирования, то в этой обсудим некоторые практические моменты. Внутри поста — структура юнит-тестов, стили юнит-тестов, принципы рефакторинга, полезные советы для того, чтобы ваши юнит-тесты были эффективными и читаемыми, а также некоторые антипаттерны при написании тестов.
Ну и, конечно же, список источников, где можно получить дополнительную полезную информацию. В общем, начнём.
Автор: Корина Пип (Corina Pip) Оригинал статьи Перевод: Ольга Алифанова
Все мы хорошо знакомы с концепцией случайным образом падающих автотестов. Это тесты, которые, несмотря на отсутствие изменений в тестируемой функции, или падают случайным образом на одном и том же шаге, или делают это каждый раз по-разному. Разбор результатов таких тестов может быть непростым делом, и некоторые команды предпочитают просто прогнать тест еще раз, если он упал. Но действительно ли это лучшее решение? Вот что думаю я.
Привет! Меня зовут Владимир, я разработчик команды продукта «Сервис персонализации» в SM Lab. В этом посте я хотел бы рассказать (а в комментариях — обсудить) один очень важный и полезный инструмент разработчика — юнит-тесты.
Вы наверняка уже много про них знаете, особенно если они составляют часть ваших рабочих обязанностей. Информации в сети много, проблема в том, что она не всегда полная и недостаточно хорошо структурирована.
Мой рассказ будет состоять из двух частей. В этой части я расскажу, что такое юнит-тестирование и для чего это нужно, что такое покрытие тестами, как оно считается и какие есть подводные камни, рассмотрю подходы к изоляции в юнит-тестах и виды зависимостей, а также вопросы, связанные с эффективностью юнит-тестов.
Эта статья для всех – кто слышал про них, но не видел, кто приступает к написанию юнит-тестов, и кто их пишет уже давно. Надеюсь, каждый из вас найдет что-то полезное для себя.
При подготовке материала очень помогла книга Владимира Хорикова (@vkhorikov ) «Принципы юнит-тестирования». Рекомендую ее всем, кто хочет еще глубже погрузиться в эту тему.
Это видео - фрагмент нового курса Арсения Батырова "Автоматизация тестирования REST API на Java". На видео мы пишем наш самый первый API-тест на языке Java, используя одну из самых популярных библиотек для создания http-запросов - REST-assured. Вы можете убедиться сами, что это просто и почти любой может научиться этому.
Для прохождения курса не нужны никакие предварительные знания о работе с HTTP и API. Мы всему научим. Однако, нужны базовые знания любого языка программирования:
Работа с циклами (for, while) и условиями (if)
Работа с функциями - входные параметры, return
Основы ООП - что такое классы и объекты классов
Курс “Автоматизация тестирования API на Java” специально создан для быстрого погружения в навыки, необходимые тестировщику для успешного старта карьеры в автоматизации. Да и для ручного тестировщика понимание внутреннего устройства API и возможность быстро проверить свои гипотезы простым скриптом будут значительными плюсами в работе.
Приходите на наш курс и научитесь писать API-тесты на самом популярном языке программирования в автоматизации.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Вместо того, чтобы кликать при логине, можно авторизоваться программно и появиться в приложении авторизованным пользователем. В этой статье мы разберем этот процесс. Объяснения можно найти и в документации Cypress, однако если вы хотите узнать больше о всяких тонкостях, продолжайте чтение.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Недавно я разбирался с конфигурацией Cypress. Я обнаружил, что особенно трудно настраивать разные окружения, особенно для новичков. В этой статье я разобью конфигурацию на последовательность небольших шагов, и это поможет вам ориентироваться в теме.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
В предыдущих статьях серии о тестировании ориентированных на потребителя контрактов и Pact мы обсуждали CDCT, разобрались, как использовать Pact для поддержки CDCT, как автоматизировать процесс и сделать его частью процессов CI/CD, и посмотрели, что будет, когда на стороне потребителя меняются ожидания.
В шестой и последней статье мы посмотрим, как добавить в процесс CDCT новый сервис, и как это можно упростить при помощи подхода, который называется двусторонне направленным тестированием контрактов.
Предупреждение:двусторонне направленное тестирование контрактов существует только в Pactflow и недоступно в OSS Pact Broker.
Автор: Теодор Жеррад (Theodore Gerrad) Оригинал статьи Перевод: Ольга Алифанова
Если вы интересуетесь тест-автоматизацией, то в какой-то момент зададитесь одним (или всеми) из следующих вопросов – что такое Page Object Model (POM)? Важна ли тест-автоматизация? Надо ли этому учиться? Сколько времени это обучение займет? Если вы похожи на меня – а вы, скорее всего, похожи – то вы впадете в панику, быстро и последовательно спрашивая себя обо всем этом. Хоть я и не эксперт (пока что), я могу предложить свой взгляд на эту проблему. Хоть я и не могу явно ответить на все эти вопросы, я хотел бы поделиться рядом мыслей в этой статье.
