TestGrow - pruebas de software

ИДЕМПОТЕНТНОСТЬ В API: ЗАЧЕМ НУЖНА И КАК ПРОТЕСТИРОВАТЬ РУКАМИ Всем привет! Сегодня хочу поговорить о понятии, которое часто встречается в спецификациях API, но не всегда понятно тестировщику без технического бэкграунда. Речь про идемпотентность. Идемпотентность - это свойство операции, при котором повторный вызов метода даёт тот же результат, что и первый. Простой пример из жизни: выключатель света. Если он уже выключен, то сколько бы вы ни жали «выкл», то лампочка останется все равно погашенной. В API это важно, потому что запросы в реальной жизни могут теряться, дублироваться или повторяться из-за сетевых проблем. И если каждый повтор будет менять данные, то последствия могут быть серьезными. Примеры: ⁃ DELETE /user/123 → пользователь удалён. Если вызвать повторно, система должна вернуть «пользователя уже нет», а не падать или создавать что-то новое. ⁃ PUT /user/123 {name: “Александр”} → имя изменилось на Александр. Повторный запрос должен оставить всё как есть. ⁃ А вот POST /order обычно не идемпотентен, потому что каждый вызов создаёт новый заказ. Как тестировать идемпотентность вручную: 1. Найти в документации методы, которые по определению должны быть идемпотентны (чаще всего GET, PUT, DELETE). Кстати иногда разработчики делают и POST идемпотентным (чаще всего через Idempotency-Key), например в платежным системах, так стоит уточнять этот момент. 2. Сделать запрос и зафиксировать результат. 3. Повторить этот же запрос несколько раз. 4. Проверить, что состояние системы не меняется после первого успешного вызова. 5. Дополнительно проверить логи и базу (если есть доступ), чтобы убедиться, что дубликатов не появилось. Почему это важно тестировать? Потому что при реальных сбоях (например, потеря пакета или таймаут) клиент может отправить один и тот же запрос несколько раз. И именно идемпотентность спасает бизнес от дублирования заказов, списания денег дважды и прочих подобных багов. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

БАГ, КОТОРЫЙ «САМ ПОЧИНИЛСЯ» Всем привет! Так как большинство проголосовало за практические кейсы, то буду стараться побольше об этом писать. Сегодня хочу поговорить о ситуации, знакомой, думаю, каждому тестировщику. Ловишь баг, описываешь шаги, делаешь скриншоты, собираешь логи. А потом запускаешь тест заново, и, там тадам, бага нет. Сервис работает идеально. Что это вообще было?🤔 Такие «мистические» баги случаются чаще, чем кажется, и у них есть вполне земные причины: ⁃ Многопоточность. Два процесса обращаются к одним и тем же данным почти одновременно. В первый раз система не справилась, во второй — уже всё ок. ⁃ Нестабильное окружение. Например, проблемы с сетью, временный сбой внешнего сервиса или база, которая «подвисла» на секунду. ⁃ Кэш и асинхронность. Иногда баг проявляется только при первом запуске, пока система прогревает кэш или подтягивает данные. ⁃ Тестовые данные. Если баг завязан на конкретное состояние БД или API-ответа, он может исчезнуть после одного прогона. ⁃ Скрытый багфикc. Разработчик мог выкатывать хотфикс на прод (или даже в тестовую среду), не предупредив никого. Почему такие баги опасны? Потому что они «призрачные» и разработчики часто относятся к ним скептически: «Не воспроизводится? Значит, и нет бага». Но мы-то знаем, что случайность в IT часто становиться закономерностью. Что я советую делать тестировщику: ⁃ фиксировать всё максимально подробно (логи, скриншоты, если необходимо запись видео); ⁃ пробовать воспроизвести на разных окружениях; ⁃ проверить зависимости (база, сторонние сервисы, кэш); ⁃ заводить баг-репорт, даже если воспроизводимость низкая — с пометкой плавающий дефект. Мой личный опыт: такие баги чаще всего «возвращаются» позже, а иногда уже в проде, и тогда у команды уходит в разы больше времени на расследование. Поэтому лучше зафиксировать эту странность сразу, чем закрыть глаза и надеяться, что она не повторится. А у вас было такое, что баг «сам починился»? Как вы действуете в таких ситуациях? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

