В этой заметке я поделюсь опытом автоматизации тестирования специфичных сквозных (E2E) сценариев, с которыми мне пришлось столкнуться.
Для успешного решения этой задачи, я нарушил один из важных принципов тестирования - делай тесты независимыми. Далее я покажу, почему я так поступил, и что из этого вышло. Быть может, этот опыт будет полезен моим коллегам.
Сталкивались ли вы с проблемой возникновения багов из-за пересечения включенных фичей в приложении? Или, возможно, была необходимость одновременно проводить большое число A/B-экспериментов в одном компоненте?
Некоторое время назад команда Почты Mail.ru решала задачу управления сложным состоянием приложения с большим количеством фичей и источников данных с помощью конечных автоматов. Нужно было ускорить разработку и тестирование, поддерживая возможность проведения более чем 20 А/В-экспериментов. На тот момент, я работал там над проектами портальной навигации и главной страницы.
Меня зовут Денис Стасьев. В этой статье расскажу о том, как мы внедряли машину состояний в одном из компонентов главной страницы Mail.ru — блоке новостей, что получили на выходе и ещё подробнее о том, почему в итоге остановились на XState.
В последние годы в разработке Android наметился заметный сдвиг в сторону декларативных UI-фреймворков, и последним дополнением к этой экосистеме стал Jetpack Compose. Декларативные UI-фреймворки предлагают структуры контроля, с помощью которых можно менять способ отрисовки пользовательского интерфейса. Декларативно созданные пользовательские интерфейсы могут использовать эти структуры управления, что делает их более динамичными, чем императивные фреймворки, которые обычно используются для разработки под Android и IOS.
В этой статье мы расскажем о лучших практиках и методах тестирования приложений на базе Jetpack Compose, и о том, как использовать эти инструменты и методы для обеспечения качества и надежности приложения.
Вокруг профессии тестировщика до сих пор много спекуляций. Одни, желая продать свои услуги, говорят, что это направление — идеальное для старта своего пути в IT, другие — что профессия тестировщика крайне сложна, незаурядна и вообще сюда не стоит идти, если у вас нет технического бэкграунда.
Почему об этом пишу я? Меня зовут Никита, и у меня есть опыт работы в «Мегафоне», Rambler&Co и Okko. Я имею представление о том, как устроены процессы внутри крупных компаний — как в маленьких, так и в больших командах. Помимо прочего, работаю наставником на курсе «Инженер по тестированию» и помогаю студентам разобраться в том, как это ваше тестирование устроено.
Эта статья призвана показать, какими же задачами занимается тестировщик, какие у него обязанности, и почему искать баги — это далеко не главная его задача. Будет полезно тем, кто рассматривает себя в роли QA. Или, быть может, вы разработчик, для которого работа тестировщика покрыта завесой тайны? В общем, этот лонгрид для тех, кто вообще не понимает, чем мы занимаемся, но ему очень интересно.
В марте мы с ИТ-лидером системы Alfa ID и её архитекторами генерировали идеи по повышению стабильности и устойчивости системы, потому что в течение года планировался кратный рост нагрузки. Одной из мыслей, которая потом успешно воплотилась в реальность, была «А давай хаос инжиниринг попробуем? А то мало у нас проблем на проде как-то пока»
Автоматизированное тестирование стало настолько неотъемлемой частью обеспечения качества, что некоторые тестировщики задаются вопросом, не заменит ли оно полностью ручное.
Все мы привыкли к общепринятым инструментам для тестирования. Думаю, список есть у каждого и он постоянно пополняется. Лично мой: Postman, IntelliJ IDEA и DataGrip от JetBrains, ShareX для скриншотов и его величество DevTools.
В этой статье я хотел бы отдать дань самоделкам нашего ремесла. Мелкие скрипты и утилиты или целые приложения, написанные для того, чтобы помочь в нелёгком деле создания продукта. На первый взгляд незначительные штуки, которые делают процесс работы таким удобным.
От коллег-тестировщиков я не раз слышал: «В ручном тестировании упёрся в потолок, хочется перейти в автоматизацию, но боюсь, что не потяну» или «…не знаю, с чего начать». Меня зовут Михаил, в тестировании 7 лет, из них около 4 занимаюсь автоматизацией. В последние пару лет мануальщики нужны всё реже, некоторые компании их уже не нанимают. Бизнесу интересны fullstack-специалисты, умеющие и вручную тестировать, и автоматизировать. Мой опыт подсказывает, что перейти из ручников в автотестеры по силам каждому. Так что я протёр клавиатуру и написал для вас эти мемуары. Заходите под кат, возможно, статья будет волшебным пенделем стимулом для тех, кто ещё сомневается и тянет с переходом.
Не так давно (13 Сентября 2023) на Хабре опубликовали статью "Подборка выдающихся статей по тестированию". В приведенном списке есть и статья "Фетиш юнит-тестов" Мартина Сустрика.
Я считаю эту статью вредной, и постараюсь показать – чем именно. Кто-то из читателей согласен с утверждениями Мартина. Возможно, кто-то из них не смотрел с позиции QA на эти утверждения. Именно для них я изложил свою точку зрения.
Говорят, молчание — золото, но чтобы стать хорошим тестировщиком, нужно уметь договариваться (с разработчиками, дизайнерами, продукт-менеджерами), убеждать, лавировать между оппонентами и примирять конфликтующие стороны. Словно я описываю посредника в переговорах, но сегодня не о нем речь.
Из каждого утюга сегодня звучит призыв двигаться в сторону IT. Информационные технологии — это уже не только про математику, но и про дизайн, менеджмент, аналитику и тестирование. Причём о тестировании говорят как о чём-то очень лёгком для начала карьеры. Мол, стать тестировщиком может каждый. Но стать — это одно, а стать профессионалом — совсем другое.
Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических.
QA-инженер — это не волк-одиночка, который только ищет баги. Задача тестирования — проверка работы продукта в соответствии с требованиями заказчика. Есть даже поговорка, что разработчики радуются, когда работает, а тестировщики радуются, когда не работает. Потому что тестировщики проверяют работу программы согласно требованиям к ПО и удостоверяются, что нет багов. Но поиск багов — не цель тестировщика, а следствие его кропотливой работы.
В ЮMoney большой отдел тестирования — в нём почти 80 человек, которые каждый день проверяют качество продуктов и сервисов. В этой статье рассказываем, как мы измеряем эффективность тестирования, какие метрики собираем и что за результаты это приносит.
Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.
Автор: Роман Горбунов, руководитель проектов в сфере обеспечения качества ИТ‑компании «Точка качества».
При взаимодействии с директорами, владельцами бизнеса и некоторыми руководителями команд разработки специалисты компании по тестированию программного обеспечения «Точка качества» периодически сталкиваются с мнением, что тестировать ИТ‑решение — это легко и быстро. Нужно просто нажать несколько кнопок и готово, запустить пару программ, и можно делать релиз.
В связи с этим некоторые думают, что нет необходимости создавать или привлекать отдельную команду инженеров по тестированию, так как с задачей справятся разработчики, менеджеры проекта, аналитики, специалисты техподдержки или представители бизнеса.
Чтобы выпустить на рынок востребованное ПО, которое будет работать быстро и корректно, будет соответствовать критериям безопасности и дизайна, необходимо провести тестирование. Тестирование ПО — это многогранный и сложный процесс, который делится на виды, этапы, методы и инструменты и требует особых компетенций, которыми не всегда обладают другие ИТ‑специалисты.
Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.
Приветствую всех читателей, меня зовут Вадим, я — бэкенд-разработчик в компании Домклик. В этой статье я хотел бы поделиться своим интересным опытом мажорного повышения зависимостей в проекте, который свыше пяти лет находится в проде под ежедневной нагрузкой более 2000 RPS. Мне пришлось обновить наш основной фреймворк сразу на несколько мажорных версий. Приглашаю прочесть как именно и зачем я это делал!
Playwright рекомендует использовать пакет @playwright/test и загружать браузеры с помощью команды npx playwright. Если вы следуете этой рекомендации, для вас ничего не изменилось. Однако вплоть до версии 1.38 при установке пакета playwright вместо @playwright/test браузеры загружались автоматически. Это уже не так, и рекомендуется явно загружать браузеры с помощью команды установки npx playwright.
Одним из таких ключевых ожиданий со стороны работодателей является знание JSON, REST и типов запросов HTTP. В этой статье мы рассмотрим, почему это важно и какие преимущества это приносит как для специалистов, так и для компаний.
Привет, меня зовут Дима, я руководитель группы разработки инструментов тестирования. Миссия нашей команды предоставить инструменты которые позволяют тестировщикам измерить качество своего продукта и улучшить его. Мы хотим, чтобы тестировщики релизили быстро и без багов.
У нас есть интересные задачи и классные решения для них, которыми мы хотим поделиться.Приглашаю вас на открытый Ozon Tech Community QA Meetup, в Москве, 21 сентября в 19:00
На митапе подробно обсудим, как устроено тестирование в Ozon, поговорим про тестовое покрытие и узнаем, как работает QA в блоке по продукту и технологиям товарных операций, а именно в разработке склада.
Привет! Меня зовут Оля, я работаю в сфере обеспечения качества ПО уже более 15 лет. За это время я успела поработать в самых разнообразных компаниях по очень разным направлениям: от ПО для автозаправок до финтеха и агротеха. Пробовала себя и в ручном, и в автоматизированном тестировании. В итоге ушла с головой в менеджмент.
Больше всего мне нравится работать над процессами: выстраивать с нуля, встраивать практики обеспечения качества в существующие процессы, калибровать их в зависимости от результатов и прочее.
Сейчас я курирую QA в нескольких командах в Спортмастер Лаб, и в том числе помогаю им выстраивать те самые хорошие процессы.
На одной из прошлых SQA days я сделала доклад на тему анализа дефектов в командах, и решила написать статью по его мотивам.
