Home

Вышел выпуск рассылки за вторую половину сентября, его содержание доступно по ссылке.

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

Подписаться на рассылку можно по ссылке.

Обсудить в форуме

Ростов! Грядет осенний DX TECH TALK #4! 

Настал черед сурового QA meet up!

Если вам интересны технические доклады, общение со спикерами в неформальной обстановке под напитки и снэки, то добро пожаловать к нам на DX TECH TALK 12 октября в 19:00.

!Вход свободный!

Вас ожидают доклады:

In Sprint Testing. Как найти и обезвредить баги до релиза

Спикер: Сергей Федулов, QA Engineer, Devexperts (СПб)

Поговорим о том, что собой представляет In Sprint тестирование, при каких условиях возможно его проведение, и какие преимущества дает этот метод всем участникам процесса: разработчикам, команде тестировщиков и заказчику.

Гонки по граблям

Спикер: Борис Кириллов, Senior Software Developer, Devexperts (СПб)

Разбираем проблемы автоматизированного тестирования асинхронных приложений и пути их решения.

Автор: Эран Кинсбрунер (Eran Kinsbruner)

Оригинал статьи: https://mobiletestingblog.com/2017/08/25/optimizing-mobile-test-automation-across-the-pipeline/

Перевод: Ольга Алифанова

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

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

Множество "хозяев" у одной и той же проблемы

Так как мы живем в мире Agile/DevQAOps, разработка кода автотестов – проблема не только QA, но и всех вообще. Тесты выполняются в процессе разработки, начиная от разработки как таковой и заканчивая интеграцией и пред/пострелизным тестированием.

Использование "умных меток" для ваших тестовых сценариев (авторизации), наборов тестов (приложение А) и типов (юнит, регресс) может быть хорошим шагом в сторону обретения контроля над вашими тестами.

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

Мы выбрали доклады с конференции, которые посвящены тестированию производительности.

1. Настраиваемое тестирование производительности, Евгений Ланцов, Deutsche Bank, Санкт-Петербург

2. Всевидящее око. Мониторинг нагрузочного тестирования с InfluxDB и Grafana, Андрей Пищулин, Перфоманс Лаб, Ижевск

3. Apache JMeter vs LoadRunner: на заре справедливости, сравнение инструментов нагрузочного тестирования, Максим Рогожников, Перфоманс Лаб, Ижевск

4. Нагрузочное тестирование: Нестандартные методы анализа потока данных в приложениях, Сергей Журин, Перфоманс Лаб, Москва

Автор: Пол Меррил (Paul Merrill)

Оригинал статьи: https://techbeacon.com/5-ways-simplify-your-automated-test-cases

Перевод: Ольга Алифанова

Поддержка автотестов может занимать много времени, как и понимание отчетности по ним. К счастью, эти процессы можно ускорить.

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

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

29 июня в Харькове прошла тринадцатая встреча Smart Club for Smart Talks, где специалисты по тестированию могли услышать два интересных доклада на темы: «Как узнать, когда пора автоматизировать и с чего начать» Марка Курченко и «HP LoadRunner: expectations vs reality» Игоря Колосова.

Первый спикер рассказал, чем отличается автоматизация от мануального тестирования.
О том, какой язык предпочесть, какие фреймворки выбрать, TDD, BDD, DDD, Selenium)
А также об SQL, REST, SOAP, HTML/CSS, GIT и прочем.

Второй докладчик поделился опытом использования линейки продуктов для нагрузочного тестирования от Hewlett Packard, рассказал о том, как менялось его мнение на разных стадиях знакомства с инструментарием и дал несколько полезных советов тем, кто возможно столкнется с HP LoadRunner.

Ниже вы можете ознакомиться с записями докладов:

Автор: эксперт по инженерным практикам в Альфа-лаборатории Асеева Анастасия.

Оригинальная публикация: https://habrahabr.ru/company/alfa/blog/331434/

Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.

Прежде чем начну рассказывать про сам selenium grid и все, что связано с ним, я хочу пояснить суть проблемы, которую мы пытались решить.

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline. 

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

Автор: Михаль Димек (Michal Dymek)

Оригинал статьи: https://michaldymek.me/postman-devoted-friend-api-testing

Перевод: Ольга Алифанова

Сидел я как-то раз, работал, и внезапно (ну, как обычно) один из наших проектных менеджеров возник передо мной с вопросом:

- Не можешь ли ты помочь с нашим внутренним проектом?

- Конечно, почему нет! – сразу же откликнулся я.

Я только начинал свой путь в QA, и многого еще не знал, но если опытный сотрудник просит твоей помощи, что еще остается сделать?

Он представил меня другим членам команды, и они рассказали мне о приложении, которое оказалось очень интересным. А затем произошло вот что! Оказалось, что фронтенд еще не готов, и поэтому тестировать придется через API.. и я задумался, а что такое API вообще, как мне это тестировать? И что еще хуже, они, судя по всему, думали, что этот вид тестирования – совершенно рутинная задача, и не особо вдавались в подробности. К тому же я сделал худшее, что можно сделать в этой ситуации – побоялся попросить советов и помощи.

К счастью, они прислали мне рекомендацию, какие инструменты лучше всего использовать для тестирования через API, а также полную документацию на продукт (в Swagger, с этим я тоже раньше не сталкивался). Инструментом был Postman. Поначалу я боролся с ним методом проб и ошибок, но затем наши отношения наладились. Теперь я благодарен за этот опыт – я люблю Postman и постоянно его использую. В этой статье я хочу показать вам, почему работать с Postman очень легко и выгодно.

Итак, начнем с самого начала.