ПОЧЕМУ SWAGGER-ДОКУМЕНТАЦИИ НЕ СТОИТ СЛЕПО ДОВЕРЯТЬ В последнее время в нашем проекте Store Manager мы часто обсуждаем Swagger-документацию и её роль в тест-аналитике. Решил вынести этот вопрос сюда, потому что вижу: многие тестировщики не понимают, как устроен Swagger и работают с ним как с требованиями. Но это не так. Swagger документация — это не требования, которые мы видим в конфлюенс или еще где-то, а обетка для написанного кода, который пишет именно разработчик и что важно, Swagger документация генерируется из кода. А разработчик, это человек. У него свои дедлайны, свои задачи и, как правило, если он допустил ошибки в API, то эти ошибки перенесутся в Swagger. Что еще может пойти не так: Неактуальность. Разработчик обновил код, но забыл поправить описание в Swagger. В итоге документация «живёт» своей жизнью. Упрощения. В Swagger часто описывают happy path. Ошибки, edge cases, нестандартные сценарии могут быть не отражены. Человеческий фактор. Ошибки в описании типов, обязательных полей, кодов ответа встречаются чаще, чем кажется. Скрытые детали. Иногда Swagger описывает «идеальную» картину, а на деле сервис требует дополнительные заголовки, токены, хитрые параметры. Поэтому важно помнить, что Swagger — это удобный помощник, но не «требования» в прямом их понимании. Системные и бизнес-требования всегда приоритетнее. Если они расходятся со Swagger, доверять нужно требованиям. Swagger — отличная точка входа. Но слепое доверие к нему может стоить того, что если в сгенерированном из кода Swagger документации ошибка, то вы и протестируете сервис с этой ошибкой положительно, не найдя ее по факту. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет! Сегодня хочу рассказать вам немного о личном, а именно, недавно я писал пост, что активно начал погружаться в робототехнику и сейчас работаю над тем, чтобы самостоятельно построить своего робота. Пока концепт такой, сделать робота на колесах, сверху поставить робо руку, добавить в него искусственный интеллект и научить его как разпознованию и ориентации в пространстве, так в и выполнение каких-то базовых вещей, например, что-то принести и т д. Немного о том, почему я решил этим заняться. Тут не просто хоби, я активно слежу за тем, как меняется мир и какие знания могут быть востребованы в будущем, поэтому два года назад я активно начал изучать ИИ, теперь вижу, что помимо ИИ нас ждет еще достаточно глубокое проникновение роботов на базе ИИ в нашу жизнь, поэтому, чтобы бы в курсе технологии, я и решил построить своего первого робота. На текущий момент пока завершил каркас, шасси, подключение основных датчиков контроля дистанции. В целом самым неожиданным для меня было, что болшую часть времени тратиться не на программирование (тут кстати пока не так все сложно), а на конструирование и проектирование именно каркаса самого робота. В итоге пришлось много пилить, сверлить, паять, чтобы работало корректно. Второе, это изучение основ работы электроники, что тоже очень важно. Ну а детали все заказны из Китая, робот будет функционировать на Rasberry PI плате с процессором и двумя платами Adruino для подключения датчиков и прочего. В общем впереди еще много чего интересного, буду делиться с вами новостями. Если есть какие-то вопросы, пишити в комментариях 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Всем привет! Сегодня хочу поделиться с вами новым крутым брендом одежды. Эти ребята создают одежду специально для IT-сферы и реально продумали каждую деталь. It-бренд Rybe не просто одежда — удобный интерфейс для жизни. Где тестировщик всегда на страже, чтобы всё было correctly. Ребята добавили классные детали к одежде, которые делают жизнь проще: • люверсы под пропуск, • карман с отделением для наушников, • салфетка для экрана и очков, • 100% премиум-хлопок, который дышит, не скатывается и не теряет форму. Универсальная посадка. Плотная ткань. Меньше багов в жизни — больше времени на их поиск в коде. В общем, заказывайте, дарите, носите Ознакомится с ассортиментом можно тут: Ссылка скрыта Ну а тут я уже присмотрел себе худи для тестировщика Rybe tg: @rybe_store

