Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я упоминала, что специально использую UI, дабы обозначить, что он должен находиться на вершине тест-пирамиды, в то время как в других случаях вершина называется E2E. Чувствую, надо подробнее это объяснить.

UI – это пользовательский интерфейс. UI-тестирование относится к тестированию, выполняемому через UI.

E2E – это end-to-end тестирование. Это тесты, которые выполняются от входной точки в приложения до выхода из него.

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

Однако они отличаются важными нюансами.

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

Всем привет! Я старший преподаватель направления функционального тестирования в «ЛАНИТ Экспертиза». К нам в штат приходят люди из разных профессий и с разным уровнем знаний. Поэтому в компании организованы курсы обучения практикам тестирования, которые уже стали базовыми. Одной из них является тестирование с помощью 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-специалистам, но и бэкенд-разработчикам начального уровня, а также всем, кто хочет углубить свои познания в области взаимодействия с БД.