Как тестировать приложения которые работают с очередями сообщений

Тестирование микросервисной архитектуры

Меня зовут Кирилл, я работаю в компании Slotegrator и возглавляю отдел QA. Наша команда занимается разработкой платформ для онлайн-казино. У этого продукта очень разнообразный функционал, который включает в себя следующие пункты:

• Модуль регистрации и авторизации;
• Пополнение баланса и отслеживание статуса;
• Подтверждение пользователей;
• Бонусный модуль и т. д.

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

Как все начиналось?

В начале моей карьеры в Slotegrator, наша команда из 30-ти человек работала с 5-6 клиентами. И этого было достаточно, чтобы создавать платформу на PHP-монолите. То есть, она была построена как единое целое, где вся логическая обработка запросов помещалась внутрь одного процесса.

Но, со временем, наша компания значительно расширила свою клиентскую базу и разрабатывать платформу на монолите PHP стало не удобно, поскольку пожелания клиентов стали разнообразными и каждый хочет создать свою уникальную платформу.

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

Архитектура нашего продукта включает в себя следующие пункты:

• интерфейс пользователя;
• серверная часть, которая отвечает за бизнес-логику приложения;
• доступ к данным;
• база данных.

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

Работая с монолитом, у нас возникали сложности с масштабированием части приложения, поэтому мы были вынуждены делать это для всего приложения.

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

Почему микросервисы?

После того как наша команда столкнулась с рядом проблем, мы решили перейти на микросервисную архитектуру.

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

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

Однако, нам удалось преодолеть все эти трудности. Мы приобрели огромное количество новых знаний и навыков, а также овладели новыми инструментами.

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

Тестирование микросервисов

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

Эти сервисы находятся на разных серверах и написаны на различных языках программирования, таких как Java и.Net. Однако, это также является и недостатком, поскольку разработчики определенного микросервиса практически не знают, что делают остальные микросервисы. Таким образом, это делает процесс тестирования не из легких.

Тем не менее у нас есть возможность обновить отдельный микросервис быстро и протестировать его не затронув другие.

• unit-тестирование;
• контрактное тестирование;
• интеграционное тестирование;
• end-to-end тестирование;
• нагрузочное тестирование;
• UI- или функциональное тестирование.

Теперь рассмотрим подробнее все виды тестирования.

Unit-тестирование

Unit-тестирование (модульное тестирование) — это вид тестирования ПО, позволяющий проверить корректность отдельных модулей или компонентов программного обеспечения. Цель: проверка того, что каждая единица программного кода работает корректно.

Unit-тестирование бывает двух видов:

• позитивное (проверить поведение методов в нормальных условиях);
• негативное (проверить устойчивость системы к нештатным ситуациям).

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

Мы покрыли 70% функционала unit-тестами, и поскольку используем CI/CD, то не можем развернуть приложение, пока они не пройдены.

Контрактное тестирование

У нас работают над микросервисами несколько команд:

• бэкенд;
• фронтенд;
• тестировщики.

Чтобы понимать какой ендпоинт и в каком формате отдаёт и принимает данные, мы договариваемся между собой. Для этого, используем контракт между командами, который называется Pact. Он содержит в себе все методы и возвраты всех сервисов.

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

Наша команда работает с контрактным тестированием следующим образом: мы получаем ТЗ, которое согласованно со всеми стейкхолдерами. Согласно техническому заданию, мы оцениваем задачи и создаем схему работы.

Интеграционное тестирование

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

End-to-end тестирование

E2E тестирует бизнес-логику подобно процессу тестирования в интеграционном, но уже не изолированно, а в масштабе всей системы.

В end-to-end тестировании проверяется, как взаимодействуют все сервисы c платформой:

• регистрация;
• авторизация;
• игровая деятельность;
• пополнение и снятие денежных средств.

То есть мы проверяем насколько соответствует все приложение запросам заказчика.

Нагрузочное тестирование

Процесс нагрузочного тестирования формально делится на 4 этапа:

• тестирование производительности (Performance Testing);
• тестирование стабильности или надежности;
• стресс-тестирование;
• объемное тестирование (Volume Testing).

Для тестирования, мы используем JMeter, а сами нагрузочные скрипты написаны на Groovy.

Также, мы используем около пяти виртуальных машин, развернутых на AWS и у нас есть 7 физических машин. Физические машины, мы используем если нам необходимо создать большую нагрузку от 15,000 RPS и более. Виртуальные машины такие показатели дать не могут, поскольку каждый запрос необходимо отправлять с подписью шифрования, вследствие чего процессор сильно нагружается. Поэтому, мы используем виртуальные машины только для фоновой или статической нагрузки — 2000 RPS.

Что касается статистики, мы её собираем в Grafana. После чего, мы анализируем все показатели, такие как нагрузка на CPU, GPU, сеть, диски и т. д.

UI- или функциональное тестирование

Это итоговый вид тестирования. Мы тестируем практически все то же самое, что и при end-to-end тестировании, но только с использованием UI. Мы проводим UI тестирование мануально и также делаем автотесты.

