Автор: Михаил Кургузов

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

Возможные проблемы

1. Плохое знание продукта и некорректное тестирование

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

2. Отсутствие консистентности на разных версиях оборудования

Оригинальная публикация

Привет! Мы команда из отдела разработки ПО для банкоматов Т-Банка: Александр, Владислав, Иван и Денис.

Расскажем о необычном, но интересном опыте автоматизации и роботизации тестирования банкоматного ПО в Т-Банке, для которого мы использовали коллаборативного робота.

Ручное тестирование нового ПО АТМ (automated teller machine или по-нашему: банкомат)трудозатратно, требует много времени и ресурсов. Зачастую действия повторяются и QA выполняет одни и те же тест-кейсы. Нашей целью было высвободить ресурс QA, уйдя от рутинного ручного тестирования к более творческим задачам путем роботизации ручного тестирования.

Привет! Меня зовут Михаил Кургузов, я из отдела локализации и переводов SM Lab. В этом цикле постов я расскажу о локализации и ее интеграции в процесс тестирования ПО. 

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

• Пост #2 — особенности тестирования локализации, кто чем занимается, как проходит процесс.

• Пост #3 — чеклист, лучшие практики, дополнительные материалы и много полезных примеров.

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

Автор: Екатерина Ступкина

Представьте, что аутентификация — это ключ от дома, а авторизация — список комнат, в которые этот ключ открывает дверь. В современных приложениях простой ключ-пароль заменяется сложными системами: токенами, OAuth 2.0 и OIDC.

Я, Екатерина, QA Lead в «Лиге Ставок», покажу, как с помощью инструментов тестирования проводить базовые проверки: тестировать валидность токенов, отслеживать их обновление и проверять корректность прав доступа.

Это руководство из трех частей поможет систематизировать знания и применять их в работе — от основ до реальных кейсов.

Автор: Мирза Сизич (Mirza Sisic)
Оригинал статьи
Перевод: Ольга Алифанова

Что (и зачем) тестировщикам нужно знать о куки-файлах (cookies) приложений?

Cookies приложений за 30 секунд или меньше

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

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

Автор: Никонов Владислав

Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование" (КТ). Я уже не первый раз натыкаюсь на этот термин, в первый раз я поискал инфу об этом, как то не очень понял и забил. Но с каждой последующей встречей у меня все больше подгорало.

В пирамиде тестирования, КТ стоит сразу после модульного. И если unit-тесты это участь разработчиков, то КТ это уже, якобы, зона ответственности тестировщика, отсюда необходимость хоть как то в этом разобраться.

Начнем с определений. Самое крутое (тут сарказм), которое я нашел это - "Компонентное тестирование программного обеспечения - это тестирование отдельных компонентов программного обеспечения". Да и вообще, во многих статьях определение пропускается и пишется, что-то вроде "компонентное тестирование это вид тестирования который следует сразу после модульного и до интеграционного". Еще варианты:

Автор: Питер Томас (Peter Thomas)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Кастури Раджаманикам(Kasturi Rajamanikkam)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

Я Арман (Arman Muradian. Senior QA Engineer, мой telegram канал про QA – LilBugHunters), и сегодня я хочу вам рассказать про пуши.

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

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

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

Оригинальная публикация

Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

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

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.