Привет, Хабр! Вы наверняка сталкивались с терминами «тестирование», «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 микросервисов, которые тестируются на различных уровнях. У нас, как и в классической пирамиде, таких уровней три, а сейчас мы активно запускаем еще один — контрактные тесты.
Приветствуем вас, уважаемые пользователи и читатели Хабра!
Мы рады представить вам долгожданные функции нашего продукта «ПроAPI Структура» от команды «Вебмониторэкс». Эти функции позволят вам еще более эффективно управлять и оптимизировать ваши API. Речь идет о «Настройке чувствительности», «Очистке трафика» и «Создание правил WAF для параметров роута». Давайте подробно рассмотрим каждую из них.
Часто ли вы сталкивались с ситуацией, когда тесты падали из-за небольшой разницы между скриншотами? Например, не успел исчезнуть спиннер, не докрутился скроллбар, уведомление исчезло чуть быстрее, чем нужно и так далее.
Часто ли вы сталкивались с ситуацией, когда тесты падали из-за того, что на скриншоте появился сторонний элемент, который выпустила другая команда? Часто ли вы сталкивались… с самыми разными причинами, из-за которых приходится сидеть и анализировать фейлы скриншотных тестов?
Меня зовут Александр Гончар, я инженер по обеспечению качества в Т-Банке. Хочу поделиться опытом, как избавиться от скриншотных тестов.
С 21 февраля по 3 марта в Казани проходил первый международный фиджитал-турнир «Игры будущего». Зрелищные соревнования на стыке традиционного и цифрового спорта, инновационные дисциплины, более 2000 участников со всего мира — турнир стал по-настоящему уникальным событием. Мероприятие ожидаемо привлекло зрителей и получило широкое освещение в СМИ. Правда, было и то, что на протяжении всего турнира неизменно оставалось за кадром: кибератаки и инциденты информационной безопасности на «Играх будущего».
Масштаб таких мероприятий всегда диктует исключительные требования к обеспечению кибербезопасности. А учитывая специфику турнира, киберспортивную составляющую и сложную IT-инфраструктуру, к защите игр необходим был особый подход. Поэтому для нас, экспертов Positive Technologies, выступившей ключевым партнером по кибербезопасности на «Играх будущего», это стало своего рода вызовом. Забегая вперед, докладываем, что справились мы с ним успешно: на мероприятии не было допущено ни одного инцидента ИБ, повлекшего последствия для проведения турнира! Но обо всем по порядку. Как мы, специалисты PT Expert Security Center (PT ESC), защищали от кибератак «Игры будущего»? Какие инциденты обнаруживали? Какие продукты и технологии нам помогали? Обо всем этом читайте под катом!
Про тестирование PWA есть много разрозненных мнений, подходов и обособленных принципов, иногда противоречащих друг другу. Мы в Red Collar решили испытать на себе несколько вариаций подхода к тестированию таких приложений.
Продолжение темы использования библиотеки контрактного тестирования Pact для .NET. В первой части темы были рассмотрены теория и процесс контрактного тестирования взаимодействий по HTTP.
В случаях, когда между системами есть зависимости, даже при условии наличия тестов на обеих сторонах, гарантировать отсутствие ошибок довольно тяжело. В особенности нелегко запомнить кучу взаимодействий, полагающихся на очереди, обменники, топики и прочие асинхронные каналы.
В этой статье подробнее остановимся на тестировании асинхронных коммуникаций на примере RabbitMq, а также познакомимся с инструментом PactBroker.
