Эту статью написал программист из Италии Валентино Гаглиарди. Он говорит, что сразу после выхода Puppeteer его заинтересовала автоматизация тестирования веб-интерфейсов с использованием данной библиотеки и Jest. После этого он приступил к экспериментам.



Здесь речь пойдёт об основах работы с Puppeteer и Jest на примере тестирования веб-формы. Также тут будут рассмотрены особенности использования Chromium с пользовательским интерфейсом и без него, и некоторые полезные мелочи, касающиеся различных аспектов тестирования веб-страниц и организации рабочей среды. Валентино полагает, что, хотя Puppeteer — инструмент сравнительно новый и его API вполне может подвергаться изменениям, у него есть шанс занять достойное место в арсенале веб-разработчиков.

BDD — разработка через поведение. BDD для микросервисов — это сотрудничество клиента, разработчиков и тестировщиков. BDD — это разработка, которая учитывает и технические интересы и бизнес-требования. Этот подход обычно применяется для описания интерфейсов приложений, а так как микросервисы — детали реализации системы, то BDD прекрасно походит и для разработки микросервисов. Как это сделать — в переводе материала Ken Pugh.



Об авторе: Ken Pugh обучает компании развивать гибкость, создает высококачественные системы с помощью Acceptance Test-Driven Development, BDD, ускорения DevOps. Кен написал несколько книг по разработке ПО, был лауреатом премии Jolt Award 2006 Prefactoring, один из создателей курса SAFe Agile Software Engineering.

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

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

Итак начнем.

Что нам понадобится?

• Python начиная с версии 2.7 (Весь код тестировался на версии 2.7.16 и 3.7.3)
• Модуль PyMySQL
• Модуль vk_api
• Модуль requests
• Группа Вконтакте (Внимание! Бот будет работать именно со стороны группы, а не стороны аккаунта человека)
• База данных (включая данные о пользователе и т.д)

Подключение

Для начала подключим все библиотеки:

import vk_api
from vk_api.utils import get_random_id
from vk_api.bot_longpoll import VkBotLongPoll, VkBotEventType
import pymysql.cursors
import requests

Теперь можно приступить к настройке бота и базы данных.

Именно в моем случае все данные находятся в файле config.py. Вы же можете прописать их где угодно. На функционал то никак не повлияет.

Подключение базы данных

Для этого создадим функцию при помощи модуля PyMySQL:

def get_connection():
    connection = pymysql.connect(host='you_host',
                                 user='you_user',
                                 password='you_password',
                                 db='you_db'
                                 charset='utf8mb4',
                                 cursorclass=mymysql.cursors.DictCursor)
    return connection

Эта функция будет возвращать данные для дальнейшей работы с базой данных. Соответственно подставляем свои данные где видим «you_».

Всем привет! Продолжаю рассказывать об опыте управления в IT. Сегодня поговорим о вводе нового сотрудника в команду. Вы взяли инженера в штат. Когда он станет полноценной боевой единицей? Что делать, чтобы ускорить его адаптацию? Как оптимизировать этот процесс? В конце концов, стоит ли вообще уделять этому внимание и тратить время?

Добро пожаловать на 11 урок! Если помните, то еще в 7 уроке мы упомянули, что у Check Point существует три типа Security Policy. Это:

1. Access Control;
2. Threat Prevention;
3. Desktop Security.

Мы уже рассмотрели большинство блейдов из политики Access Control, главная задача которых — контроль трафика или контента. Блейды Firewall, Application Control, URL Filtering и Content Awareness позволяют уменьшить площадь атаки, отсекая все лишнее. В данном же уроке мы рассмотрим политику Threat Prevention, задача которой — проверка контента, который уже прошел через Access Control.

25 апреля мы провели очередной митап Avito Student Talks, в этот раз он был посвящён аналитике: карьерному пути, Data Science и продуктовой аналитике. После встречи мы подумали, что её материалы могут быть интересны самой широкой аудитории и решили ими поделиться. В посте — видеозаписи докладов, презентации от спикеров, отзывы слушателей и, конечно, фотоотчёт.

Цели данной публикации:

• Краткое введение в Consumer Driven Contracts (CDC)
• Настройка CI pipeline на основе CDC

Consumer Driven Contracts

В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.

Для продолжения нам необходимо познакомиться с основными положениями CDC:

• Контактное тестирование находится на уровне Service/Integration Tests над Unit Tests согласно пирамиде автотестирования (Mike Cohn)
• Контрактное тестирование может применяться, когда есть 2 (или более) сервиса, которые взаимодействуют друг с другом
• Сonsumer driven подход означает, что первым шагом в реализации является написание теста на стороне потребителя. Результатом теста является пакт (контракт) в формате json, который описывает взаимодействие между потребителем (например, веб-интерфейс / мобильный интерфейс: сервис, который хочет получить некоторые данные) и поставщиком (например, серверный API: сервис, который предоставляет данные)
• Следующим шагом является проверка договора с провайдером. Это полностью осуществлено фреймворком Pact.

После нахождения уязвимостей в мобайл-банкинге украинского банка (пост) я захотел немного сменить направление и перейти от финансовых сервисов к другим.

На глаза попалась рекламная статья про обновлённое мобильное приложение такси, его я и выбрал своим подопытным.

Здесь инструменты те же: ПК, Fiddler, Android-смартфон – устанавливаем приложение и отслеживаем его запросы.

Я специально не рассматривал запросы и ответы при регистрации или логине (например, не стал проверять возможность перебора пароля), а перешёл к функциям, доступным после регистрации.

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

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

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

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

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

Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.

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

27 апреля команда FunTech Meetups провели первый митап по тестированию. Митап был полностью посвящён автоматизации, а спикеры из Mail.ru Group, Badoo, ivi.ru, Tinkoff.ru и FunCorp в своих докладах рассказывали, как и что они автоматизируют в своих компаниях. Предлагаем Вашему вниманию видео и слайды с этих выступлений.

«Автотесты, объединяющие подходы, платформы и сердца», Михаил Чирков, ivi.ru

Привет. Меня зовут Даша, тестирую мобильное приложение 2ГИС на iOS. Хочу поделиться нашим процессом ведения фич, который помогает не только сэкономить время, но и прокачать личные скиллы. Прочитайте статью, чтобы узнать, как нам удаётся удерживать в едином контексте продактов, дизайнеров, разработку. Мы верим, что ревью первой тестовой сборки всеми заинтересованными действительно облегчает людям жизнь. А коммуникация — ключевой момент в ведении фичи.

Предисловие: в университете было получено задание — собрать scrum команду, выбрать проект и работать над ним в течении семестра. Наша команда выбрала разработку веб-приложения (react + flask). В этой статье я постараюсь рассказать, какими тесты должны были быть, и проанализировать, что у нас получилось на бекенде.

Примерно полтора года назад я начал участвовать в хакатонах. За этот временной промежуток я успел принять участие в более чем 20 мероприятиях различного масштаба и тематик в Москве, Хельсинки, Берлине, Мюнхене, Амстердаме, Цюрихе и Париже. Во всех мероприятиях я занимался анализом данных в том или ином виде. Мне нравится приезжать в новые для себя города, налаживать новые контакты, придумывать свежие идеи, реализовывать старые задумки за короткий промежуток времени и адреналин во время выступления и оглашения результатов.

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

Привет, Хабр!

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

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

Многие считают тестирование на production окружении вредной практикой: оно не помогает предотвратить попадание проблем к конечным пользователям, а больше констатирует их наличие. Кроме этого, тестировщик отрывается от стандартного рабочего процесса и методик, применяемых на тестовом окружении. Меня зовут Оля Михальчук, я QA-инженер в финтех-компании ID Finance. В этом посте я расскажу почему тестирование на проде может существенно помочь вашему проекту.

Привет, Habr. Меня зовут Илья Смирнов, я Android-разработчик в компании FINCH. Хочу показать вам несколько примеров работы с Unit-тестами, которые мы наработали у себя в команде.

В наших проектах используется два вида Unit-тестов: проверка на соответствие и проверка на вызов. Остановимся на каждом из них более подробно.

Разбираемся, в чём суть методологии и кому она может принести пользу.

Также поговорим о DevOps-специалистах: их задачах, зарплатах и навыках.

Аннотация

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

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

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

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

В начале 2019 года мы (совместно с порталами Software-testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.

Статья публикуется от имени Ахальцева Иоанна, Jiga

Tinkoff.ru сегодня — это не просто банк, это IT-компания. Она предоставляет не только банковские услуги, но ещё выстраивает экосистему вокруг них.

Мы в Tinkoff.ru заключаем партнерство с различными сервисами для повышения качества обслуживания своих клиентов, и помогаем становиться этим сервисам лучше. Например, мы проводили нагрузочное тестирование и анализ производительности одного из таких сервисов, которые помогли найти узкие места в системе — включенные Transparent Huge Pages в конфигах ОС.

Если вы хотите узнать каким способом провести анализ производительности системы и что из этого получилось у нас, то добро пожаловать под кат.