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

В 2021 году я начал масштабное исследование трудоустройства 400 QA-студентов более десятка различных курсов. Исследование получилось настолько длинным, что превратилось в дюжину хабр-статей с 500'000 просмотрами, а некоторые из его участников успели пройти путь от "какой курс посоветуете?" до "поздравьте, мне предложили позицию сеньора".

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

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

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

Язык паттернов помогает избежать многих проблем: не использует широкие тесты, не использует моки, не игнорирует инфраструктуру и не требует архитектурных изменений. Он обладает мощью широких тестов, а также скоростью, надёжностью и удобством сопровождения, присущим модульным тестам. Хотя и не обошлось без компромиссов. В этой публикации подробнее рассмотрим паттерны инфраструктуры, паттерны Nullability и паттерны тестирования легаси-кода.

Специалисты fullstack QA весьма востребованы работодателями. В сегодняшней статье расскажу, в чем ценность таких сотрудников, какие hard и soft skills нужны и почему будущее именно за fullstack QA.

Данный регламент я написал на основании опыта работы лидом в IT компании с веб-приложением. Пункты из него прошли проверку практикой. Изначальные версии были основаны на best practice из интернета, agile и опыта предыдущих и текущих руководителей.

Здесь нет привязки на какую-то определенную систему трекинга задач. Использование возможно как для JIRA, Kaiten, GitLab, Trello, так и для excel-таблицы.

В своей книге "Методы тестирования программного обеспечения" Борис Бейзер описывает парадокс пестицидов. В контексте тестирования программного обеспечения - независимо от того, какой метод тестирования вы выберете, вы все равно пропустите более незаметных “вредителей”, то есть баги.

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

Как же с этим справиться? Расширить охват тестирования, добавив в свой процесс фаззинг.

Представляем вам Asserts — платформу для анализа и отслеживания метрик. Сканируя метрики вашего приложения в любой совместимой с Prometheus базе данных временных рядов (time-series database, TSDB), Asserts в реальном времени: 

— создаёт карту архитектуры приложения и инфраструктуры, 
— строит дашборды, 
— отслеживает цели уровня обслуживания (service level objectives, SLOs) 
— и запускает автоматические проверки для выявления изменений и потенциальных проблем. 

Наша задача — снизить усталость от предупреждений и сократить время поиска первопричины.

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

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

Отмечу, что говорить мы будем именно о Chrome DevTools, хотя и в других браузерах есть аналогичные консоли разработчиков. Сам их частенько использую — это удобно. Поскольку инструменты неочевидные, рекомендую заглянуть под кат и начинающим, и опытным тестировщикам — точно почерпнёте для себя что-то новое.

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

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

Автоматизированные тесты очень важны. Без них программистам приходится тратить огромное количество времени на ручную проверку и исправление кода. К сожалению, многие автотесты также тратят огромное количество времени. Простым и очевидным вариантом является создание широких тестов, которые являются автоматизированными версиями ручных тестов. Но они нестабильны и медленны.

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

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

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

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

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

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

В известном смысле это основы тестирования, но по моему опыту как раз из-за этого (“это база, ну что там может быть такого”) о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат – налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы. 

Приступим!

Интересуетесь, как ускорить автоматизированные UI тесты? Узнайте эффективные и действенные советы, которые помогут вам быстрее и эффективнее выполнять UI автотесты.

Привет, Хабр! Меня зовут Катерина. Недавно я опубликовала подборку ресурсов для питонистов и, поскольку ее неплохо приняли, решила поделиться еще и ресурсами для QA-специалистов. Я не систематизировала их по важности или популярности, просто разбила на статьи, YouTube- и Telegram-каналы.

Всем привет! Относительно недавно, мне повезло столкнуться с задачей автоматизации, связанной с шиной событий EventBus. Задача довольно интересная, поэтому хочу поделиться своим решением, вдруг помогу кому-нибудь)

Как в PHP заставить функции из стандартной библиотеки, например \time() или \date() выдать нужный результат?

С помощью инструмента xepozz/internal-mocker такое возможно сделать. Для этого необходимо выполнить несколько подготовительных шагов и можно запускать тесты в любом окружении.

Опыт запуска Kafka в тестовых сценариях достиг высокого уровня удобства благодаря использованию Testcontainers и улучшенной поддержке в Spring Boot 3.1 с помощью аннотации @ServiceConnection. Однако написание и поддержка интеграционных тестов с Kafka по-прежнему представляют собой вызов. В этой статье описывается подход, который значительно упрощает процесс тестирования, обеспечивая изоляцию тестов и предоставляя набор инструментов для достижения этой цели. При успешной реализации изоляции, тесты с Kafka могут быть организованы так, что на этапе проверки результатов обеспечивается полный доступ ко всем сообщениям, возникшим в ходе теста, избегая при этом необходимости в использовании методов принудительного ожидания, таких как Thread.sleep().

Этот метод подходит как для использования с Testcontainers, так и для Embedded Kafka или других способов запуска сервиса Kafka (например, локального инстанса).

Всем привет! Меня зовут Артём. Последние два с половиной года я активно ввожу за руку ребят в мир IT через плоскость тестирования веб-систем. Не так давно, используя накопленный опыт и практику я создал собственный курс, где обучаю ребят любых возрастов тестированию с нуля.

Сегодня я немного расскажу про процессы и используемые инструменты для обучения на моем курсе.

Привет, Хабр! Меня зовут Василий Косарев, я Java‑разработчик в CDEK. Много раз мы слышали о необходимости писать модульные тесты, о том, что весь код должен быть ими покрыт. При этом мне не встречалось списка: какие именно методики лучше использовать при тестировании кода.

Я задумался: есть ли чек‑лист/ руководство, который облегчил бы генерацию тестовых сценариев и помог выявлять серьёзные ошибки? Чтобы вдумчиво подходить к тестированию и не тратить ресурсы впустую, сводя к минимуму количество необходимых тестов.

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

Всем привет! Меня зовут Алексей Иванов, и я очень люблю тестирование.

Несколько месяцев назад я заметил, что в Москве не хватает митапов по тестированию. Да, есть митапы, которые иногда проводят ребята из Альфа-банка, Озона, X5, но все они исходят от компаний, а не от сообщества как такового. И мы с небольшой командой организовали сообщество MoscowQA и провели первый митап в МТС AI.

29 февраля наш митап пройдет при поддержки компании Самолет.

В программе доклады инженеров из Самолета, Flipper Devices и moretv.