Вывод

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

Тестирование веб приложений и сайтов — полное руководство

В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.

Основные виды тестирования сайта (веб-приложения)

1. Тестирование функциональности;
2. Тестирование удобства использования;
3. Тестирование интерфейса;
4. Тестирование совместимости;
5. Тестирование производительности и скорости загрузки сайта;
6. Тестирование безопасности.

Тестирование функциональности

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

Проверьте все ссылки

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

Проверьте формы

Формы используются для получения информации от пользователей и взаимодействия с ними.

Что нужно проверить в формах:

• Правильность работы валидации в каждом поле формы.
• Значения полей, используемые по умолчанию.
• Опции для создания форм, удаления, просмотра и редактирования форм ( если такие имеются ).

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

Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.

Тестирование файлов cookie

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

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

Проверьте HTML/CSS

Если вы оптимизируете сайт для поисковых систем, то валидация HTML/CSS особенно важна. Первым делом проверьте сайт на наличие синтаксических ошибок в HTML-коде . Проверьте, доступен ли сайт для различных поисковых систем.

Тестирование базы данных

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

Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.

При тестировании функциональности сайтов нужно проверить:

Ссылки

1. Внутренние ссылки;
2. Внешние ссылки;
3. Ссылки на электронную почту;
4. Битые ссылки.

Формы

1. Валидация полей;
2. Сообщения об ошибке при неверном вводе;
3. Обязательные и необязательные к заполнению поля.

База данных

Следует проверить целостность базы данных.

Тестирование удобства использования (юзабилити сайта)

Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.

При этом проверяется:

• Легкость обучения;
• Навигация;
• Субъективная удовлетворенность пользователей;
• Общий вид.

Проверка навигации

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

• Сайт должен быть простым в использовании;
• Инструкции должны быть очень четкими;
• Проверьте, достигают ли предоставленные инструкции поставленной цели;
• Главное меню должно быть доступно на каждой странице;
• Главное меню должно быть построено в логической последовательности.

Проверка контента

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

Для контента и фона страницы лучше применять общепринятые стандарты, чтобы цвет шрифта, рамок и т.д. не раздражал пользователей.

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

Другая информация для пользователей

Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция « Поиск по сайту » должна помогать легко находить нужный контент.

Тестирование пользовательского интерфейса

Нужно проверить, правильно ли осуществляется связь с сервером. Следует проверить совместимость сервера с используемым программным обеспечением, аппаратными средствами, сетью и базой данных.

• Интерфейсы веб-сервера и приложения.
• Интерфейсы сервера базы данных и сервера приложения.

Если база данных или веб-сервер для какого-либо запроса, исходящего от сервера приложения, возвращает сообщение об ошибке, сервер приложения должен фиксировать его и отображать пользователю.

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

Проверка совместимости

• Совместимость с браузерами;
• Совместимость с операционными системами;
• Просмотр на мобильных устройствах;
• Параметры печати.

Совместимость с браузерами

Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.

Верстка сайта должна быть кроссбраузерной. При использовании Java-скриптов и AJAX , обеспечивающего функциональность пользовательского интерфейса, проверки безопасности или валидации создают большую нагрузку на систему.

Проверьте работу веб-приложения в браузерах Internet Explorer , Firefox , Netscape Navigator , AOL , Safari , Opera разных версий.

Совместимость с операционными системами

Некоторые функции веб-приложения могут быть несовместимы с определенными операционными системами. Не во всех из них поддерживаются новые технологии, используемые в веб-разработке. Поэтому проверьте работу приложения в Windows , Unix , MAC , Linux , Solaris и их различных версиях.

Просмотр на мобильных устройствах

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

Параметры печати

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

Тестирование производительности сайта

Тестирование производительности сайта или веб-приложения должно включать в себя:

• Нагрузочное тестирование.
• Стрессовое тестирование.

Проверьте производительность приложения на различной скорости интернета.

Нагрузочное тестирование сайта ( веб-приложения ) — это тестирование, при котором большое количество пользователей одновременно выполняют запрос к одной и той же странице. Выдерживает ли система пиковые нагрузки?

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

ab тестирование функциональности также включает в себя проверку на ошибки, связанные с оперативной памяти.

Тест производительности можно применять для проверки масштабируемости сайта или оценки продуктивности при использовании стороннего программного обеспечения.

Скорость соединения

Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.

Нагрузка

1. Количество пользователей, одновременно посещающих сайт;
2. Проверьте работу системы при пиковых нагрузках;
3. Пользователь осуществляет доступ к большому количеству данных.

Стрессовая нагрузка

1. Непрерывная нагрузка;
2. Производительность памяти, процессора, обработки файлов и т. д.

Тестирование безопасности

Ниже приведены некоторые наборы для тестирования веб-безопасности:

