Приветствую?

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

Меня зовут Антон, я QA Mobile в компании MobileUp. В статье я разберу, что такое пермишены, для чего нужны, какие виды существуют, где их можно найти и как тестировать.Эту статью я пишу исключительно с точки зрения ручного тестирования, но в конце текста оставлю интересные ресурсы, которые могут пригодиться для QA Auto (но это не точно ?).

Для написания автотестов используются XPath и CSS-селекторы. Они помогают найти элемент на странице, чтобы потом с ним как-то взаимодействовать (кликнуть, ввести текст, или что-то другое).

Я видела много статей о том, что это вообще такое, но мне очень не хватало шпаргалки по разным селекторам, причем в разрезе «Вот он в CSS и он же в XPath» для сравнения. 

А мне такое для студентов надо. Поэтому решила сделать сама. Вдохновлялась страничкой «Xpath cheatsheet», но сделала на свой вкус — под автоматизацию, а не XPath вообще. И с комментариями, с ними удобнее. 

Пишите, если где-то накосячила. Хотя я все селекторы проверяла на тестовых страницах, но мало ли… И надеюсь, вам такая шпаргалка тоже пригодится! =)

Привет, Хабр! Меня зовут Кристина. Я работаю в Яндекс Практикуме ревьюером на курсе «Инженер по тестированию», ментором тестировщиков в Мастерской программирования и руководителем соревновательных видов IT-практики (багатонов, хакатонов и кейс-чемпионатов).

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

Привет, Хабр! В этой статье я хотел бы рассказать о методе работы с WebSocket, который я часто применяю в своих разработках. Если кратко, WebSocket — это, пожалуй, самое частое, что я использую в своих проектах. Мне очень важно, чтобы сервер мог общаться с клиентом в двустороннем режиме, но использование обычного WebSocket не всегда комфортно. Для решения этой задачи я часто пишу какой-либо обработчик, и, суммируя суть того, что именно делает этот обработчик, я решил написать небольшую и очень простую библиотеку.

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

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. По ходу перевода я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.

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

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

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

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

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

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

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

Коллеги, всем привет!

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

О чём это всё

Когда вы запускаете новый продукт, обеспечение качества (QA) очень важно. Независимо от того, отдаете ли вы аутсорсинг команде QA или выполняете внутренние проверки, вам необходимо создать план тестирования. Это гарантирует, что в процессе обеспечения качества ничего не будет упущено.

Если вы новичок в планировании тестирования, эта статья ответит на все ваши вопросы и предоставит основу для планирования.

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.