Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Вы — начинающий тестировщик? Работать над приложением в команде из пяти и более разработчиков может показаться надёжным способом создать продукт без багов. Но правда в том, что количество разработчиков в проекте никоим образом не влияет на итоговое число ошибок.
Как бы ни был опытен разработчик — баги всё равно случаются. Не существует такого понятия, как «идеальный продукт».

Со временем разработчики начинают понимать, какие баги вы чаще всего находите, и в продукте становится меньше багов определённого типа — по сравнению с тем, что было ещё пару спринтов назад. Однако это не повод расслабляться. Именно тестировщик должен продолжать искать новые способы находить баги — до того, как они попадут на прод.

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

Вот несколько таких техник, которые, по моему опыту, приносят хорошие результаты.

Автор: Никита Филонов
Оригинальная публикация

Вступление

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

Правильный профиль нагрузки — это не просто цифра в настройках. Это ответ сразу на три вопроса:

• Что мы нагружаем (какие сервисы или сценарии),

• Как мы нагружаем (параметры, последовательность, интенсивность),

• Почему именно так (данные, прогнозы или требования).

Цель этой статьи — дать практические рекомендации, которые помогут правильно выбрать профиль нагрузки и сделать тестирование осмысленным и полезным, а не просто «запуском ради отчётности».

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

Автор: Эди Стоукс, Рабай’а Браун (Ady Stokes, Rabi'a Brown)
Оригинал статьи
Перевод: Ольга Алифанова

Синие экраны — это только начало

Пока большая часть мира восстанавливалась от «чёрного лебедя» — масштабного сбоя, связанного с CrowdStrike и Azure, — команда Ministry of Testing решила поделиться несколькими лёгкими и забавными историями о том, как любимые устройства (и маломощные рабочие ноутбуки) умирали или просто притворялись мёртвыми.

Примечание: некоторые из вас, возможно, никогда не видели печально известный "синий экран смерти" Windows, который мы здесь будем иногда называть BSoD (Blue Screen of Death). Читайте дальше, чтобы узнать подробности.

Задача любого тестировщика — проверять продукт на соответствие установленным требованиям и своевременно отлавливать любые баги и ошибки. В идеальных условиях или небольших проектах эта схема работает безотказно. Но в ситуациях, когда над продуктом работает несколько команд разработки, в релизы попадает по 30–70 задач, а обновления выкатываются каждую неделю, фокуса тестировщиков может просто не хватить. В таких условиях не обойтись без Quality Gates.

Меня зовут Юлия Садовникова. Я старший специалист по тестированию в команде Core Android компании ОК. В этой статье я расскажу о Quality Gates в ОК и о том, как QA может не просто тестировать, а реально влиять на проект и процессы.

Автор: Хосе Каррера (Jose Carrera)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое тестирование, управляемое через страх?

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

Такое поведение может быть вызвано разными причинами: давлением со стороны бизнеса, нехваткой знаний в предметной области, жёсткими сроками и т.д. Ещё один важный аспект — это восприятие качества внутри команды и бизнеса:

• Разделяется ли ответственность за качество между всеми участниками команды?
• Где находятся контрольные точки качества (quality gates)?

Если процесс построен так, что QA-инженеры становятся единственными "хранителями качества", без полноценного участия других специалистов, это приводит к тому, что тестирование превращается в деятельность, движимую страхом — страхом быть обвинёнными в том, что баг не был обнаружен до выхода в продуктив.

Автор: Ольга Назина (Киселёва)

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется. 

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users. 

Я выложила файлы и запросы, используемые в статье, на гитхаб — можно скачать и использовать «на пробу», так как Users открытая бесплатная система, все запросы будут работать.

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

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

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

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

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