6 СТИЛЕЙ API: ЧТО НУЖНО ЗНАТЬ ТЕСТИРОВЩИКУ? Сегодня хочу разобрать основные стили API, с которыми может столкнуться тестировщик. У каждого свои особенности, и подходы к тестированию кардинально отличаются. Классную гифку взял у Ссылка скрыта REST API: Самый популярный. Работает через HTTP методы, использует JSON. Проверяем HTTP методы (GET, POST, PUT, DELETE), коды ответов, валидацию JSON, заголовки, параметры запросов. SOAP: Старый, но живучий. Использует XML и строгие контракты через WSDL. Часто встречается в финансовых организациях и крупных корпорациях. Тестируем XML envelope структуру, WSDL контракты, обработку ошибок, namespace корректность, WS-Security если есть. GraphQL: Один endpoint, гибкие запросы. Можешь запросить только нужные поля или связанные данные. При тестировании важно проверять queries, mutations, subscriptions и работу слишком сложных запросов. gRPC: Быстрый и компактный, использует Protocol Buffers вместо JSON. Популярен в микросервисах для внутреннего взаимодействия. Тестируем binary Protocol Buffers, streaming (одиночную, серверную, клиентскую, двустороннюю), метаданные, коды состояния, таймауты. WebSockets: Двусторонняя связь в реальном времени. Не request-response, а постоянное соединение. Проверяем установку соединения, ping/pong, кадры сообщений, жизненный цикл соединения, переподключение, поток событий в реальном времени. MQTT: Лёгкий протокол для IoT устройств. Работает через брокер сообщений с топиками и подписками. Тестируем публикацию/подписку, QoS уровни (0,1,2), сохранённые сообщения, соединение с брокером, шаблоны топиков. Инструменты: В целом со всеми технологиями можно рабоать через Postman, но также существуют и специальные инструменты под каждый тип. С какими стилями API работали? Какой показался самым сложным для тестирования? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

CHATGPT STUDY MODE: КОНЕЦ ЭПОХИ QA КУРСОВ? Всем привет! Чуть больше недели назад OpenAI анонсировали Study Mode режим в ChatGPT, который не даёт прямые ответы, а задаёт вопросы и ведёт к решению пошагово. И я думаю, это может серьёзно изменить всю индустрию обучения. Что такое Study Mode. Вместо готовых ответов ChatGPT становится наставником, который задает наводящие вопросы, подстраивается под ваш уровень и помогает разобраться самостоятельно в изучаемом предмете. Включается одной кнопкой в интерфейсе. Почему это может изменить обучение? Во-первых, это персонализация. Study Mode калибруетобучение под ваши цели и уровень навыков. Если попросить объяснить API тестирование новичку, то он выдаст простые аналогии, если спросить про сложные SQL запросы, то даст задачки по нарастающей сложности. Во-вторых, это постоянная доступность. Study Mode работает круглосуточно как персональный наставник. Не нужно ждать следующего урока курса или ответа преподавателя, потому что можно изучать тестирование в любое время, когда появилось желание или вопрос. Внутри для обучения ChatGPT использует сократический метод, а именно Study Mode задает вопросы и отвечает, предлагая подсказки для саморефлексии. Что это значит для курсов QA? Многие курсы дают или имеют готовые ответы и шаблоны в обучении. Study Mode учит думать. Если студент просит прямой ответ, ChatGPT напоминает, что самостоятельная проработка -это лучший способ изучения и будет стараться подвести вас к ответу наводящими подсказками. Например, если попросить Study Mode научить меня тестированию GraphQL. Вместо лекции он спросит: "Работал ли ты с REST API? Что знаешь про базы данных?". Потом пошагово объяснит разницу, даст практические задания и проверит усвоение материала. OpenAI планирует интегрировать это поведение прямо в основные модели после получения обратной связи и проведения бета тестов То есть это только начало. Думаю, скоро увидим: - Постепенное падение спроса на типовые курсы - Рост персонализированного обучения - Изменение роли преподавателей QA Study Mode пока работает только на английском, но это вопрос времени. Ссылка на релиз Study Mode Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

