Всем привет! Я Светлана Кирдяйкина, старший инженер по тестированию в Авито. Если вы задумываетесь про оптимизацию своего времени и улучшении тестирования — эта статья точно будет вам интересна. Здесь я постаралась простым языком описать факторы, на которые стоит обратить внимание перед тем, как начинать автоматизацию.
Когда мы в NTechLab первый раз задумались о проведении нагрузочных тестов для наших продуктов, выбор инструмента для нас был очевиден: JMeter имел мощное комьюнити, обширный набор доступных плагинов и возможность написать свой при необходимости. Немаловажным фактором стало и то, что в интернете масса статьей о том, как начать работать с JMeter.
Однако, очень скоро мы столкнулись с ситуацией, когда количество кейсов нагрузочного тестирования разрослось, а написанные нами скрипты в JMeter стали напоминать нагромождение бессвязных элементов. С каждым релизом поддерживать тестовый набор таких скриптов становилось всё сложнее. Сюрпризом стало и то, что несмотря на большое количество статей посвященных старту работы с JMeter, статей которые бы рассказывали о том как грамотно развивать нагрузочные тесты в JMeter — не нашлось.
Мы в NTechLab проводим много нагрузочных тестов для своих продуктов и в этой статье расскажем какими трюками пользуемся, чтобы наши JMeter тесты всегда были легко поддерживаемыми и читаемыми, а регрессионное нагрузочное тестирование продуктов не становилось пыткой.
В современном программном обеспечении присутствует множество багов. Какие-то из них влияют на безопасность, какие-то на работоспособность, но есть отдельная категория, которую я называю «Веселые баги». Они не влияют на других пользователей и на работоспособность системы в целом, но могут доставить множество эмоций тому, кто их использует, а также тем, кто наблюдает за получившимся результатом.
Все началось пару дней назад, когда ко мне в предложку ВК попал мой первый руководитель, с которым мы не виделись уже несколько лет. Перейдя в профиль, я увидел, что он учился в Сомалийском Университете Пиратства и Абордажного Судозахвата. Мы всегда пользовались и пользуемся лицензионным ПО, поэтому я сразу смекнул, что ни на какого пирата он не учился. Дальше я попробовал через веб-интерфейс в своем профиле поставить такое же высшее образование, но такого университета в списке доступных не нашлось... Но откуда тогда взялся университет пиратства?
Статья кратко описывает основные концепции и преимущества использования лямбда-выражений в Java, а также их применение в сочетании с функциональными интерфейсами и новыми возможностями, такими как stream() и ссылки на методы. Она будет особенно полезна начинающим тестировщикам-автоматизаторам, знакомящимся с современными подходами к работе с кодом.
В этой статье мы рассмотрим, что такое тестирование производительности, рассмотрим несколько подходов, которые можно использовать для лучшего понимания того, как приложение ведёт себя при различных уровнях нагрузки. Мы также познакомимся с K6 — мощным инструментом для тестирования производительности, специально разработанным для современных процессов разработки, и продемонстрируем его использование на примере. Этот инструмент предлагает очень удобный опыт для пользователей, обладающих базовыми знаниями JavaScript или TypeScript, значительно упрощая процесс тестирования производительности.
Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!
JavaScript и Node.js имеют множество библиотек тестирования и утверждений, таких как Jest, Jasmine, Qunit и Mocha.
В этой статье мы рассмотрим, как использовать Mocha для тестирования, Chai для утверждений и Sinon для моков, шпионов и стабов.
Привет всем! В этой статье мы собрали для новичков подборку фреймворков для автотестирования. Вы найдёте здесь подсказки, на что опираться при выборе, а также сводку некоторых достоинств и недостатков.
Фреймворк для автоматизации тестирования — это инструмент, экономящий время разработчикам, которым необходимо тестировать функциональность и надёжность программного обеспечения. Автоматизируя повторяющиеся, трудоёмкие задачи, такие как тестирование потоков входа и поведения меню, фреймворки могут выявлять проблемы на ранних этапах процесса разработки, а это в значительной степени способствует повышению общего качества конечного продукта.
Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд.
В этой статье хочу поделиться опытом нашей команды: с какими проблемами мы столкнулись при оценке задач QA, какие подходы пробовали, и какой метод в итоге стал для нас наиболее эффективным.
Сразу уточню: я не претендую на универсальность предложенного метода. Этот подход успешно работает в рамках наших процессов, но это не значит, что он подойдет всем без исключения.
Методы я решил подробно не описывать, так как их описание можно легко найти в открытых источниках. В данном материале я сделал акцент на правильное сочетание, своевременность применения и нюансы использования этих подходов. Если вам интересно узнать больше о каждом из упомянутых методов, рекомендую ознакомиться с их описанием в этой статье: TestGrow.
Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки «на глаз» оказывались неточными. Ведь если заложить слишком много рисков — в продакшен попадут не все задачи, а если их не заложить — есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.
Интеграционные тесты, написанные программистом — это отличный способ обеспечить уверенность в своём веб-сервисе.
В мире .NET для разработки веб-сервисов обычно используют ASP.NET Core, но интеграционное тестирование часто упускают из виду либо делают не очень качественно.
Статья покажет полноценный подход к организации интеграционных тестов на языке Gherkin для API-сервиса, написанного на C# 12 с ASP.NET Core 8 и использующего PostgreSQL.
Тестирование ПО — не магия, а ремесло. Но даже у самых опытных мастеров случаются промахи. Какие ошибки подстерегают тестировщиков на пути к качественному продукту? Давайте разберем их, добавив к каждой ситуации реальные примеры.
Всем привет! Меня зовут Найля, и я инженер по обеспечению качества в Т-Банке на одном из внутренних сервисов. Занимаюсь ручным и автоматизированным тестированием на проекте. Расскажу о том, как мы написали API-тесты с использованием фейков, что это такое и когда стоит отдать предпочтение им, а не мокам.
Долгое время у нас были только юнит-тесты, написанные разработчиками, и небольшое количество UI-тестов с использованием внутреннего фреймворка компании. На другие виды тестов на тот момент было недостаточно компетенций. Но время шло, и все больше всплывала потребность менять автоматизацию тестирования на проекте.
Всем привет! Недавно решил попробовать, что из себя представляет Flutter Web, подумал, может попробовать сделать бота для Telegram, и заодно настроить простейший CI/CD для отдельного фронтенд- и бэкенд-проектов. Однако в интернете я не нашёл простой и исчерпывающей инструкции или процесса.
Поэтому задача этой статьи — решить эту проблему! Сделать автоматическую сборку, тестирование и деплой на сервер, и всё это — без необходимости городить SSH-ключи, Github-токены и подключать сторонние решения. Всё на минималках, без лишней бюрократии.
Одной из самых раздражающих проблем, с которыми я сталкивался за последние 25 лет в индустрии, являются нестабильные тесты (flaky tests) — тесты, которые чаще всего проходят, но иногда необъяснимо завершаются ошибкой без явных на то причин. Вы отправляете код в репозиторий, а через двадцать минут получаете уведомление о том, что набор тестов завершился ошибкой. Вам приходится бросать всё, чем вы занимались, чтобы разобраться в причине сбоя. В итоге вы приходите к выводу, что причина явно не в ваших изменениях, и прибегаете к старому как мир трюку — запускаете тест повторно. На этот раз тест проходит успешно, и вы думаете: «Опять нестабильный тест… Ну ладно». И возвращаетесь к более важным задачам.
Как и многие, я, как мог, сопротивлялся Test-Driven Development. Я не понимал, почему тесты нужно писать перед реализацией. Почему мы должны выворачивать разработку наизнанку и переворачивать естественный, как мне тогда казалось, процесс, с ног на голову.
Но, так или иначе, разработка через тестирование настигла и меня. Да, до сих пор получается не идеально, но значимость модульных тестов сейчас мне видится неоспоримой.
И об этом мы поговорим в статье ниже.
Мы разберём страхи, останавливающие разработчика перед тем, чтобы начать, наконец, писать тесты. Выявим очевидные преимущества. Обсудим основные правила разработки через тестирование. И подкрепим всё это реальными примерами.
Приветствую! Сегодня расскажем вам про то, как реализовать Mock-серверы в Postman.
Mock-серверы позволяют имитировать поведение реального API. Т.е можно продолжать разработку своего приложения, даже если реальный сервер еще не готов или недоступен.
JSON — один из самых распространённых форматов данных, используемых для передачи и получения данных в современных API. Важно глубоко понять его.
В этой статье я даю краткий обзор: в основном это структура данных вида key: value, содержащая примитивные типы данных, такие как строка, логическое значение, числа, а также массивы. JSON очень похож на словарь в Python.
Привет, меня зовут Александр (aka bytehope). Прежде чем прийти к багхантингу, я пять лет занимался коммерческой разработкой. Однако меня всегда больше интересовал поиск уязвимостей, поэтому сейчас свое свободное время я провожу на площадках багбаунти.
Эту статью я решил посвятить уязвимостям, связанным с недостатками контроля прав (Broken Access Control). Вы узнаете, что это очень распространенный баг, который может проявляться самыми разными способами. Конечно, особый акцент будет сделан на практике: я покажу, как отловить четыре разных вида этой уязвимости в лабах Web Security Academy. Начнем с самых простых примеров, поэтому статья подойдет для начинающих охотников. Смело заглядывайте под кат!
Однажды я задумался, почему одни QA-инженеры застревают в мидлах, а другие — дорастают до CTO. Я исследовал эту тему, проводил интервью и пришёл к определённым выводам, которыми готов поделиться.
Дисклеймер: везде, где далее будет использован термин «тестировщики», можно подставлять «разработчики», «аналитики» и даже «менеджеры», ведь скилл-нутриенты полезны вообще всем айтишным специалистам.
