Тестирование веб-сервисов *

В эпоху вселенского внедрения agile-методологий и Devops уже никто не сомневается в том, что регрессия должна быть автоматизирована. Особенно, если в компании идет речь о Continuous Delivery. Все кинулись хантить разработчиков автотестов, от чего рынок становится перегретым.

В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.

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

Первым на наши вопросы ответил «дедушка русского тестирования» Александр Александров. В этом посте своим мнением поделились: руководитель отдела тестирования в СКБ Контур Максим Захаров, Senior QA Engineer в Exadel, участник RSTQB Илья Вахрушев, тестировщик в Badoo Арсений Батыров и эксперт в автоматизации тестирования и тренер по инженерным практикам в Альфа-Лаборатории Анастасия Асеева.

Где учиться начинающим тестировщикам более-менее понятно всем: существует много статей, курсов, книг и мануалов. А вот что делать тем, кто вырос из джуна в мидла — непонятно. В преддверии конференции DUMP, мы решили спросить известных тестировщиков, что они посоветуют джуниорам, которые хотят расти. Первым на наши вопросы ответил «дедушка русского тестирования» Александр Александров — тест-менеджер в компании Luxoft, кандидат физико-математических наук, эксперт RSTQB.

Сколько открытых багов у вас в бэклоге? 100? 1000?
А сколько времени они там лежат? Неделю? Месяц? Годы?
А почему так происходит? Нет времени? Надо делать более приоритетные задачи? «Вот сейчас все срочные фичи реализуем, а потом точно будет время на разгребание багов»?

… Некоторые используют Zero Bug Policy, у кого-то хорошо развита культура работы с багами (своевременно актуализируют бэклог, пересматривают ошибки при изменении функциональности и т.д.), а кто-то выращивает волшебников, которые пишут вообще без багов (маловероятно, но, может, и такое бывает).

Сегодня я расскажу вам про наше решение по чистке бэклога багов — проект «Багодельня».

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

Собственно, MS с радостью бы придушили эту свободу, чем они планомерно занимаются. Что-то их держит не перекрыть все выходы до конца. К примеру, Гугл душить не стремится, хотя мог бы. Есть, видимо, в мире много сервисов, не дающих сказать MS-овцам "Мы просто делаем, как все".

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

Представьте, что у вас есть всего один тест с использованием Selenium. Что может сделать его нестабильным? Как его ускорить? Теперь представьте, что тестов стало два. Теперь представьте сотню. Как заставить быстро отработать такую кучу тестов? Что произойдет, если количество тестов продолжит расти?

В этой статье Саймон Стюарт проведет нас по нелегкому пути масштабирования, от одного теста до параллельно исполняющихся сотен тестов. Мы познакомимся и с проблемами, которые при этом появляются, и с практическими методами решения этих проблем. Будет код на Java и некоторые мысли о развитии тестовой инфраструктуры.

Прототипом этой статьи является доклад Саймона Стюарта на Heisenbug 2017 Moscow. Саймон — создатель WebDriver, технологии, которой сейчас почти 11 лет. Он стал руководителем проекта Selenium около 9 лет назад. В Google занимался масштабированием Selenium, от нескольких десятков тысяч до нескольких миллионов тестов каждый день, на их инфраструктуре. Затем перешел в Facebook. В данный момент занимается разработкой спецификации WebDriver для W3C, которая входит в группу тестирования и тулинга в W3C. Можно сказать, что на основе WebDriver и создается стандарт.

Программист Трэвис Фишер, перевод статьи которого мы публикуем сегодня, решил рассказать о самых полезных, с его точки зрения, модулях и вспомогательных инструментах для JS-разработки. Полезными он считает технологии, которыми пользуется постоянно и в ценности которых убедился на собственном опыте. В частности, речь пойдёт о библиотеках и утилитах, предназначенных для серверной и клиентской разработки на JavaScript. Трэвис говорит, что не стремился к тому, чтобы включить в свой материал нечто узкоспециализированное, или сделать что-то вроде очередного awesome-списка, которые сами по себе весьма полезны, но обычно оказываются несколько перегруженными. Здесь речь пойдёт лишь о том, самом лучшем, что он с полной уверенностью может порекомендовать другим.

