Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

Под катом — разбор тестирования первого из этой тройки, GraphQL. Все примеры в посте я делал с помощью Postman, он достаточно популярен и доступен, чтобы вы при желании могли всё быстро в нём повторить.

Технологический прогресс не стоит на месте, особенно если это касается области IT. Еще в 2014 году, когда Google открыл исходный код проекта Kubernetes, который вобрал в себя лучшее из Borg и Omega - внутренних систем Google, его мало кто знал и использовал. Но прошло 7 лет и K8S (он же Kubernetes) стал успешным open-source проектом, который используется по всему миру. В большинстве компаний инфраструктура построена на K8S - от маленьких проектов до огромных кластеров и облаков, которые обеспечивают бесперебойную доступность сервисов. Давайте коснемся Kubernetes и расскажем, как им пользоваться на практике. Но сначала надо спросить, а что такое этот ваш Kubernetes и для чего он собственно нужен. Подойдет ли он для ваших проектов.

Привет, я Алексей, QA Automation Engineer в команде «Интеграции» в Петрович-ТЕХ. Занимаюсь разработкой фреймворка автоматизированного тестирования сервисов интеграции, для REST и SOAP. 

Наблюдение: когда приходишь на собеседование на должность Junior QA Automation, то обязательно просят разработать автотесты для API. Звучит логично, но не так уж и просто: когда только начинаешь свой путь в автотестировании, тебе не всегда очевидно, как должен выглядеть рабочий тестовый фреймворк, из чего он должен состоять, как правильно написать тесты, а к ним тестовые данные. «Сырые» тесты, которые описывают в книгах и разных источниках – не всегда выручают.

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

Надеюсь, статья будет интересна начинающим авто-тестировщикам и тем, кто уже разрабатывает автотесты для API.

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

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

Составные части аудита качества:

• Текущее качество продукции.

• Качество тестирования.

• Качество разработки.

• Требования к качеству.

• Готовность к производству.

• Опасные области.

• Состояние процессов по проекту.

• Автоматизация + Рентабельность инвестиций.

• Удовлетворенность клиентов.

Когда:

• У вас нет четкой видимости качества программного обеспечения или узких мест в процессе работы.

• Рабочая нагрузка вашего проекта увеличивается, но ваш текущий процесс контроля качества не позволяет масштабировать ресурсы.

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

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

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

Для чего:

• Изучить, с чего начинается процесс, как он поддерживает развитие и где он эффективно заканчивается.

Cистемой тестирование также обеспечивает проверку пакетной обработки и обработки данных из других вышестоящих и нижестоящих систем. Отсюда и название «End-to-End». Сквозное тестирование обычно проводится после функционального и системного тестирования. Для его проведения используются реальные данные и тестовая среда для имитации рабочего режима. 

Нам известны 7 принципов тестирования и сейчас мы их подробно разберём.

Итак, приступим.

1.  Исчерпывающее тестирование невозможно
2.  Тестирование демонстрирует наличие дефектов, а не их отсутствие
3.  Заблуждение об отсутствии ошибок
4.  Раннее тестирование сохраняет время и деньги
5.  Принцип скопления или кластеризация дефектов
6.  Тестирование зависит от контекста
7.  Парадокс пестицида

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

В переводе с латинского При́нцип - это основа, начало, первоначало, и можно сказать, что принципы тестирования — это основы тестирования.

Привет! Меня зовут Тимур Шарафутдинов, я занимаюсь процессами автоматизации тестирования в «Ростелеком ИТ». Сегодня поделюсь своим опытом реализации model based-подхода в написании python API автотестов на проекте — приложении с микросервисной архитектурой для обработки, хранения, конфигурирации заказов.

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

Вернуться Дальше

Я обнаружил, что Python Testing с pytest является чрезвычайно полезным вводным руководством к среде тестирования pytest. Это уже приносит мне дивиденды в моей компании.

Chris Shaver
VP of Product, Uprising Technology

Перевод статьи подготовлен специально для студентов курса «Python QA Engineer»

Кроссбраузерное тестирование – это именно тот тип тестирования, который требует большого количества сил и времени. Тестирование веб-приложения в различных браузерах, на различных операционных системах, устройствах, разрешениях экрана для того, чтобы оценить рендеринг вашего сетевого контента для обширной аудитории – серьезная задача. Особенно, если заниматься этим вручную. Автоматизированное кроссбраузерное тестирование с помощью Selenium поможет сэкономить время на рутинных действиях и сократить время регрессионного тестирования. Однако люди не любят перемены. Если в вашей организации популярно ручное тестирование, у руководства, вероятно, возникнут вопросы, когда вы предложите внедрить автоматизацию тестирования.

В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:

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

Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?

В данной статье разберем, как писать gRPC автотесты с использованием языка Go, также сделаем Allure отчет

Docker, первый выпуск которого был еще в 2013 году, — весьма удобный инструмент для сборки пакетов, поставки и запуска приложений в «контейнерах». Большинство крупных компаний, например, Google, Amazon и VMware рассматривают Docker как зрелую технологию для контейнеров, поэтому сейчас самое время изучить этот инструмент и в результате продвинуться по карьерной лестнице. Хотите? В статье будут приведены вопросы по Docker, ответы на которые нужно знать, если вы идете на собеседование.

Современные приложения активно используют сети. Обычное дело, когда во время сборки apt-get/dnf/yum/apk install устанавливает пакет из репозитория пакетов дистрибутива Linux. При выполнении команды приложение может захотеть подключиться к внутренней базе данных postgres или mysql, чтобы сохранить определённое состояние при вызове listen() и accept(). При этом разработчик должен иметь возможность работать отовсюду — из дома или офиса, с мобильного устройства или через VPN. Docker Desktop помогает сделать так, чтобы сеть «просто работала» в каждом из сценариев. В статье разбираем инструменты и методы, которые обеспечивают это, начиная с всеми любимого набора протоколов: TCP/IP.

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

Рабочий репозиторий с финальной версией рабочего кода и инфраструктуры

Ссылка на отчеты после прогона тестов

Когда я хотел добавить в gitlab автотесты в стеке python, allure, docker, то я выяснил, что толковых статей на эту тему нет. Пришлось разбираться самостоятельно и как результат проб и ошибок появилась эта статья, которая скорее является гайдом, частично затрагивающим написание тестов, но наибольший фокус именно на выстраивании инфраструктуры. Если у вас уже написаны тесты на allure, то вы сразу можете переходить к разделу настройки инфраструктуры. Отмечу, что текст НЕ затрагивает написание UI тестов, но я затрону инфраструктуру для них в отдельном блоке.

К старту курса по разработке на Python делимся детальным руководством по работе с современным PyQt для новичков. Чтобы читать было удобнее, мы объединили несколько статей в одну:

1. Первое приложение

2. Слоты и сигналы

3. Виджеты

За подробностями приглашаем под кат.

• Основы
• Накапливание (аккумулирование) данных на месте
• Именование значений внутри f-строки
• Any и All
• Подводные камни и ограничения
• Заключительные мысли

Всем привет!

Меня зовут Борис. Я AQA iOS-engineer в Vivid Money.

Это вступительная статья, в цикле статей по iOS-автоматизации, в которых хочется рассказать о пользе ui-тестов на проекте, их эффективном использовании и написании.

Данная статья будет полезна начинающим iOS-автоматизаторам, либо разработчикам, которые решили изучить XCUITest и покрыть свой проект ui-тестами.