Введение в тест-анализ #2: проблемы с поиском серых зон

🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?

🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».

🍩 требований нет.
Такое тоже бывает)

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

Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику

#rdclr_QA #read

Тестирование API: на что обратить внимание

API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.

Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.

🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.

🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?

Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.

Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API

#rdclr_QA #read

Всем привет и хорошего начала недели! Написала так много, что побуду с вами чуть подльше. 😺 Продолжаем тему тестирования, и кто не знаком, — дежурю я, Настя, middle QA. ✌🏻

Web-приложения и особенности их тестирования

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

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

Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.

Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.

Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.

Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read

Библиотека: Все необходимое для ручного тестирования Web-приложений

🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit

🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler

🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com

👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья

🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete

#rdclr_QA #product #read

Типы мобильных приложений и как их тестировать

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

🌂 Чаще всего приложения для мобильных телефонов загружают на таких площадках, как Google Play или AppStore. Разработчики создают приложение либо под конкретную платформу, либо сразу для нескольких. Наиболее популярные операционные системы, для которых выпускаются новинки — это iOS, Android, Windows Phone.

🧚🏿‍♂️ Нативные приложения — это приложение, разработанное специально для одной платформы и на родном (с англ. native — родной) для определённой платформы языке программирования. Для Android этим языком является Java, тогда как для iOS — objective-С или Swift.

💃 Мобильные веб-приложения оптимизированы для легкого и удобного использования на мобильных устройствах. Запуская такие мобильные веб-приложения, пользователь выполняет все те действия, которые он выполняет при переходе на любой веб-сайт.

🧜🏿 Гибридные приложения представляют собой сочетание веб и нативных приложений. В особенности, имеется в виду их кроссплатформенность и доступ к функционалу смартфона.

🥵 Как тестировать мобильные приложения? 🥶
Любое приложение на Android, Windows Phone или iOS делится на важные блоки: front- и back-end. В первый входят элементы, которые использует пользователь, а второй является скрытой частью, с которой работают исключительно программисты, применяя для этого серверный софт. Таким образом эта система работает в совокупности, но с чётким разделением функционала и задач. Как тестировать?

1. Тестирование на различных платформах, версиях ОС, моделях устройств.
2. Использование эмуляторов или реальных устройств.
3. Работа с разными видами интернет-подключений (Wi-Fi, 4G, 3G, отсутствие связи).
4. Переход в фоновый режим при поступлении звонков и sms, срабатывании будильника.
5. Процесс переустановки и обновления приложения до новой версии.

#rdclr_QA

Бибилиотека: все, что нужно для тестирования мобильных приложений 📚

📝 Теория, книги, статьи:
Чек-лист тестирования мобильных приложений
Push-уведомления
UI-элементы и жесты в мобильных приложениях

🖇 Guidelines:
iOS Interface Guidelines
Android Components

💻 IDE:
Android Studio
Xcode

🧩 Android specific:
Android Debug Bridge (adb)
Android developer options
Exerciser Monkey
Apkanalyzer

⚖️ Аналитика:
Firebase Crashlytics

⚙️ Симуляторы и эмуляторы Android:
Genymotion
BrowserStack App Live

🛠 Симуляторы и эмуляторы iOS:
Xcode Simulator

🍪 Фермы устройств:
Firebase Test Lab
Microsoft App Center
Samsung Remote Test Lab
AWS Device Farm
HUAWEI DIGIX Lab Test Services

🚜 Распределение платформ и устройств:
Мобильные ОС
Worldwide Mobile Vendor

🎮 Инструменты прокси трафика:
Fiddler
Charles Proxy
Mitmproxy

#read #rdclr_QA

Android Debug Bridge (adb)

Android Debug Bridge (adb) — инструмент командной строки, который позволяет взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, которую можно использовать для выполнения различных команд на устройстве.

Это клиент-серверная программа, состоящая из трех компонентов:
🌵 Клиент, отправляющий команды.
Клиент работает на вашей машине разработки. Вы можете вызвать клиента из терминала командной строки, введя команду adb.

🍀 Демон, запускающий команды на устройстве.
Демон работает в фоновом режиме на каждом устройстве.

🌳 Сервер, который управляет обменом данными между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.

Установка ADB
adb входит в пакет Android SDK Platform-Tools. Скачать этот пакет можно с помощью SDK Manager , который устанавливает его в android_sdk/platform-tools/. Или, если вам нужен автономный пакет Android SDK Platform-Tools, вы можете скачать его с официального сайта.

Основные команды:
$ adb devices — просмотр списка устройств;
$ adb get-state — состояние устройства;
$ adb reboot — перезагрузка устройства;
$ adb install -f /path/some_name.apk — можно выполнить установку приложения во внутреннюю память;
$ adb shell pm list packages — список установленных приложений;
$ adb logcat — просмотр журналов системы и приложений.

Еще можно почитать про команды для ADB :)

#rdclr_QA #read

Куда развиваться тестировщику?

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

В тестировании можно условно выделить три направления:
🚙 ручное — продукт тестируют вручную;
🚕 автоматизированное — повторяющиеся тесты проводят автоматически, чтобы не тратить время на одни и те же проверки;
🚑 нагрузочное — специальными инструментами и скриптами проверяют, выдержит ли приложение высокую нагрузку. Например, при большом количестве пользователей или атаке ботов.

