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

Привет, меня зовут Андякина Ольга, я QA‑инженер в компании 2ГИС, тестирую сервис по бронированию отелей Отелло. В этой статье расскажу про плюсы и минусы разных подходов к генерации данных и поделюсь хорошими практиками подготовки данных на примере пакета библиотек d42 и нашего проекта. В первую очередь, наш опыт будет полезен тем, кто занимается автоматизацией тестирования фронтенда.

Автоматизированное тестирование сложно представить без использования тестовых данных. Например, при интеграционном тестировании нужно записывать данные в базу и валидировать полученные данные, в нагрузочном — выполнять запрос с уникальными параметрами. Также данные могут потребоваться при фронтенд‑ и e2e‑тестировании, чтобы наполнить блок текстом или ввести ФИО в форму. Есть различные подходы к получению тестовых данных для автотестов, и генерация данных — один из самых удобных и гибких подходов.

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

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

Привет, я Евгений Иванченко, лидер Web QA Гильдии в Dodo Engineering. При иных обстоятельствах я мог бы оказаться главой отдела тестирования, но у нас нет такого отдела. Нет, это не результат техногенной или юридической катастрофы. Мы его просто распустили.

Разумеется, это не значит, что мы перестали тестировать наши продукты. Мы только избавились от выделенной команды тестирования. Как в Dodo Engineering провели глобальную перестройку процессов и чем в этом помог Kaiten — читайте под катом.

Во время работы над проектом на Django Rest Framework (DRF) я столкнулся с необходимостью писать тесты для API, которые возвращали неотсортированные данные. Сортировка данных в API не требовалась, и делать её только ради тестов казалось нелогичным. Использовать для решения этой задачи множества оказалось невозможным, так как элементы множества должны быть хэшируемыми, коими словари не являются. Я искал встроенный способ сравнивать неотсортированные данные в pytest, но таких средств не нашёл. Зато наткнулся на обсуждение в сообществе pytest, где пользователи просили реализовать такую возможность, а разработчики pytest предлагали сделать это кому-то другому в виде плагина. Так родилась идея создания pytest-unordered.

Лирическое отступление. Дорогие читатели, мы продолжаем рассказывать о том, как работать в SM Lab! Ознакомьтесь с нашей предыдущей статьей, чтобы узнать больше о нашей культуре и принципах работы Как QA собеседование проходил. Следите за обновлениями, впереди еще много интересного!

Привет, Хабр! Вы наверняка сталкивались с терминами «тестирование», «QA» и «QC». В индустрии сейчас распространены сбивающие с толку интерпретации этих терминов. Мы считаем, что эта путаница приводит к множеству проблем, как внутри отдельных команд или компаний, так и в индустрии в целом. В этой статье мы расставили все точки на ё и на примерах объяснили разницу в этих терминах.

Разработчики вечно ищут баланс: как выпускать фичи быстро, качественно и желательно небольшой командой. Наш рабочий рецепт – это фронты + e2e-тесты. Рассказываю, как мы используем автотесты и визуализируем их результаты.

Нагрузочное тестирование (load testing) — это процесс оценки производительности системы под разными уровнями предполагаемой рабочей нагрузки. Профессия нагрузочного тестировщика, несмотря на свою относительную «молодость», становится весьма востребованной в крупных ИТ-компаниях. Если вы выбираете для себя направление специализации в QA — то будут интересны основные плюсы и минусы профессии на основе нашей оценки этой сферы и рынка труда. А ваши комментарии помогут дополнить этот список плюсов и минусов.

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

Тестирование — это процесс оценки программного приложения, а тестировщики — это профессионалы, которые участвуют в этом процессе. Они решают множество задач: пишут тест-кейсы, сообщают о найденных багах, настраивают среду, работают с требованиями и так далее. По данным исследования, рынок тестирования программного обеспечения уже превысил 40 миллиардов долларов США и, как ожидается, к 2027 году вырастет ещё на 7%. Тестировщики должны знать языки программирования, инструменты управления тестированием, инструменты автоматизации тестирования, обладать навыками управления проектами и многими другими навыками. 

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

Привет! Меня зовут Антон Червонный, мне 29 лет, и чуть больше трёх из них я занимаюсь тестированием. Чтобы стать QA-инженером, я прошёл курсы «Инженер по тестированию» и «Автоматизатор тестирования на Java» в Яндекс Практикуме, но это не весь мой релевантный опыт — до этого я оптимизировал процессы в отельном бизнесе и обеспечивал качество в сети квест-комнат.

Я много лет живу в Австрии. В этом материале я расскажу, как дорос до синьора за три года и чем отличаются привычки нанимающих менеджеров в Европе и России. И самое главное: поделюсь методикой, которая помогает мне получать приглашения на собеседования в ответ на 8 откликов из 10.

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

В статье мы рассмотрим реализацию связки Qase с Playwright и GitLab CI, которую мы используем в SmartHead: от создания проекта до получения отчетов об автоматизированном тестировании.

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

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

Всем привет!

Меня зовут Гребенюк Гузель, я QA-руководитель группы тестирования в АЭРО. Мы занимаемся разработкой eCommerce- и data-решений для крупного бизнеса.

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

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

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

Следующим этапом мы стали формировать e2e цепочки из методов путём получения значений переменных полученных из одного запроса и передачи их в качестве входных параметров в следующий запрос. Это дало толчок к активному использованию вкладки Test в Postman и формированию сниппетов для парсинга ответов и получения нужных значений. В результате мы сформировали шаблоны по базовым тестам, которые стали использовать ручные тестировщики на всех проектах.

В рамках этих тестов мы проверяли коды ответов, время отклика, типы полей,  json схемы, требования по ограничениям для получаемых значений. Это дало хороший прирост в скорости регресса и качестве тестирования.

Инструменты мониторинга работы приложений могут быть полезны не только DevOps’ам, но и разработчикам для исследования производительности приложения в поиске, например узких мест в его работе, поэтому в данной статье мы не только настроим мониторинг для Jmix-приложения, но и подготовимся к его синтетическому нагрузочному тестированию. Особенностью платформы Jmix в силу того, что она использует фреймворк Vaadin, является тот факт, что работа UI интегрирована с бекендом, но это также значит и то, что и метрики можно использовать прозрачно, т.е. замерять ими работу интерфейсного слоя. 

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

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

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

Всем привет! Меня зовут Александр, в hh.ru я занимаюсь автотестами. В статье про оценку тестового покрытия мы затронули тему интеграционных тестов. В этом материале я расскажу, как у нас обстоят дела с пирамидой тестирования в целом. В hh.ru более 200 микросервисов, которые тестируются на различных уровнях. У нас, как и в классической пирамиде, таких уровней три, а сейчас мы активно запускаем еще один — контрактные тесты.