Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.
В данной статье я бы хотел описать подход к написанию тестов с четким разделением на отдельные этапы, каждый из которых выполняет свою специфическую роль. Это способствует написанию тестов, которые легче читать, понимать и поддерживать.
Речь пойдет об использовании методологии Arrange-Act-Assert применительно к интеграционным тестам на Spring Framework с использованием мокирования (mock) HTTP-запросов к внешним ресурсам, к которым идет обращение по ходу выполнения тестируемого кода в рамках поведения системы. Предлагаемые к рассмотрению тесты написаны с использованием Spock Framework на языке Groovy (см. недавнюю статью по этой теме: Тестируем Spring Boot приложения через Spock Framework). В качестве механизма мокирования будет использоваться MockRestServiceServer. Будет пару слов и о WireMock.
Привет! Меня зовут Даниил Савин. Летом я участвовал в программе стажировки для безопасников от Бастион и в процессе глубоко исследовал тему безопасности приложений, использующих GraphQL. Так появилась статья, из которой вы узнаете:
• какие встроенные функции есть у GraphQL;
• как тестировать GraphQL API;
• какие инструменты использовать;
• и как обходить различные защитные механизмы.
Всем привет, это моя первая статья по тестированию. До этого я писал от лица Scrum-мастера, а теперь уже и от лица QA. В тестировании я уже более 2-х лет. Работал на двух проектах одновременно, и было супер весело менять проект на протяжении дня: утром ты тестируешь веб-сервис, а вечером со студентами делаешь тест-план по мобильному приложению. Не жизнь, а сказка!
Из названия мы с вами понимаем, что тема статьи интересна и, как воздух, необходима.
Для кого-то покажется тестирование без требований пустяком, и он, как вызов, примет этот поединок. Но я хочу заметить, что тестировать сервис-продукт, который ты понимаешь от того, что видел аналоги, пользовался этим сервисом с пелёнок и понимаешь его за счет косвенных требований - дело одно. Когда нет аналогов или сервис выполняет роль франкенштейна из функционала от разных продуктов - тут ситуация другая.
Не будем петь серенады, как это сложно, и приступим к делу.
Вас посвящают в суть проекта, и главный шаг - уточнить у аналитика или того героя, кто выполняет эту роль, "Есть какая-нить дока?" (далее - спецификация).
Какая может быть спецификация на проекте? Будьте внимательны, я не использую термин документация, потому-что дока - это текстовый формат, а в виде спецификации может выступать:
1) документация; обновленная в последний раз в 90-х
2) макеты; вообще не похожи на прод
3) тикеты в Jira; обычно там один заголовок, но верим в чудо
4) user-story;
5) тест-кейсы, чек-листы; если был тестировщик до
6) звонок с владельцем продукта; Product owner
.only from Cypress test» — знаком ли вам такой комментарий к коммиту? Если вы используете Cypress для сквозного тестирования, то вы знаете, о чем я говорю.
Хорошее название бага понятно любому:
- менеджеру, плохо знающему техническую часть проекта;
- джуниору, который только пришел в проект;
- разработчику (зачем мне это чинить?)
Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?
И в этой статье я хочу разобрать каждый из них подробнее
Уверен, многие даже не задумываются над тем, как поведёт себя разрабатываемый бот в случае неправильного его использования. Самое время вскрыть своих ботов и исправить часто допускаемые недочёты, которые я здесь опишу. Снова их 5, снова никакого кода, снова только описание. Добро пожаловать под кат.
Привет! Меня зовут Таня, я куратор в SM Lab. В этом посте я расскажу вам о нашем пути оптимизации тестирования — узнаете, какие на нашем продукте были проблемы в процессах тестирования, как мы их решали, почему не надо отвлекать тестировщиков и в чём польза интуитивного тестирования.
Для того чтобы понять суть процессных изменений, нужно знать, как же мы работали до них.
Итак, основа.
У нас есть две доски в Jira. Первая отвечает непосредственно за релизные задачи и хотфиксы, вторая — за задачи сопровождения и инциденты. Рассмотрим подробнее первую доску с задачами и хотфиксами.
На ней есть три колонки, с которыми и работают тестировщики:
Привет, Хабр! Меня зовут Александр Бехтерев, я работаю QA-инженером в Учи.ру. Не так давно перед нами встала задача перехода с библиотеки Selenium на новую и мощную библиотеку Playwright. Этот переход был вызван желанием улучшить процессы тестирования и попробовать что-то новое.
В этой статье я постараюсь подробно рассмотреть процесс создания проекта на Python, Pytest и Playwright с применением паттерна Page Object, а также оставлю шаблон yml, который позволит запускать автотесты в CI.
Я вернулся с очередным постом. На этот раз я напишу о процессе интеграции веб- и мобильных проектов автоматизации с облачным провайдером непрерывной интеграции, создании CI-среды и ее подключении к Slack.
Эта статья является продолжением первой, в которой я рассказывал об основах Cucumber BDD с Selenium и Java.
Без лишних слов, let’s CI, что я подготовил сегодня.
Чтобы быстро продвигаться в рабочих задачах, необходимо иметь уверенность в том, что можно вносить изменения. А уверенность в изменениях зависит от тестового покрытия.
С тех пор как мы это поняли, автоматические тесты стали просто необходимы. Это привело к массовому внедрению шаблонов для старта работы. Однако просто начать работу недостаточно.
Привет! Меня зовут Лев Палей, и я собаку съел на всяких сравнениях, технико-экономических обоснованиях и всей этой истории с выбором каких-либо решений. Теперь я работаю по другую сторону сделки. Поэтому, после некоторого времени, проведенного в компании-производителе, решил рассказать о тяготах выбора WAF, как историю из тех времен, когда сам был заказчиком и с учетом всякого нового, что начал понимать теперь. Раньше я не мог много об этом рассказывать (не было времени), а сейчас готов поделиться своим двусторонним опытом. Если перед вами стоит задача ........ велком под кат за подробностями.
Часть 2. Одно дело про WAF говорить – другое дело WAF считать!
Всем привет! Сегодня я хочу рассказать о Mock Service Worker — технологии, которая позволяет эмулировать поведение бэкенда в ситуациях, когда по каким-то причинам невозможно использовать реальный бэкенд для полноценной разработки фронтенда, а также когда необходимо изолированно протестировать различные пользовательские сценарии. Тем более, что совсем недавно вышла новая мажорная версия библиотеки msw, и в ней достаточно много важных обновлений.
Качество программного продукта — важный критерий. Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь. Как правило, у каждого члена команды свое представление о качестве. Это связано с тем, что в оценке в большей степени учитываются субъективные мнения. Правильнее сказать, что качество представляет собой набор критериев или параметров. И этот набор может отличаться в зависимости от личного опыта или профессиональной деятельности участника команды: пользователя, разработчика, тестировщика, аналитика, заказчика или др.
Mountebank - это мощная платформа для тестирования API и mocking-a, предоставляющая пользователям функционал и инструменты для создания гибких, настраиваемых и надежных тестовых окружений. В этой статье автор рассмотрит настройку Mountebank на реальном примере.
Коллеги, все желаю хорошего дня.
Хочу предоставить коллекции в Postman и Insomnia, построенные на основе написанных тест-кейсов по API.
Привет, Хабр! Меня зовут Ирина Иванова, я работаю QA-инженером в команде разработки внутренних проектов в Учи.ру. Мы занимаемся такими сервисами, как виджет поддержки, личный кабинет сотрудников пользовательской поддержки, карьерный сайт и так далее.
Все проекты разные, у них разные задачи. И трудности, с которыми приходилось сталкиваться во время работы над ними, тоже были разными. Но одной из повторяющихся проблем стало застревание фич на этапе контроля качества, неравномерная нагрузка на инженера по тестированию и, как следствие, замедление скорости релизов. Ниже я расскажу, какое мы нашли решение.
Привет! Меня зовут Лев Палей, и я собаку съел на всяких сравнениях, технико-экономических обоснованиях и всей этой истории с выбором каких-либо решений. Теперь я работаю по другую сторону сделки. Поэтому, после некоторого времени, проведенного в компании-производителе, решил рассказать о тяготах выбора WAF, как историю из тех времен, когда сам был заказчиком и с учетом всякого нового, что начал понимать теперь. Раньше я не мог много об этом рассказывать (не было времени), а сейчас готов поделиться своим двусторонним опытом. Если перед вами стоит задача ........ велком под кат за подробностями.
Протестировать позитивные сценарии использования API можно легко и быстро, используя JSON схему. В этой статье мы поговорим о полезных приемах, хитростях, которые можно применить для ускорения процесса, и об источниках данных для такого тестирования. Излагать буду “для самых маленьких” - если хотите быстро подтянуть JSON схемы в свой проект и готовых онлайн-генераторов вам мало, но вы не планируете погрязнуть в чтении документации, добро пожаловать под кат.