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

«Дедушка российского тестирования», тестировщик с 50-летним стажем Александр Александров объясняет, почему классическая научная литература по тестированию по-прежнему актуальна и с каких основополагающих текстов стоит начинать свой путь в этой профессии.

Привет! Меня зовут Сергей, я более 11 лет в тестировании, и успел за это время перепробовать множество разных подходов в QA — начинал простым тестировщиком, затем строил и развивал всевозможные отделы тестирования и автоматизации, а сейчас работаю в QIWI.

В этой серии постов я хочу поговорить с вами про тестирование трех популярных так называемых не-REST-бэкендов. Самое главное для начала — определиться с терминами, договоримся, что везде в тексте, где я упоминаю REST — речь идет именно о REST HTTP-бэкенде. Наверняка многие из вас с ним работали и вообще неплохо знакомы.

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

Под катом — разбор тестирования первого из этой тройки, GraphQL. Все примеры в посте я делал с помощью Postman, он достаточно популярен и доступен, чтобы вы при желании могли всё быстро в нём повторить.

Всем привет! Меня зовут Вадим Лунин. Я — QA Manager из Альфа Банка в Беларуси. Этой статьёй  хочу начать цикл статей по инструментам, которые мы используем для тестирования наших продуктов в Альфа Банке.

Привет, хабр. Меня зовут Кияшева Екатерина и я руковожу тестированием. Сегодня хочу поделиться своим чит‑листом обо всем.

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

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

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

Салют, Хабр!

Меня зовут Анатолий, и я работаю в компании Space307 в должности QA-инженер.

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

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

Отдельное спасибо хочу выразить коллегам, которые помогали в составлении, дополнении и ревью этой статьи. Simply the best!

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

Всю полезность из фидбэка переработаю для прокачки этой статьи.

Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS.

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

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

• В responsive mode браузера на компьютере

• С помощью эмуляторов iOS и Android

• На физическом iPhone и Android-устройстве через USB

• С помощью Browserstack

Вы не используете очередь? Вы просто не умеете её готовить. Но прежде чем этому научиться, нужно разобраться, что это вообще такое и где это применяется. Потому что большинству достаточно 10 000 запросов в секунду, а это дает любой брокер. Но если вам нужно больше, придется погрузиться в очереди достаточно глубоко.

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

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

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

Экономия затрагивает самые разные сферы проекта и специалистов. В этой статье рассмотрим обеспечение качества (QA). Бизнес нередко считает, что тестирование – та часть проекта, на которой можно сэкономить, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать. Наш коллега Андрей на конкретных примерах покажет, к каким последствиям приводят наиболее популярные случаи экономии на QA.

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

SQL-инъекция (SQLi) - это уязвимость веб-безопасности, которая позволяет злоумышленнику вмешиваться в запросы, которые приложение делает к своей базе данных. Как правило, это позволяет просматривать данные, которые он обычно не может получить. Это могут быть других пользователей, или любые другие данные, доступ к которым имеет само приложение. Во многих случаях злоумышленник может изменять или удалять эти данные, вызывая постоянные изменения в содержимом или поведении приложения.

Сложно найти тестировщика, который не знал бы о DevTools, но еще сложнее найти человека, который знает о них всё. Помимо знакомой всем базовой функциональности, есть много полезных и удобных фич. А если не ограничиваться Хромом, то их количество запросто можно удвоить.

Осенью на нашей конференции по тестированию Heisenbug Татьяна Дроздова рассказала о возможностях DevTools в Chrome, Firefox и Safari, и доклад очень понравился участникам. Сейчас мы готовим следующий Heisenbug, где Татьяна выступит с новым докладом о браузерных расширениях — а в ожидании этой конференции сделали для Хабра текстовую версию доклада с предыдущей. Далее текст идёт от лица Татьяны.