• Проверка с помощью вставки внутреннего URL в адресную строку браузера без авторизации. Внутренние страницы при этом не должны открываться.
• После авторизации с помощью логина и пароля, а также просмотра внутренних страниц попробуйте изменять URL . Например, вы проверяете какую-то статистику сайта под идентификатором ID= 123 . Попробуйте изменить ID URL на другой ID сайта, который не имеет отношения к авторизованному пользователю. В любом случае доступ этого пользователя к просмотру других показателей должен быть запрещен.
• Попробуйте ввести неверные данные в поля формы для авторизации. Выясните, как система реагирует на ввод недопустимых данных.
• Каталоги или файлы не должны быть доступны напрямую, если для них не предусмотрена возможность скачивания.
• Проверьте работу капчи для защиты от автоматического входа с помощью программного кода.
• Проверьте, используется ли в целях безопасности SSL . Если да, то должно отображаться сообщение при переходе пользователя с незащищенных HTTP-страниц к защищенным и наоборот.
• Все операции, сообщения об ошибках, нарушения безопасности должны записываться в файл журнала на веб-сервере.

Основной причиной тестирования безопасности сайта является поиск потенциальных уязвимостей и их последующее устранение.

• Сетевое сканирование;
• Сканирование уязвимостей;
• Возможность потенциального взлома паролей;
• Обзор журнала;
• Средства для проверки целостности;
• Обнаружение вирусов.

Моменты, которые следует учитывать при тестировании сайта

Следует обратить внимание на взаимодействие HTML-страниц , интернет-подключение, брандмауэры, приложения, запускаемые на веб-страницах ( апплеты, JavaScript , модульные приложения ), а также приложения, работающие на стороне сервера ( скрипты CGI , интерфейсы баз данных, генераторы динамических веб-страниц ).

Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.

Пример сценариев тестирования сайта

Дополнительные факторы, которые следует учесть при тестировании сайта:

• Какова ожидаемая нагрузка на сервер ( например, количество запросов за единицу времени )?
• Какая производительность требуется при различных видах нагрузки ( время ответа веб-сервера, время отклика базы данных на запрос )?
• Какие инструменты потребуются для тестирования производительности?
• Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
• Какую производительность ожидает получить клиент ( насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск )?
• Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
• Какие средства безопасности требуются ( файерволы, шифрование, пароли и т.д. ), и какую работу они будут выполнять? Как их можно проверять?
• Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
• Как будет выполняться управление обновлением контента сайта?
• Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
• Какая спецификация HTML будет соблюдаться? Насколько точно?
• Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
• Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript , компонентов ActiveX и т.д.?
• Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
• Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
• Отображение веб-страниц должно быть независимо от типа браузера.
• На каждой странице следует указать ссылку для связи.

Пожалуйста, оставляйте ваши мнения по текущей теме статьи. Мы очень благодарим вас за ваши комментарии, лайки, подписки, дизлайки, отклики!

Пожалуйста, оставляйте свои мнения по текущей теме статьи. Мы очень благодарим вас за ваши комментарии, лайки, подписки, отклики, дизлайки!

Тестирование мобильных приложений: полезные советы

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

Интернет-соединение

Как проверить работу приложения при различном интернет-соединении? Не нужно, сидеть и ждать, пока на стороне провайдера случится сбой и соединение пропадет. Есть вариант получше. Используйте утилиту Charles, которая позволяет эмулировать разный уровень сигнала и прерывать его. Главное, чтобы ваш ПК и телефон были подключены к одной сети.

Помимо проверок прерывания и медленного соединения, надо еще знать, какие места приложения тестировать.

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

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

Прерывание работы приложения сообщениями, звонками, нотификациями

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

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

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

Анализ работы приложения на подзарядке

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

Тестирование при нехватке памяти

Смартфон – это давно уже не просто телефон, а устройство для хранения музыки, фото, документов. Проблемы нехватки памяти возникают у пользователей регулярно. Обязательно проверьте установку приложения и обновление его файлов, когда память устройства переполнена и когда ее осталось совсем немного.

Здесь у вас может возникнуть вопрос: как заполнить 250 гб памяти айфона?

Конечно, всегда можно снять 250 гб видео и стать популярным блоггером, но у кого время ограничено есть способ проще: создайте в командной строке «липовые» файлы нужного размера (команда FSutil), после этого с помощью iTunes перенесите их на девайс.

И не забывайте освобождать память после завершения тестирования. Коллеги будут вам благодарны.

Учитываем гайдлайны Android и iOS

Очень важно делать проверки на соответствие гайдлайнам ОС. Это снизит вероятность того, что приложение не будет допущено для размещения в сторе. Повторное размещение приложения требует времени. Если, к примеру, время обработки запроса на добавление в Google Play занимает пару часов, то Apple Store может рассматривать его в течение двух недель. И будет обидно, если после этих 2 недель ваше приложение будет отклонено из-за какой-то мелочи. У нас на проекте был пример того, когда приложение отклонили из-за того, что иконка на устройстве незначительно отличалась от иконки в магазине. И Apple посчитал, что это будет вводить пользователей в заблуждение.

Гайдлайны можно посмотреть на официальных сайтах Apple и Google.

В качестве десерта

После успешного тестирования настала пора собирать трофеи. Приложение выпущено в релиз, пользователи ставят высокие оценки. Что может быть приятнее?

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