Контур ежегодно запускает бесплатные курсы по программированию для студентов в Екатеринбурге, Питере, Новосибирске, Ростове-на-Дону, Ижевске, Перми и Казани. С 2013 мы выросли до 7 городов и 13 университетов, разработали свою онлайн-платформу ulearn.me, где с февраля 2018 есть курсы не только для разработчиков на C#, но и курс для тестировщиков.

Именно о нем мы поговорили с Катей Чаплинской, менеджером разработки и организатором курса. Катя рассказала какие фишки ждут курсантов в этом году, как проходила подготовка и какие перспективы у курса.

Катя, буквально в двух словах расскажи что это за курс?

— Это уже пятый курс для новичков, который знакомит курсантов с основами тестирования. Традиционно в конце февраля мы набираем группу примерно из 30 студентов и молодых специалистов. Такая небольшая группа дает возможность уделить внимание каждому курсанту, да и преподаватели не утомляются, проверяя домашку. По опыту прошлых лет предполагаем, что 10-15% студентов не дойдут до конца курса, так что группа еще сократится. Занятия начались 22 февраля, все они будут проходить на Малопрудной два раза в неделю, по вторникам и четвергам. Курс закончится еще до майских праздников, потому что в середине мая курсантам становится не до занятий =)

Не важно, какой подход применяется при написании тестов: TDD, BDD, или какой-то другой. Юнит- тесты это первичный защитный барьер, который помогает избежать багов. А хорошо описанные кейсы помогут коллегам понять, что происходит в проекте и не наломать дров в коде.

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

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

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Всё время смущали вопросы простоты поддержки и применения, но в большей степени — пропускная способность решений. Хотелось, чтобы это было что-то простое в использовании и быстрое в работе. Готовые решения не подошли, и мы взялись делать свое.

Под катом расскажем, что из этого вышло, какие задачи решали, и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов. Этот пост — расшифровка доклада, который прозвучал на HolyJS 2017 Moscow. Видео можно посмотреть по ссылке, а почитать и посмотреть слайды — далее.

Каждый год мы стараемся тщательно измерять производительность разных версий PHP и HHVM на различных платформах. В этом году мы измерили четыре версии PHP и HHVM на 20 платформах/конфигурациях, включая WordPress, Drupal, Joomla!, Laravel, Symfony и многие другие. Также мы протестировали популярные решения для электронной коммерции вроде WooCommerce, Easy Digital Downloads, Magento and PrestaShop.

Мы всегда рекомендовали пользователям WordPress не пренебрегать преимуществами свежайших поддерживаемых версий PHP. Не только ради безопасности, но и ради повышения производительности. Причём речь идёт не только о WordPress, это по большей части справедливо для всех платформ. И сегодня мы продемонстрируем, как PHP 7.2 одерживает сокрушительную победу!

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

Движущая сила микросервисов

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

Пока властители дум всё ещё не могут определиться, справедливо ли это утверждение или нет, микросервисы уже успели войти в моду — причем до такой степени, что для большинства стартапов они де-факто стали архитектурой, выбираемой по умолчанию.

Однако, когда дело доходит до тестирования (или, чего похуже, разработки) микросервисов, выясняется, что большинство компаний по-прежнему испытывает привязанность к допотопному способу тестирования всех компонентов вместе. Создание сложной инфраструктуры считается обязательным условием для проведения сквозного (end-to-end) тестирования, при котором набор тестов для каждого сервиса обязательно должен быть выполнен — делается это для того, чтобы убедиться, что в сервисах не появилось регрессий или несовместимых изменений.

Привет, Хабр! Меня зовут Влад Романенко. Я работаю инженером по тестированию в Badoo, в команде iOS.

Любите заводить новые знакомства, обмениваться знаниями и опытом и быть в тренде? Тогда предлагаю вам внести в свой календарь пару—тройку предстоящих мероприятий.

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

В моём списке уже около 20 конференций. Среди них Международный день ГИС в Белорусском государственном университете, Конференция для пользователей и разработчиков ГИС с открытым исходным кодом в Москве и множество конференций по тестированию (например, эта и эта).

