Рубрика «автоматизация тестирования» - 7

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

В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.

Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.

Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.
Читать полностью »

Автоматизация тестирования iOS-приложений с применением Calabash и Cucumber - 1

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

В этой статье я расскажу о том, как мы автоматизируем тестирование наших приложений (ICQ и Агент Mail.Ru), поделюсь нашими наработками в этой области и упомяну о проблемах, с которыми мы сталкиваемся.
Читать полностью »

Привет!

Когда VexorCI начинался, мы решили, что для начала использования не обязательно писать файл конфигурации. Мы сами пытаемся догадаться, что именно нужно для запуска тестов и постоянно учим сервис распознавать новые настройки. Но мир разработки очень разнообразен, поэтому некоторым проектам конфиги необходимы.
За последние пару месяцев к Vexor подключилось 100 проектов. Очень разных проектов с уникальными настройками. За это время мы много узнали о том, как готовить файлы конфигурации так, чтобы это было удобно нашим юзерам. В процессе мы пересмотрели наш первоначальный подход и хотим поделиться с вами нововведениями.
Читать полностью »

Привет! Время долгожданного поста про внутреннее устройство Vexor – облачного continuous integration для разработчиков, позволяющего эффективно тестировать проекты и платить только за те ресурсы, которые реально используются.

image
Читать полностью »

Приводим доклад Игоря Хрола, компания Wargaming, Минск, с конференции SQA Days 15.

Видео доклада:
vimeo.com/93944414

Презентация:
www.slideshare.net/slideshow/embed_code/33725306#

Читать полностью »

Всем привет! По моему мнению, каждый программист должен стремиться к автоматизации и оптимизации всего, что движется и еще нет. В этой статье будет рассказано о том, как автоматизировать рабочий процесс Ruby on Rails разработчика с помощью Ruby гема под названием Guard. Эта статья в первую очередь полезна Ruby разработчикам, но может пригодиться и другим.

image

Что такое Guard?

Читать полностью »

Зачем разработчикам писать автотесты? С таким же успехом их можно заставить класть плитку или вести бухгалтерию. Не барское это дело! Или, все-таки, барское?

Автотесты – барское дело

Читать полностью »

Прежде чем начать рассказ про наш очередной opensource-инструмент, давайте я поясню, для чего мы его сделали. Я довольно много общаюсь с коллегами-тестировщиками и разработчиками из разных компаний. И, по моему опыту, автоматизация тестирования ─ один из самых непрозрачных процессов в цикле разработки ПО. Посмотрим на типичный процесс разработки функциональных автотестов: ручные тестировщики пишут тест-кейсы, которые нужно автоматизировать; автоматизаторы что-то делают, дают кнопку для запуска; тесты падают, автоматизаторы разгребают проблемы.

Allure — фреймворк от Яндекса для создания простых и понятных отчётов автотестов [для любого языка]

Я вижу здесь сразу несколько проблем: ручные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам; ручные тестировщики не знают, что именно покрывается автотестами; автоматизаторы тратят время на разбор отчётов. Как ни странно, но все три проблемы вытекают из одной: результаты выполнения тестов понятны только автоматизаторам — тем, кто эти тесты писал. Именно это я и называю непрозрачностью.

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

Именно поэтому мы разработали Allure — инструмент, позволяющий внести прозрачность в процесс создания и выполнения функциональных тестов. Красивые и понятные отчёты Allure помогают команде решить перечисленные выше проблемы и начать наконец разговаривать на одном языке. Инструмент имеет модульную структуру, позволяющую легко интегрировать его с уже используемыми инструментами автоматизации тестирования.
Читать полностью »

Компания, в которой я работаю, разрабатывает ПО на заказ, в том числе мобильные приложения на базе Android и iOS. В связи с тем, что конкуренция в этом сегменте рынка довольно высока, тестировщики не только отвечают за соответствие конечного продукта спецификациям и ожиданиям клиента, но еще и поставлены в жесткие рамки по бюджету и срокам тестирования. Это побуждает нас исследовать новые инструменты и методы, которые позволили бы нам уменьшать затраты на тестирование и повышать качество продуктов.

Imagrium — это результат одного из таких исследований. Технически это Jython фреймворк для кросс-платформенного тестирования мобильных Android/iOS приложений с помощью распознавания изображений, написанный нашей компанией. Он представлен в виде рабочего PyDev проекта, который вы можете изменить под свои нужды. Код распространяется под MIT лицензией и доступен на Github. В этой статье я расскажу о принципах работы фреймворка и его устройстве.
Читать полностью »

Преамбула

Я работаю в компании, которая делает достаточно большое и, не побоюсь этого слово, громоздкое мобильное приложение с солидной для мобильного приложения историей в несколько лет и, соответственно с довольно солидным и монструозным кодом.
Поток пожеланий от заказчика разнообразен и обилен и в связи с этим время от времени приходится вносить изменения даже в те места, которые для этого, вроде как, не предназначены. Некоторые, возникающие при этом проблемы — регрессионные баги — доставляют время от времени немало сложных часов.
При этом, по тем или иным причинам на проекте существует лишь ручное тестирование и довольно внушительного количество тестировщиков, а довольно наивные попытки автоматизации оного остались лишь на уровне нескольких довольно тривиальных юнит-тестов на уровне «Hello world».
В частности — у отдела тестирования есть внушительный цикл тестов для поиска регрессии, который проводится достаточно регулярно и занимает приличное количество времени. Соответственно, однажды возникла задача как-то оптимизировать этот процесс. Об этом и пойдет речь.

Честно, я не помню, какие средства для автоматизированного приемочного тестирования я смотрел и почему они мне не подошли. (Буду очень благодарен, если кто-то в комментариях подскажет интересные варианты решения этого — наверняка я пропустил что-то очень стоящее) Одно могу сказать точно — так как наше приложение, фактически тонкий клиент — очень многие кейсы невозможно(ну или как минимум, я не знаю как) покрыть юнит-тестами и нужно что-то еще. Так или иначе было решено написать свою библиотеку для автоматизации приемочного тестирования.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js