Что делать, когда селедку под шубой уже доели, а за работу садиться еще рано?

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

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

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

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

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

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

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

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

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

Приступим!

Слой API любого приложения - один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые  приносят пользу пользователям. 

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

Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API - вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться - Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами - прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать...

Всем привет! Меня зовут Леша, я фронтенд-разработчик. Крашу кнопочки, пишу js скрипты, веду канал в TG https://t.me/frontend_tales (подписывайтесь, стараюсь выкладывать полезный материал).

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

Привет! Меня зовут Сергей, я бэкенд разработчик команды SEO в Банки.ру.
В этой статье хочу описать свое знакомство с техникой Trace Based Testing (TBT): 

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

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

Протестировать позитивные сценарии использования API можно легко и быстро, используя JSON схему. В этой статье мы поговорим о полезных приемах, хитростях, которые можно применить для ускорения процесса, и об источниках данных для такого тестирования. Излагать буду “для самых маленьких” - если хотите быстро подтянуть JSON схемы в свой проект и готовых онлайн-генераторов вам мало, но вы не планируете погрязнуть в чтении документации, добро пожаловать под кат.

Здравствуйте вам каждому. Мы — Дмитрий и Павел, специалисты по тестированию в ITFB Group. В нашей работе, как и у любого тестировщика, есть много рутинных, однотипных задач. Делать их не хочется, но без них нельзя. К счастью, нам теперь могут помогать генеративные нейросети.

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

Приглашаем под кат почитать про наш опыт.

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

Меня зовут Вячеслав Смирнов, я ускоряю и тестирую инфраструктурные сервисы в Miro. Ещё я развиваю сообщество нагрузочников в telegram: делюсь там кое-какой экспертизой. В частности, если выполнять тесты производительности регулярно, по несколько раз в день, то вскоре в популярном хранилище тестов InfluxDB фильтровать результаты тестов производительности становится сложно. Сегодня я расскажу про 12 шагов, как можно ускорить InfluxDB. Основным из них является ускорение с помощью nginx кэширования. Пример использования кэширующего nginx, в качестве источника данных для Grafana можно найти тут. Все остальные примеры, которые мы будем разбирать я вынес сюда. А слайды оставил здесь.

Обеспечение надежного функционирования системы при развертывании обновления системы требует запуска тестов разного уровня - от модульных тестов отдельных компонентов до интеграционных тестов, проверяющих в staging-окружении работу системы в целом. Но не менее важны для оценки готовности системы к большой кратковременной пиковой нагрузке (или злонамеренным атакам) выполнение нагрузочных тестов. В июле 2021 года компания Grafana Inc приобрела продукт k6, который изначально был ориентирован на запуск высокопроизводительных распределенных нагрузочных тестов, и это положительно повлияло на его дальнейшее развитие как встраиваемого инструмента для запуска тестов в облачных инфраструктурах или Kubernetes. В этой статье мы рассмотрим один из возможных сценариев использования k6 для тестирования сервиса в конвейере CI/CD.

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

И так. Началось все с достаточно невинной просьбы архитектора моего проекта — «Денчик, смотри, нужно взять все задачи, сделанные в этом спринте — то есть с версии 0.0.1.01 до версии 0.0.2.01 и выписать в статью».

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

Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =) 

Данная статья поможет разобраться в нюансах настройки секретов HasiCorp Vault и NET приложения в Kubernetes.

После весны 2020 года слово “тестирование” приобрело некоторые неожиданные значения и неоднозначные коннотации — пожалуй, везде, кроме IT. В нашей сфере без него никуда — и так было всегда.

Видов тестирования ПО — множество: модульное, функциональное, А/В-тестирование, интеграционное, нагрузочное и т д. И на наш взгляд, как раз последнее является как самым важным, так и наиболее сложным. Ведь если ошибки, которые могут быть выявлены с помощью A/B-тестов, модульных, функциональных и интеграционных тестов, проявляются практически сразу после “выкатки” новой версии приложения, то проблемы, на выявление которых нацелено нагрузочное тестирование, — “спящие”. И обнаруживаются они только тогда, когда на новую версию вашего сайта или приложения придет реальный пользовательский трафик, с которым не справится “софтверная” часть проекта (база данных, application-сервер) или “железно-инфраструктурная” (нехватка оперативной памяти в кластере, большая нагрузка на дисковую подсистему при операциях чтения-записи).

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

В прошлой статье: QA Lead и точка: Часть 1 мы обсуждали, что QA лиду необходимо развивать T-shape компетенции для комфортного взаимодействия с другими отделами. Более того, важно не забывать про актуальность навыков, связанных с основной специализацией, ведь, как мы знаем, в IT информация устаревает очень быстро и нужно быть готовым к регулярному обучению длиною в жизнь. В то же время было упомянуто, что QA Lead много времени посвящает коммуникациям, планированию, менторингу. Встает вопрос: «как и когда развивать свои основные технические навыки, не говоря уже о развитии в ширину по смежным направлениям?». В этой статье обсудим, какие форматы обучения бывают, и сопоставим их с широко известными четырьмя этапами обучения.

Всем привет! Хочу рассказать о прохождении собеседования в Тинькофф, где я решила попробовать свои силы, несмотря на несколько этапов отбора.