CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:
Собирается ли он?
Проходят ли автотесты?
Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.
Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту.
Автор: Хиллари Уивер-Робб (Hillary Weaver-Robb) Оригинал статьи Перевод: Ольга Алифанова
Я хотела провести рефакторинг некоторых примеров своих тестов, используя RestSharp и NUnit (например, тестов из этих статей). Для разовых акций это отличные примеры API-тестов, но когда вы их объединяете, то получаете неподдерживаемую свалку, нарушающую множество принципов разработки ПО. Если тест-код не соответствует тем же принципам и практикам, что и код приложения – на него легко махнуть рукой как на "ненастоящий код", но это тоже код, и он важен!
В мире автоматизации новичку ориентироваться довольно сложно. Приходится узнавать множество понятий, разбираться в особенностях существующих инструментов. Например, вот: Selenium, Selenide, Selenoid, Selendriod — что это, чем отличается? Да и можно ли их сравнивать?
Написал статью, чтобы помочь в этом разобраться. Кому интересно, добро пожаловать под кат!
Вышеописанные фазы тест-дизайна в реальности не происходят линейно. Они могут идти во всех направлениях, растягиваться на несколько релизов, и в них будет множество изменений и новых идей по мере интерпретации результатов тестирования.
Сделать это довольно легко, потому что в Postman-е есть
документация с примерами. Более того, эти примеры можно найти в самом инструменте на вкладке «Tests», они называются «Snippets».
Вот только если вы не знакомы с языками программирования, получившийся тест будет из разряда «Оу, магия!». А что, если вы хотите подкорректировать тест? Поменять под себя? Какую часть можно трогать, а какую оставить как есть?
В этом видео я возьму пример из сниппетов Postman-а, и подробно объясню, что означает каждая его часть. Теперь редактировать будет не страшно!
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Я долго боролся с собой, обдумывая сертификацию. Поначалу я думал, что "было бы круто сертифицироваться – это привлекло бы внимание ко мне" – держа в уме, что я был зеленым неопытным новичком. Затем я думал, что сертификация – это обязаловка, ее нужно иметь в резюме любой ценой – она покажет, что я потратил время и инвестировал в свое развитие. Сейчас я убежден, что только от меня зависит, признают ли меня опытным тестировщиком – и сертификация тут вообще ни при чем. Сегодня мы поговорим о такой устаревшей концепции тестирования, как сертификаты и связанное с ними марание бумаги.
Я довольно давно и много занимаюсь автоматизацией тестирования. И не понаслышке знаю, какую боль иногда доставляют новые версии чего угодно. Обновили XCode, вышла новая Selenium, придумали новый браузер (особое спасибо Microsoft за Edge и его драйвер), зачем-то вот вам еще один язык программирования… Все это автоматизатора приводит исключительно в радость от осознания собственной значимости. Ведь только он теперь способен запустить тесты на всем этом.
Менее опытные ребята, кто только постигают все азы и таинства работы с тестами, почему-то радость не испытывают. На нашем курсе по автоматизации ученики часто спрашивают про то, как работать с новыми версиями тех или иных составляющих стека. Об этом сегодня я и решил рассказать. Кому интересно — добро пожаловать под кат.
На конференциях и в неформальных беседах на работе нет-нет да и возникает разговор о важности работы QA-инженера и его роли в проекте. Это может быть и робкий вопрос коллеги-программиста «А, может, выпустим без QA?», и объёмный доклад.
Проблема, как мне кажется, связана с тем, что эффективность труда сотрудников отдела QA обратно пропорциональна количеству «срочных, внезапно возникающих» сложных задач. Назовём это «парадоксом немецкого сантехника», который получает зарплату, когда у него нет вызовов: чем меньше протечек и аварий на его участке, тем качественнее и эффективнее его работа. Но чем меньше у него вызовов, тем больше кажется со стороны, что он ничего не делает.
Автор: Мэри Дрейк (Marie Drake) Оригинал статьи Перевод: Ольга Алифанова
На этой неделе я помогала коллегам переносить существующие тесты WebdriverIO в Cypress. Если вы хотите знать, что такое Cypress, и чем он отличается от Selenium – посмотрите этот вебинар от Гила Тайара. Перенося некоторые тесты, я вспомнила, что существующий тест-набор использовал теги Cucumber для фильтрации того, какие тесты в каких окружениях прогоняются. Фильтрация тестов – полезная для нас фича, потому что на проде мы прогоняем только часть наших тестов. В имеющемся у нас сейчас фреймворке Cypress мы решили пользоваться стандартным подходом – писать тесты с использованием Mocha в качестве прогонщика, а не Cucumber. У Mocha есть способ фильтрации тестов с использованием паттерна –grep, но он сейчас не поддерживается в Cypress, и о его внедрении просят пользователи. Мне не очень-то хотелось использовать плагин Cypress Cucumber исключительно для использования функции тегов, поэтому я решила внедрить простенький обходной путь, который планирую предложить коллегам, пока мы ждем внедрения фичи от Cypress.
Автор: Хиллари Уивер-Робб (Hillary Weaver-Robb)
Автор: Виктор Славчев (Viktor Slavchev)
Автор: Энди Найт (Andy Knight)
Автор: Мэри Дрейк (Marie Drake)