Тестирование веб-сервисов *

В статье рассмотрим 7 инструментов, которые помогают управлять процессом тестирования, их ключевые особенности и ситуации применения.

Привет, я Михаил Шваркунов, директор по качеству ВКонтакте. Расскажу, как выглядят наши ежечасные релизы с точки зрения тестирования: как мы переложили часть задач по тестированию на разработчиков, сколько у нас автотестов и что мы ими покрываем. А ещё как команда тестирования сопровождает релиз, какие у нас при этом SLA и что делаем после. И вообще — зачем так часто что-то выкатывать? Что, нельзя подкопить и катать раз в день? 

Большое количество модулей Maven замедляет сборку проекта и время прогона тестов. Для того, чтобы сохранить многомодульную структуру проекта и быстро прогонять тесты, мы в Wrike написали новый инструмент — Maven Modules Merger, который сократил время некоторых сборок с 50 до 12 минут. В статье подробно расскажу о том, с какими проблемами нам помог справиться Maven Modules Merger и поделюсь подробностями его создания.

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

Привет! Меня зовут Александр Пронин, я занимаюсь тестированием более пяти лет, последние полгода из которых — в QIWI, проект ContactPay. Мы делаем платежную систему для международного рынка, она состоит из микросервисов, которые написаны на Python и живут в Google Cloud. Проект существует на рынке более двух лет, на данный момент среди наших клиентов уже есть компании-единороги. 

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

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

История о том, как школьники нашли глупейшую ошибку в production версии электронного журнала г. Москвы и построили на этом бизнес.

За последние пару лет не раз можно было услышать про новые инструменты
сборки статики, такие как SWC, esbuild и Vite. Все они обещают нам next
gen-оптимизацию времени сборки, а SWC ещë и грозится оптимизировать
скорость выполнения тестов на Jest; более того, судя по документации,
сделать это очень просто. Я решил проверить, так ли это на самом деле и
каким будет результат. Если вам интересно, что из этого получилось и
какие были проблемы, то прошу под кат.

Нам известны 7 принципов тестирования и сейчас мы их подробно разберём.

Итак, приступим.

1.  Исчерпывающее тестирование невозможно
2.  Тестирование демонстрирует наличие дефектов, а не их отсутствие
3.  Заблуждение об отсутствии ошибок
4.  Раннее тестирование сохраняет время и деньги
5.  Принцип скопления или кластеризация дефектов
6.  Тестирование зависит от контекста
7.  Парадокс пестицида

Зачем вообще они нужны и как могут помочь в понимании процесса тестирования? Это хороший вопрос. И если тщательно разобраться и следовать этим принципам, то можно избежать многих ошибок, недоразумений и неожиданных ситуаций в будущем.

В переводе с латинского При́нцип - это основа, начало, первоначало, и можно сказать, что принципы тестирования — это основы тестирования.

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

В этой статье я поделюсь своим опытом создания Telegram Bot-а для автоматизации тестирования.

Привет! Меня зовут Тимур Шарафутдинов, я занимаюсь процессами автоматизации тестирования в «Ростелеком ИТ». Сегодня поделюсь своим опытом реализации model based-подхода в написании python API автотестов на проекте — приложении с микросервисной архитектурой для обработки, хранения, конфигурирации заказов.

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

Тестирование — неотъемлемая составляющая разработки программного обеспечения. Независимо от того, насколько хорошо вы пишете код или насколько тщательно продуманным может быть первоначальный процесс тестирования, всегда есть вероятность, что что-то может ускользнуть.

Вот почему нагрузочное тестирование так важно. Кроме коммерческих инструментов, также доступны варианты с открытым исходным кодом.

Всем привет! Меня зовут Евгений Симигин, я занимаюсь внедрением DevOps-практик в Центре компетенций по разработке облачных и интернет-решений МТС Digital. В этой статье – обзор Argo Rollouts, я покажу несколько примеров применения и отмечу интересные места в документации. Хотите быстро освоить Argo Rollouts и разобраться в этом решении? Тогда жмите кнопку «Читать далее»!

Конференция Heisenbug («по тестированию, но не только для тестировщиков») близится: программа уже готова, и пришло время поделиться с Хабром всеми подробностями. 

Во-первых, напоминаем формат. Конференция будет проходить три дня. Первые два — полностью онлайновые. А вот в третий всё на выбор участников: можно приехать на конференцию в Москве, чтобы как следует пообщаться лично, или подключиться удалённо из любой точки планеты. 

Во-вторых, публикуем полную программу. В ней не только доклады-монологи: будут и воркшопы с мастер-классами, где можно научиться чему-то на практике, и круглые столы с тематическими обсуждениями. Среди прочего будут звучать слова «SRE», «Kaspresso», «бенчмаркинг», «TestOps» и не только. Но обо всём по порядку.

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

Далеко не все пользуются тёмной темой, но однажды ослепнув от яркого монитора и обзаведясь очками, невольно переходишь на тёмную сторону. Так как же грамотно подойти к её созданию? Меня зовут Мария, я QA-инженер в ISPmanager и сегодня расскажу, как спроектировать и протестировать тёмную тему с учётом человеческой физиологии.

Всем привет! Меня зовут Сергей, и сегодня я расскажу о том, как я искал носки мы выстраивали процессы тестирования в команде.

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

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

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

Один из важных вопросов как в нашей жизни, так и в бизнесе, и в IT — вопрос эффективности. Эффективно ли мы планируем наше время, те ли задачи решает бизнес, тот ли код мы оптимизируем? Чтобы ответить на эти вопросы, результат должен обладать главным критерием — измеримостью. Измеримость результата новых фич для бизнеса и IT обеспечивает платформа А/B-тестов. О том, как её можно построить, выдерживать большой RPS и при этом не облажаться уронить прод, я расскажу в этой статье. 

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