😎 Также выделяют уровни специалистов. В каждой компании — по-разному, но чаще всего уровни делят так:
Младший специалист, или джуниор (англ. junior)
Джуниор спрашивает, как сделать задачу: чаще всего он ещё не может сделать её или быстро подстроиться к новым условиям, вводным данным и окружению.

Специалист, или миддл (англ. middle)
Миддл спрашивает, какую задачу нужно сделать: он уже умеет выполнять несложные задачи самостоятельно — ему нужно только задать направление.

Старший специалист, или синьор (англ. senior)
Синьор спрашивает, зачем делать эту задачу: он может оценить полезность изменений, заметить потенциальные риски и спроектировать план задачи.

Ведущий специалист, или лид (англ. lead)
У ведущего специалиста уровень и экспертиза выше синьора. Как правило, он ведёт проекты либо руководит подразделением, либо принимает ключевые решения по технической части. Бывает и то, и другое одновременно — именно такую роль чаще всего играет QA Lead, он же руководитель отдела тестирования.

Сейчас компании все чаще выделяют такие позиции, как strong junior и strong middle, а в матрице скиллов конкретизируют требования к специалисту под каждый уровень. Также следует помнить, что в каждой компании свои требования и в компании «А» ты можешь быть junior, а в компании «В» middle.

В любом случае, я желаю удачи тебе в дальнейшем развитии, карьерного роста и вдохновения от дела, которым ты занимаешься! 🥂
#rdclr_QA

Разработчики из Воронежа, приходите знакомиться с нами в офлайне! 🀄

26 апреля собираемся на новый митап из серии RDCLR.HOME — о «Карте развития PHP-разработчика» расскажет специалист Red Collar Иван Марков.

Ждём в гости тех, кто только начинает изучение PHP, или уже освоил базы и хочет вырасти до уровня Middle/Senior.

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

Митап по традиции пройдет в нашем офисе в бизнес-парке «Текстильщики» по адресу: ул. Текстильщиков, 5б, 3 подъезд, 3 этаж.

Вход свободный, но количество мест ограничено. Успейте зарегистрироваться по ссылке: https://forms.gle/W66uESCgUEFBLzeF6


Подробнее о том, что такое RDCLR.HOME, читайте тут: https://vk.com/rdclr.home

«Быть тим-лидом: ожидания и реальность» — первый материал от Red Collar на Хабре собрал больше 7 тысяч просмотров за неделю. 🦾 👾

Наш Java-разработчик Макс рассказал о том, как специалисту (вы)расти в тим-лида, научиться ловить баланс качества и сроков, прогнозировать риски и не стать по пути «мелким тираном».

🔹 Прочитать материал будет ценно не только разработчикам, но и руководителям любых направлений — Макс отдельно выделил вопросы грамотной коммуникации, актуальные для всех.

Читайте по ссылке: https://lnkd.in/ezdfPxtQ 🤝

Привет, меня зовут Павел, я backend-разработчик Red Collar! Пишу на Java/Kotlin. 🦾

На этой неделе буду автором на канале и расскажу вам:

- о принципах SOLID
- о Spring Data JDBC и её подводных камнях
- о Keycloak

Стартуем прямо сейчас!

Микросервсиная архитекутера

Наверняка вы уже работали с приложением, построенным на микросервисах, а если нет, то слышали об этой архитектуре.

Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.

#rdclr_backend #Java

Друзья, привет! На связи всё так же я, Павел, Java-разработчик Red Collar. 🤝

Решил потестить новый формат, чтобы текст легче воспринимался, а иллюстрации кода не терялись потом в поиске.

В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾

Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16


#rdclr_backend #Java

Друзья, всем привет! Это вновь я, Java-разработчик Red Collar Павел.
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.

Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.

Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24

#rdclr_backend #Java

Авторизация, идентификационные брокеры

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

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

💡Почему Keycloak? Это продукт с открытым исходным кодом, предназначенный для идентификации и контроля доступа.
Keycloak версий 16.0 и ниже использует сервер WildFly, но начиная с версии 17.0.0 Keycloak перешел на Quarkus и стал самостоятельным фреймворком. Более подробно можно почитать здесь.


🙌🏻 Keycloak предлагает:

- единый вход (SSO)
- брокерскую идентификацию и вход в систему
- управление пользователями
- клиентские адаптеры
- консоль администратора и консоль управления учетными записями

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


👾Из основного функционала стоит выделить:

- Single-Sign On and Single-Sign Out для браузерных приложений.
- Поддержку OpenID/OAuth 2.0/SAML.
- Identity Brokering — это аутентификация с помощью внешних OpenID Connect или SAML идентификационных провайдеров.
- Social Login – поддержку Google, GitHub, Facebook, Twitter для идентификации пользователей.
- Кастомизацию решения на основе фирменного стиля компании.
- Login Flows — возможна саморегистрация пользователей, восстановление и сброс пароля и прочее.
- Session Management — администраторы могут управлять из единой точки сессиями пользователей.
- Token Mappers — это привязка атрибутов пользователей, ролей и иных требуемых атрибутов в токены.
- Гибкое управление политиками через realm, application и пользователей.
- Service Provider Interfaces (SPI) — большое количество SPI, позволяющих настраивать различные аспекты работы сервера: потоки аутентификации, идентификационных провайдеров, сопоставление протоколов и многое другое.

🔥Как итог — с помощью Keycloak мы можем быстро настроить единый сервер для регистрации/авторизации пользователей и кастомизировать все с наименьшими затратами ресурсов.