CORS В API: ПОЧЕМУ БРАУЗЕР БЛОКИРУЕТ ЗАПРОСЫ И КАК ЭТО ПРОВЕРИТЬ? Сегодня хочу вам рассказать про CORS технологию, ошибки в которой часто ставят в тупик тестировщиков. Особенно когда в Postman всё работает, а в браузере — ошибка. Простыми словами CORS - это защита браузера, которая блокирует запросы между разными доменами, портами или протоколами для защиты пользователей от потенциально опасных скриптов. Например, сайт mysite.com не может просто так обратиться к API на api.company.com. Чаще всего в браузере вы можете получить такую ошибку "Access to fetch at... has been blocked by CORS policy" Когда срабатывает CORS: - Разные домены: site1.com → site2.com - Разные порты: localhost:3000 → localhost:8080 - Разные протоколы: http:// → https:// - Разные поддомены: api.site.com → site.com Почему в Postman работает, а в браузере нет? Postman и curl не являются браузерами, поэтому CORS их не касается. А вот JavaScript в браузере — да. Основные заголовки, которые нужно проверять: Access-Control-Allow-Origin, кому разрешено делать запросы: - * (звездочка) означает, что разрешены запросы с любых доменов - Ссылка скрыта — только конкретному домену - отсутствие заголовка блокирует все cross-origin запросы Access-Control-Allow-Methods, определяет, какие методы разрешены для использования: - GET, POST, PUT, DELETE и т д Access-Control-Allow-Headers, определяет, какие заголовки можно передавать: - Content-Type, Authorization и т д Что обязательно тестировать: - Работают ли запросы с фронтенда на нужный домен - Приходят ли правильные CORS заголовки в ответе - Работает ли preflight запрос (OPTIONS) для сложных запросов - Передаются ли cookies, если нужно Как тестировать: Самый простой способ — открыть DevTools в браузере, и сделать нужны запрос в приложении. Если увидите ошибку про CORS — значит что-то не настроено на сервере и это ошибка. Чтобы упростить себе работу, можно включить в браузере опцию "Preserve log" в DevTools, чтобы видеть все запросы, включая preflight. А вы сталкивались с проблемами CORS? 👇 Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний

Немного о наболевшем. Сегодня я хотел бы поделиться своими мыслями касаемо платформы TestGrow. Этот пост у меня родился из-за того, что я читаю комментарии, которые пишут на платформе и у меня складывается ощущение, что те ребята, кто проходят задания думают, что это мой бизнес, на котором я зарабатываю деньги и за которым стоит большая команда. Вот примеры пары комментариев: “Я хочу просто стать средним айтишником и получать 200к. Зачем мне эти ребусы отгадывать целыми днями скажите? 15% пройдено ИЗ БЕСПЛАТНОГО у меня уже отвращение. В ПЛАТНОМ тогда что? Разгадать тайну кольца и заклятие Саурона?” “Классный ролик! Но есть очепятка. Тайминг 1.13, Строчка "В эти тяжёлый времена на". Должно быть "В эти тяжёлые времена на” “Вообще не согласен с логикой выставления серьезности ошибок в 39 задании. Почему при том, что мы не может зарегистрироваться без отчества (хоть этого и нет в требования) это не высокая серьезность бага?” И таких комментариев очень много! Что я хочу сказать по этому поводу. 1. Testgrow не является моим бизнесом и не приносит мне никаких денег, более того, я ежегодно трачу свыше 150к рублей только на поддержку платформы, которые мне вообще никак не окупаются. Поэтому платформа живет как она есть с минимальным участием с моей стороны. 2. Большая часть практики бесплатна, лекции тоже бесплатные, но я сейчас никак не поддерживаю платформу, потому что - я один, у меня нет никакой команды или еще кого-то, кто бы этим занимался (почему, смотрите пункт 1). Поэтому вы получаете бесплатный курс с практикой и потом пишите, что она сложная, вы не можете пройти задания и так далее. Мой ответ тут такой, свыше 500 человек закончили данный практикум, значит задания пройти можно, если вам сложно проходить задания, я ни кого не держу, найдите другие курсы, которые будут вам проще. 3. В-третьих, структура заданий, да и сами задания не должны быть легкими, потому моя цель - научить учеников включать голову и анализировать, а не просто проходить тесты, если вам сложно с этим, возвращается к пункту 2. 4. Да, на платформе есть опечатки, потому что я человек, а не робот, при этом с учетом того, что созданного мною контента достаточно, чтобы написать полноценную книгу по тестированию страниц на 150, то 5-10 ошибок на весь курс - для меня не критично, если вам это режет глаз, то возвращаемся к пункту 2. В целом меня всегда удивляет, когда ты вкладываешь свое личное время, ресурс, деньги для создания бесплатного курса, а в итоге, ученики пишут, что им не нравится, сложно, находят какие-то ошибки или пишут комментарии в стиле “Курс для тестировщиков, а текст не протестирован, грамматические и пунктуационные ошибки”, у меня если честно вызывает это удивление. Если вам хочется идеальные курсы, пожалуйста, покупайте их за +100к, где копирайтеры вычитали все и исправлили ошибки и учитесь) И относитесь с уважением к авторам бесплатного контента, потому что не только я, но и другие ребята делают достаточно много, чтобы профессия тестировщика была доступна для всех. Все мои проекты: TG канал по тестированию AI | Youtube channel | Практика по тестированию | Платформа TestGrow | Автоматизация тестирования | Курс по тест-менеджменту | База знаний