
Раньше было лучше? Не уверен. Еще 10 лет назад я тестировал без ИИ: искал ошибки, писал отчеты, огребал от разрабов. А теперь — всё в 5 раз быстрее, и пока вам несут матчу на кокосовом, можно словить и починить баги. В статье — гайд + код.
Семь раз оттесть, один раз деплой
Раньше было лучше? Не уверен. Еще 10 лет назад я тестировал без ИИ: искал ошибки, писал отчеты, огребал от разрабов. А теперь — всё в 5 раз быстрее, и пока вам несут матчу на кокосовом, можно словить и починить баги. В статье — гайд + код.
В этой статье я хочу поделиться опытом, который накопил за годы работы с юнит-тестами в Angular. Вот о чём пойдёт речь:
- Почему важно писать юнит-тесты
- Зачем мокать зависимости и каковы плюсы и минусы
- Что такое SIFERS и почему это важно
- Что такое Angular Testing Library (ATL)
- Как тестировать с помощью SIFERS
- Как получать элементы DOM и генерировать события
- Что такое jest-auto-spies и observer-spy
Большинство серьезных сбоев в системах хранения данных происходят не из-за глобальных катастроф, а из-за незаметных повторяющихся отказов, на которые никто не рассчитывал: перегруженный контроллер, зависание диска, сбой питания в неподходящий момент. Такие ошибки не поймать быстрыми и однократными тестами. В целом, надежность системы хранения данных невозможно проверить абстрактно — только вживую, на реальном железе, часами, с полным погружением в нагрузку и нестабильность.
Я Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. Моя задача — не просто проверить, что СХД работает, а воспроизвести реальные риски отказа системы и проверить ее на устойчивость: высокая нагрузка, внезапные отказы компонентов системы, нестабильные внешние условия, например перебои в сети. В этом тексте расскажу, как мы тестируем отказоустойчивость СХД TATLIN.UNIFIED: какие сбои моделируем, как устроены автотесты и почему короткие прогоны не справляются с поиском критичных багов.
Мне нравится наблюдать за менторами, которые учат быть независимыми в тестировании и слать всех нафиг т.к. тестирование это не поиск багов, а сравнение ожидаемого результата с фактическим, и если нет требований, то и сравнивать нечего!
Прекрасно, вам должны платить просто так! Ведь мы работаем только так как написано в ISTQB, а там много чего написано) И на заборе тоже написано...
Вам задают простой вопрос, почему вы пропустили баг на прод? Это обычный разбор полетов после релиза и нужно учится на своих ошибках, прежде чем стартанет следующий горящий релиз! И нам необходимо объяснить причину, которая скрывается не только в процессах тестирование, но и в процессах всей команды.
Привет, Хабр! Я Александр Зырянов, проектный менеджер TMS с открытым исходным кодом TestY. Сразу о главном: выложили в open source версию TestY 2.1.
Во-первых, подвезли любимую фичу всех разработчиков — темную тему. Дочитайте до конца, чтобы посмотреть, как выглядит интерфейс различных страниц. Во-вторых, совместно с командой технических писателей YADRO разработали удобную документацию, чтобы погрузиться в работу системы с головой.
Какие еще изменения ждут пользователей в TestY 2.1 — читайте под катом.
В 2025 году Java продолжает развиваться благодаря таким технологиям, как GraalVM и Project Loom. Язык становится более быстрым и эффективным инструментом для создания решений в сфере искусственного интеллекта, облачных нативных приложений, систем Интернета вещей и масштабируемых микросервисов. В этой статье рассмотрим ключевые тренды, поддерживающие актуальность Java в современной разработке программного обеспечения.
Команды по разработке ПО, работающие самостоятельно, используют более широкий набор инструментов, чем когда-либо прежде. В обычной команде по разработке ПО может быть двадцать или даже тридцать инструментов.
В этой статье мы обсудим набор инструментов для тестировщика, о том, как выбрать между проприетарным и открытым исходным кодом, а также разберем краткое упражнение по выбору инструмента.
Всем привет! На связи команда Take it easy. Название говорит само за себя: мы упрощаем жизнь другим командам в релизном цикле и повышаем эффективность производственного процесса.
В любой разработке много времени отнимает тестирование. Поэтому мы решили автоматизировать создание тестовых сценариев API, чтобы помочь тестировщикам. Применили ИИ-инструмент APISpecGen для анализа спецификаций новых API-требований, генерации соответствующих тестовых сценариев, обезличенных тестовых данных по схемам запрос/ответ и select-запросов с помощью GigaChat.
Еще раз про gomock и тесты. Практики как можно писать тесты быстро, сохраняя их качество, при этом не лить горючие слезы.
На тему построения системы автоматизации тестирования в рамках конвейера CI/CD написано немало различных публикаций. В этой статье мы хотим рассказать о том, как строился процесс тестирования одного продукта в реальной организации, какие сложности и ошибки возникали и как они решались.
В этой статье хочу поделиться, как мы с коллегами на проекте выстроили процесс по тестированию требований.
Предыстория
У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что‑то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.
За несколько итераций проведённых 1-to-1 я выяснила, что нам было бы удобно построить это следующим образом: разделиться на подкоманды согласно функционалу, который мы реализуем, и до груминга читать аналитику, разбираться, оставлять комментарии с вопросами в спокойной обстановке без строго ограничения по времени.
Когда Java-приложение внезапно начинает «подвисать», причина почти всегда кроется в прозаичных деталях: неоптимизированных циклах, неудачном выборе коллекций, забытом кэше или агрессивном GC. В этой статье — 10 практических техник, которые помогут выжать максимум из JVM без преждевременной микрооптимизации и шаманства. Только доказавшие свою эффективность подходы, которые реально работают в проде — от финтеха до высоконагруженных API.
Реальные шаги, не всегда прямые, но всегда насыщенные опытом — моя история о том, как я пришел в SM Lab и превратился в инженера, который теперь помогает другим начать свой путь в IT.
Всем привет! Меня зовут Павел, я технический лидер тестирования в Альфа-Банке в направлении мобильной разработки.
Хотел бы поделиться способами отправки отчетов в один агрегированный запуск Allure TestOps из нескольких Jenkins джоб. В статье описано два способа, как это сделать. Сразу хочу отметить, что через стандартный плагин withAllureUpload это сделать не получится или не получилось у меня. Может есть какой-то секретный способ, как с ним работать и/или как настраивать. Но в интернете и в документации Allure TestOps такого решения не нашел.
Всем привет, я Сергей Герасимов, а эта статья – моя шпаргалка для тестирования. Особенно полезна она будет начинающим тестировщикам, но я и сам буду использовать, чтобы не держать в голове значения всех кодов и причины их возникновения.
Да, у нас есть стандартные коды 400, 404, 500 и прочие популярные ошибки, но есть и куча других. Не знаю как вы, а мне периодически приходится выяснять, что значит та или иная http-ошибка и как их воспроизводить. А когда приходят задачи из категории «проверить логирование ошибок запроса ....», то иду гуглить, как их провоцировать.
Пусть эта статья закроет часть вопросов. Коллеги, добавляйте от себя советы в комментарии, чемподробнее — тем лучше.
Привет, Хабр. Меня зовут Антон, я работаю в группе нагрузочного тестирования ЮMoney и занимаюсь исследованием производительности. В статье расскажу про xk6-browser — что у нас было до него, какие у этого решения преимущества и метрики.
Дизайн-ревью —достаточно важная вещь, которая требует внимания, когда фронтенд-разработчик сверстал новую фичу, блок или целую страницу. Вовсе не для pixel perfect, который «как задизайнили, так и сверстали» — пиксель в пиксель. Pixel perfect в десктопе — это чушь, потому что нельзя сверстать так, чтобы с разных браузеров (привет, Safari) и разрешений всё смотрелось идеально. Но ошибки, которые сразу бросаются в глаза, сразу подмечаю, структурирую и обсуждаю это с разработчиком, может, появились какие-либо ограничения и прочее. Поэтому никогда не жалею время на дизайн-ревью и через DevTools сам проверяю то, что сверстал разработчик.
Все инструменты и функциональность, о которых пойдёт речь в этой статье, можно найти в браузере в «Инструментах разработчика» (клавиша F12 / Ctrl + Shift + I (на Windows) или ⌘ + ⌥ + I (на Mac), или клик правой кнопкой мыши в любом месте страницы -> Выбор пункта меню — «Просмотр кода страницы» (или «Исходный код страницы») — это и есть DevTools).
Основной элемент для работы с девтулзами — «Инспектор» (Ctrl + Shift +C на Windows и ⌥+⌘+I на MacOS) — это инструмент поиска элементов на странице браузера.
В мире, где скорость релизов и стабильность продукта становятся конкурентными преимуществами, последовательное тестирование превращается в узкое горлышко. Параллельное тестирование с использованием Selenium Grid предлагает решение: одновременное выполнение тестов на различных конфигурациях, что значительно сокращает время проверки без потери качества.
В этой статье подробно рассмотрим, как эффективно внедрить параллельное тестирование, избежать распространённых ошибок и интегрировать его в существующие процессы CI/CD. Будет особенно полезно начинающим тестировщикам.
В статье рассматривается практический опыт использования инструмента Warp для нагрузочного тестирования S3-совместимых хранилищ. Делимся примерами запуска тестов, объясняет ключевые параметры и помогает интерпретировать результаты. Материал будет полезен тестировщикам, работающим с объектным хранилищем и желающим проверить его производительность и стабильность под реальной нагрузкой.