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

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

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

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

Приступим!

Слой 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 много времени посвящает коммуникациям, планированию, менторингу. Встает вопрос: «как и когда развивать свои основные технические навыки, не говоря уже о развитии в ширину по смежным направлениям?». В этой статье обсудим, какие форматы обучения бывают, и сопоставим их с широко известными четырьмя этапами обучения.

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

Что вообще такое, эта матрица компетенций?

Как ее использовать QA менеджеру?

Как ее строить?

Зачем ее строить?

Причем тут грейды?

Все это мы узнаем в этой статье, без душных терминов (почти).

Давай определим, зачем это вообще нужно?

Эта статья рассказывает о том, как можно тестировать документацию и вероятно кому то поможет сделать этот процесс в своей команде более качественным

Знакомьтесь: успешная компания, которая решила двигаться в ногу со временем и автоматизировать свои процессы с помощью low-code платформы. После тендера и заключения договора с исполнителем, она нашла опытного интегратора и ушла создавать идеальное ТЗ. После года напряжённой работы, когда множество деталей было учтено и всё казалось готовым к запуску,  вступила в игру реальность: приоритеты компании изменились, бюджет был пересмотрен, а идеальное ТЗ уже не отвечало актуальным потребностям. И таких примеров — множество.

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