Пока у большинства отпуска и соленая вода под ногами — мы будем говорить о трендах в мире QA! Возможно, это поможет вам проанализировать свою карьеру, выучить новую технологию или придумать план развития на сентябрь и дальше. 👍
Тестирование локализации
Выход на международный рынок. Всё больше приложений от разработчиков из самых разных стран планируют выходить на новые рынки и предлагать специальные функции, ориентированные на местную аудиторию.
В этом контексте тестирование локализации позволяет обеспечить работу всех функций продукта, точность информации в нем и его пригодность для использования в конкретном регионе.
Ключевые проверки:
- В локализованном интерфейсе те же элементы, что в исходной версии.
- Выравнивание и макет размещения текста.
- Поля ввода.
- Сообщения.
- Специальные символы и гиперссылки.
- Формат даты, времени и номеров телефонов.
Популярные инструменты для тестирования локализации:
- Псевдолокали (Android Studio).
- BrowserStack.
- Testlio.
Что такое псевдолокаль?
Псевдолокаль — это локаль, предназначенная для имитации языковых особенностей, которые вызывают проблемы с интерфейсом, макетом и другими элементами приложения при переводе.
Псевдолокаль формируется мгновенно с помощью автоматического преобразования всех локализуемых сообщений, результатом которого является читаемый английский текст. Если какой-то текст оказался не переведен на псевдолокаль, это означает, что в исходном коде какие-то сообщения не охвачены процессом локализации.
Псевдолокали экономят время и деньги: они позволяют сначала скорректировать текст интерфейса и его макет, и только после этого отправлять сообщения в репозиторий, а затем — на перевод.
Названия псевдолокалей (в системе Android) соответствуют стандартным соглашениям об именовании локалей, а их идентификаторы читаются всеми языками программирования, совместимыми с BCP 47. В этом смысле псевдолокали не отличаются от остальных языковых стандартов — французского, итальянского, китайского и других.
На платформе Android есть две псевдолокали — для представления языков с письмом слева направо (LTR) и справа налево (RTL).
Английский (XA). Добавляет к основному тексту интерфейса на английском языке латинские диакритические знаки, удлиняет исходные строки, добавляя обычный текст, и заключает каждое сообщение в квадратные скобки, чтобы выявить возможные проблемы из-за удлинения строк. Возможные проблемы: ошибки макета и неправильно сформированный синтаксис сообщения, о чем свидетельствует разделение одного предложения на несколько частей, заключенных в квадратные скобки.
AR (XB). Меняет направление «слева направо» исходного текста на «справа налево», в результате чего порядок символов в исходном сообщении становится обратным.
Включение псевдолокалей
Псевдолокали обычно добавляются в сборки для разработчиков. Чтобы включить их для приложения в Android Studio, добавьте в файл build.gradle следующую конфигурацию.
//Groovy
android {
...
buildTypes {
debug {
pseudoLocalesEnabled true
}
}
}
//Kotlin
android {
...
buildTypes.getByName("debug") {
isPseudoLocalesEnabled = true
}
}
Как обнаружить проблемы с локализацией?
Псевдолокали — это быстрый и эффективный способ выявить следующие потенциальные проблемы с локализацией в интерфейсе:
- Жестко запрограммированные строки, которые нельзя отправить на перевод, в псевдолокали отображаются как текст без диакритических знаков, что позволяет легко их заметить.
- Проблемы с макетом интерфейса, вызванные удлинением текста. Позволяют определить, где интерфейс может «сломаться» из-за длины текста.
- Объединение строк, когда одно сообщение составлено из двух и более фрагментов в квадратных скобках. Такая ситуация может затруднить правильный перевод, поскольку переводчики будут работать с этими фрагментами по отдельности, не зная, что они связаны между собой.
- Проблемы с двунаправленным текстом (BIDI), например, когда текст с одним направлением включает в себя фразу с противоположным направлением, что затрудняет чтение строки.
- Проблемы с направлением «справа налево» (RTL), например, отсутствие зеркального отображения элементов.
Визуальное тестирование
При таком тестировании визуальный вывод приложения оценивается и сравнивается с ожидаемым UX-дизайном. В процессе тестирования можно обнаружить визуальные ошибки в веб-элементах и цветовом кодировании.
Визуальное тестирование работает на слое взаимодействия с пользователем и позволяет масштабировать различные проверки и внешний вид интерфейса на самые разные цифровые платформы — в отличие от дифференциального тестирования. Инструменты автоматического визуального тестирования решают проблему регулярных изменений в слое интерфейса, а также постоянно растущего числа платформ, размеров экрана и конфигураций.
Ключевые проверки:
- Высота и ширина.
- Видимость (да, нет).
- Цвет фона.
- Координаты.
Проводить такое тестирование можно методом снимков: в различных точках тестового запуска делается растровый снимок экрана, после чего проводится попиксельное сравнение с базовым изображением.
Популярные инструменты автоматического визуального тестирования:
- Applitools.
- Kobiton.
- LambdaTest.
- Percy.
Тестирование игр
В этом случае оценивается качество видеоигры. Основная цель — выявление дефектов и ошибок в игре, а также повышение стабильности и производительности.
Ключевые проверки:
- Логика игрового процесса:
- Правила прохождения уровней.
- Визуальные атрибуты:
- Действия игрока и управление музыкой.
- Камера:
- Приближение и отдаление, кинематографический вид и повторы.
- Функции геймпада и кнопок.
- Тексты, касающиеся юридических вопросов и конфиденциальности.
- Ролики и тизеры.
- Передвижение и размещение игрока.
- Результаты и статистика игрока.
- Спецэффекты (например, вибрация), экраны загрузки, а также действия, активируемые несколькими кнопками.
Повышение производительности очень важно для оптимизации скорости работы игры. Ниже приведены ключевые параметры производительности, которые необходимо тестировать.
- Расход заряда аккумулятора: должен быть оптимальным на протяжении нескольких часов. На время отклика игры на различных устройствах не должна влиять высокая нагрузка.
- Ограничения процессора и памяти.
- Время отклика на клиенте и сервере.
Тестирование AI и ML
Технологии искусственного интеллекта (AI) и машинного обучения (ML) хорошо себя зарекомендовали в обработке данных и паттернов и сегодня представляют собой движущие силы цифровой эры.
Организации по всему миру движутся к внедрению приложений и продуктов на основе AI, поэтому у этих технологий огромный потенциал роста в ближайшем будущем.
Тестовые случаи для приложений на основе AI (ML) должны соответствовать приемлемой точности: фиксированный набор входных данных при анализе миллионов паттернов AI-системами становится неактуальным.
Ниже приведены ключевые элементы в стратегии тестирования приложения (продукта) на основе AI (ML).
- Алгоритмы:
- NLP (обработка естественного языка).
- Глубокое обучение.
- Обработка изображений.
- Данные:
- Создание и маркировка.
- Идентификация наборов тестовых данных.
- Кластеризация.
- Нефункциональное тестирование (NFR).
- Анализ решений.
- Обратное тестирование модели:
- Обратное тестирование модели полезно при оценке допущений, полученных из тестирования модели (дизайна) на исторических данных.
- Обратное тестирование очень эффективно при определении точности модели.
Да, правильно: Agile и DevOps
IT-компании уже в основном приняли Agile и DevOps, в прошлые годы. Деплои и релизы явно ускорились.
Agile предполагает постоянное обновление требований к софту и “шлифование” софта в любой момент. Улучшилось сотрудничество в самоорганизующихся многофункциональных командах.Популярные QA-практики 2022 года предполагают работу по Agile в delivery-процессах.
DevOps, в идеале, устраняет “слабые места” между разработкой и операциями, что делает софт быстрым, безопасным, расширяемым.
Раньше QA-команды работали с билдом, развернутым в dev-окружении, и в основном вручную проводили регрессионное тестирование. А теперь, с приходом новой культуры скорейшей доставки приложения на рынок, круг обязанностей QA-команды расширился: “искать не столько баги, сколько риски их возникновения”, и делать это еще быстрее, за те же деньги, и за ограниченное время.
Масштабирование приложений посредством Контейнеризации и Микросервисов
ИТ-компании делают распределенные системы, применяя микросервисную архитектуру и контейнеры, чтобы масштабировать приложения соответственно изменениям бизнес-требований.
Контейнеризация хорошо сочетается с DevOps и Site Reliability Engineering (SRE), поскольку создается масштабируемое окружение, быстро и надежно запускаются приложения в “пакетной” форме (то есть код + все зависимости). Контейнеризация уменьшает потребление ресурсов, ускоряет деплой, упрощает патчи, и ускоряет переход в облако.
Контейнеризация и микросервисы хороши, но приносят челенджи — (некоторое) ослабление безопасности, поскольку такие сервисы бывают слабо связаны; коммуникация между ними иногда проблемная; могут зависеть от сервисов третьих сторон, а значит их сбой вызывает сбой и разрабатываемого приложения.
Поэтому нужно будет тщательно продумывать стратегию контейнеризации; проверять все связи между микросервисами во время тестирования; делать smoke-тестирование новых функций до передачи на прод.
Тщательное тестирование API
API это посредник между UI и бэкендом (“между данными и их представлением”). API соединяют распределенные системы, передавая данные между ними. С широким внедрением микросервисов применение API значительно выросло.
Пример. Ритейловый сайт может иметь много “малых сервисов”: каталог, поиск продуктов, прием заказов, рекомендации, и прочее; все это подключается через API. API это “ключ к двери в цифровой мир”, но через эту дверь могут ворваться угрозы безопасности.
Чтобы снизить эти угрозы, необходимо тщательное тестирование API. И это не только проверка оптимальной имплементации. QA-команда должна всесторонне оценивать API, что касается рисков; делать безопасные, надежные платформы, уважаемые клиентами и партнерами.
Безопасные приложения
Продолжает расти запрос на безопасность приложений. Мир в 2022 становится еще мобильнее; крупные компании опираются на мобильные приложения, и платформы типа Microsoft Teams, тот же Zoom, WebEx.
Любые узкие места в этих платформах — это потенциальные потери для бизнеса. Слабое управление серверной частью; небезопасное хранение данных; пренебрежение криптографией — это открытая дверь для внешних хакеров и внутренних нечестных сотрудников. Скандалы с SolarWinds Orion и Log4j2 помнит вся ИТ-индустрия.
Тестирование мобильных приложений
Приложение в 2022 году — это приложение, работающее или на смартфоне, или на лептопе. Пользователи не расстаются со своими смартфонами даже ночью, и ИТ-компании в B2C и B2B реагируют, фокусируясь на мобильных приложениях. Если приложение не работает, или просто неудобное, пользователи злятся, шлют негативные фидбеки, в том числе в соцсетях, и это катастрофа. Continuous-тестирование гарантирует хороший User Experience, это теперь неотъемлемый элемент рабочего процесса почти всех ИТ-компаний.
Проверяется функциональность, юзабельность, производительность, и “связность”.
Согласно недавнему отчету Market Research Future, в следующие три года расходы на мобильное тестирование вырастут на 20%.
Сдвиг влево
Чтобы улучшить уверенность QA-команды в качестве релиза, надо начинать тестировать с самого начала жизненного цикла. Это и есть Сдвиг Влево.
Итак, QA-команда ищет проблемы на ранних этапах в цикле разработки. А разработчики и тестировщики эффективно работают в связке.
Сдвиг влево стимулирует подход “качество прежде всего”. Такой сдвиг позволяет отслеживать тестовые метрики с самого начала.
Сдвиг влево, вкупе с DevOps и автоматизацией, разблокировал возможности переходу к Continuous Testing; экономится время; эффективно ищутся дефекты на ранней стадии; меньше ручной муторной работы; быстро выполняются тесты; и в целом получается быстрый цикл релиза.
Еще сдвиг влево предполагает, что тестировщики могут помогать с кодом и даже сами писать его, а разработчики могут тестировать, в зависимости от проекта.
Дэвид Мосс из Гарвардской бизнес-школы говорит: “В качестве консультанта по тестированию, скажу что сдвиг влево — это запуск процесса тестирования еще до того как написана первая строчка кода. В начале разработки, когда у вас еще нет приложения. QA-департамент участвует в работе над требованиями и дизайном, все направлено на предотвращение и устранение дефектов как можно раньше”.
“Архитектурное тестирование”: увеличиваем покрытие
Написание тестовых сценариев — гибкий процесс. В нем все чаще применяется принцип Model Driven Architecture Based Testing (MDABT).
MDABT с самого начала учитывает архитектуру тестируемых приложений при создании первых тест-сьютов и первой версии приложения. Более простой принцип Model Based Testing (MBT) автоматизирует генерацию и выполнение тестовых сценариев и автотестов, применяя model-based-техники при отработке требований и поведения приложения (на рисунке ниже показано, как это делается). Создается модель приложения; генерируются “абстрактные” тесты.
Плюсы модели:
- Расширение покрытия
- Экономия времени
- Улучшение стабильности тестов
- Реюзабельность тестов
- Экономия усилий тестировщиков
- Удешевление их работы в целом
- Совершенствование поиска багов
- Общее улучшение качества
Заключение
В этой статье мы рассмотрели тенденции в сфере обеспечении качества, на которые следует обратить внимание в 2022 г., и подробно разобрали этапы проверок и популярные инструменты. Надеемся, вам было интересно. Если это так — поддержите статью, распространяйте ее 💙
