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

Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью API запросов, или, как его еще называют, тестирование API. И сегодня для тех, кто этим занимается, я постараюсь доступным языком рассказать, как использовать этот формат для описания тестовых данных, подключаемых к прогонам коллекций в Postman.

Автор: Сватика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

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

Одна из таких практик – это «перехватывать» API, что добавит очков зрелости тест-стратегии и фреймворку. Перехват означает взятие контроля над API путем подслушивания запросов и манипулирования ими через изменение свойств запроса или ответа. Я считаю, что это очень мощный инструмент автоматизаторов, помогающий создавать устойчивые тесты пограничных случаев.

В этой статье мы разберемся, что такое перехват API, и как успешно им воспользоваться, тестируя пользовательский интерфейс при помощи Cypress.

Автор: Кирилл Корнаков

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

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

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

Автор: Сватика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

Большинство тестировщиков в курсе, что Postman – один из самых популярных инструментов тестирования API. Я пользовалась им больше, нежели иными аналогичными инструментами, и просто без ума от его интерфейса. По моему опыту, наиболее популярные возможности Postman – это предварительные скрипты, методы авторизации, интеграция библиотеки Faker для случайных тестовых данных, и та, которую я намерена изучить и исследовать – Flows.

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

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

Автор: Фроленков Роман
Оригинал статьи

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд.

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

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

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

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

Под катом — наша шпаргалка по распространённым багам в работе баз данных. Разбили их по категориями, снабдили примерами и объяснили первопричины появления. Надеемся, будет полезно не только QA-специалистам, но и бэкенд-разработчикам начального уровня, а также всем, кто хочет углубить свои познания в области взаимодействия с БД.

Автор: Эш Уинтер (Ash Winter)
Оригинал статьи
Перевод: Ольга Алифанова

Службы геолокации: критичны для функциональности, сложны для тестирования

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

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

Короче говоря, для качественного тестирования приложения нужно улучшать его тестируемость.