Я заметил, что многие тестировщики и QA-инженеры почему-то избегают конференций. И напрасно. С одной стороны, есть вы со своими вопросами к сообществу, с другой — есть сообщество, которому интересен ваш опыт. И почему бы эти две стороны не объединить? Именно поэтому я решил поделиться своим мнением относительно предстоящих мероприятий и вдохновить вас на их посещение.

Пока ребята из бекендов и фронтендов шлифуют последние фразы для рассказа о своих секциях, ребята из тестирования уже всё проверили.

В мире существует множество клёвых маленьких библиотек, которые как бы и не знаменитые, но очень полезные. Идея в том, чтобы потихоньку знакомить Хабр с такими вещами под тэгом #javalifehacker. Сегодня речь пойдёт о time-test, в котором всего 16 коммитов, но их хватает. Автор библиотеки — Никита Коваль, и это перевод его статьи, изначально написанной для блога Devexperts.

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

Вот простейший метод, считающий количество дней до конца света:

fun daysBeforeDoom() {
    return doomTime - System.currentTimeMillis()) / millisInDay
}

Мы продолжаем цикл статей «Календарь тестировщика», где каждый месяц тестировщики Контура делятся опытом и рабочими секретами. В предыдущей статье Максим Захаров рассказал как разобрать бэклог.

В этот раз Илария Тарасова и Максим Колодкин из Контур.Эльбы, расскажут, почему тестировщику нужно общаться с клиентом и какие инструменты для этого есть в Контуре. Чтобы не пропустить новую статью, подписывайтесь на телеграм-канал.

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

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

За 8 лет число пользователей сильно выросло, поэтому увеличилось и число консультантов. Сейчас их 70, они работают по жестким правилам и регламентам ради эффективности. С одной стороны, это помогает выстроить работу большой команды, а с другой, делает процесс очень негибким. Консультант может решить конкретную проблему, но у него не хватает времени, чтобы подумать шире и найти её истинную причину (например, в интерфейсе). В итоге такие проблемы не всплывают в ежемесячной статистике, а так и лежат на дне, пока не накопится критическая масса недовольных пользователей.

Автор материала, перевод которого мы публикуем сегодня, сотрудник Welldone Software, говорит, что если в двух словах рассказать об инструментах для тестирования JavaScript-проектов, то для модульного и интеграционного тестирования рекомендуется использовать Jest, а для тестов пользовательского интерфейса — TestCafe. Однако каждый конкретный проект может нуждаться в чём-то особенном. Лучший способ найти именно то, что нужно — взять несколько инструментов, которые, как кажется, подойдут, и испытать их в действии. Эксперименты подскажут — на чём именно стоит остановиться.



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

В Контуре работают 100 тестировщиков. В конце прошлого года они придумали «Календарь тестировщика» — цикл из 12 ежемесячных статей с практиками, секретами и лайфхаками о тестировании.

Первая статья была опубликована в январе на сайте «Сообщества тестировщиков Екатеринбурга». Мы переносим её на Хабр, чтобы её прочло больше тестировщиков. Следующая статья — за февраль — выйдет завтра, а её анонс будет в телеграм-канале.

Открывает цикл Максим Захаров, руководитель всех тестировщиков Контура и один из тестировщиков Ритейла. Он расскажет, почему копятся баги, как разобрать бэклог и уничтожить 80 багов с помощью пиццы :)

Бэклог — журнал оставшейся работы, которую необходимо выполнить команде. Термин пришел из семейства методологий Agile, в частности из Scrum, где он является одним из основных артефактов — источником пользовательских историй.

Я работаю тестировщиком в офисе примерно по 8 часов, изредка работаю в выходные. Есть большие цели на полгода и небольшие проекты на несколько недель или месяцев. Есть и обязательная рутина. Работы всегда с избытком, то есть нет объективной возможности сделать всю. Через год я не хочу увидеть, что делаю те же задачи и решаю те же проблемы. Я не Дорофеев и не Архангельский, рецепта счастья в статье не будет, но можно смело рассчитывать на пару неплохих советов и приемов.

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