Автор: Константин Сахчинский (Konstantin Sakhchinskiy)
Оригинал статьи
Перевод: Ольга Алифанова

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

Меня зовут Алексей, я работаю тестировщиком в компании «Совкомбанк Технологии». Хочу поговорить о нефункциональном тестировании мобильных приложений на платформах Android и iOS.

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

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Освойте нагрузочное тестирование: создавайте тесты с нуля, имитируйте высокую нагрузку и выявляйте узкие места.

Вебинар поделен на две части общей продолжительностью 5 часов!
Начало: 09 и 11 сентября в 20:00 (UTC+3)

Промокод на скидку для наших подписчиков: LGALDPNA

✍️ Какие темы разберём:

✔ Основы нагрузочного тестирования и ключевые метрики.
✔ Установка и настройка Locust.
✔ Создание тестовых сценариев и пользователей.
✔ Ramp-up, разные типы нагрузок и планирование тестов.
✔ Анализ результатов и поиск узких мест.
✔ Подготовка отчётов для команды и заказчиков.
✔ Интеграция нагрузочного тестирования в CI/CD.

✍️ Кому будет полезен этот вебинар:

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

Видеозапись будет доступна всем зарегистрированным участникам. Если не получится присоединиться в прямом эфире, вы сможете посмотреть запись в удобное время. Главное — не забудьте зарегистрироваться!

Промокод на скидку для наших подписчиков: LGALDPNA

Узнать больше и записаться на вебинар можно по ссылке:
https://www.learnqa.ru/load_python_webinar?erid=2SDnjcxPSN2

Реклама: ИП Батыров Арсений Георгиевич, ИНН 370207708748, erid:2SDnjcxPSN2

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

Меня зовут Саша – я ведущий исследователь пользовательского опыта в операционных продуктах ecom.tech, @ecom_tech_channel). На наших технологиях работают Самокат и Мегамаркет. В этой статье расскажу, как я оказалась на огромных складах и как мои исследования помогли разработать собственную систему управления складами. Внутри вас ждёт этнография, много тестирования и живые фото. Поехали!

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

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

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

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

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

Всем привет! На связи Андрей – QA-лид из Совкомбанк Технологий.

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

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

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

В статье рассмотрим:

• Оптимальное соотношение QA-инженеров и разработчиков

• Соотношения, которые существуют в реальных проектах и их особенности

• Параметры, которые нужно учитывать, чтобы вывести оптимальное соотношение

• Вывод идеальной формулы

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

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тратить время на продумывание сообщений об ошибках?

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

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

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

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