🖍Не является избыточно сложным. Сложный тест использует большое количество функций, переменных или других атрибутов тестируемого ПО. Сложность нежелательна в случаях, когда программа подверглась многочисленным переменам или при тестировании множества новых функций за раз. Если программа содержит много дефектов, она провалит сложный тест так быстро, что вы не успеете его толком прогнать.
Группы тестирования, которые в значительной степени полагаются на сложные тесты, жалуются на дефекты, которые блокируют дальнейшее тестирование. Такие дефекты мешают исполнению теста и не дают тестировщикам узнать что-либо о других аспектах программы, которые должны быть выявлены в ходе данных тестов. Поэтому, на начальной стадии тестирования желательно пользоваться простыми тестами. По мере же роста стабильности программы или (в экстремальном программировании или в эволюционной модели разработки) по мере добавления в программу более стабильных функций, должна увеличиваться и сложность исполняемых тестов.

Большой долей вероятности поможет тестировщику или программисту понять некоторые
аспекты программы, заказчика или среды. Иногда мы выполняем тесты для того, чтобы понять продукт, понять принцип его работы или возможные риски. Позже мытможем разработать тесты, которые выявили бы недостатки продукта, но на ранней стадии тестирования нас больше
интересует два вопроса: что это и как это тестировать.
Многие тесты, подобные этому, не будут использоваться повторно. Однако в проектах, основанных на результатах тестирования, изменения в коде программы зачастую делаются для пробы, в целях экспериментирования. При
этом ожидается, что набор (модульных) тестов предупредит программиста о побочных эффектах. В таких условиях, тест может проектироваться для извещения об изменениях в производительности, о разности в погрешности округления или других изменениях, которые не являются дефектами. Неожиданное изменение поведения программы может стать сигналом программисту о том, что модель, отображающая его код или изменения в коде, неполна или ошибочна и требует дополнительного тестирования и поиска неполадок.

#Postman — удобный HTTP-клиент для тестирования веб-сайтов. Он позволяет сформировать и отправить HTTP-запросы, чтобы протестировать API

Из Обзор способов и протоколов аутентификации в веб-приложениях :
под идентификацией понимают получение вашей учетной записи (identity) по username или email;
под аутентификацией — проверку, что вы знаете пароль от этой учетной записи,
а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

Хорошим примером использования API может служить процесс быстрой регистрации в различных приложениях используя аккаунт любой из предложенной социальной сети, когда посредствам специального API социальной сети (например, Вконтакте, Facebook) сторонние компании получают возможность использовать специальный код и #API для предоставления Вам оперативного и упрощенного доступа к их продукту.

Внимание: здесь я использую интерфейс приложения, для того, чтобы протестировать #API.
Но есть случаи, когда не зная #UI, нужно протестировать АPI, тем самым знать токен авторизации и идентификатор клиента и это совсем другая тема. И здесь краткий обзор.

понятия:
#API (Application Programming Interface) представляет собой совокупность различных инструментов, функций, реализованных в виде интерфейса для создания новых приложений, благодаря которому одна программа будет взаимодействовать с другой.

#JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания как человеком, так и компьютером. Он основан на подмножестве языка JavaScript
JSON основан на двух структурах данных:
✨ Коллекция пар ключ/значение. В разных языках, эта концепция реализована как объект, запись, структура, словарь, хэш, именованный список или ассоциативный массив.
✨ Упорядоченный список значений. В большинстве языков это реализовано как массив, вектор, список или последовательность

#видео

Про #Postman :
Postman - помощь в тестировании REST API

Postman - Быстрый Старт для Разработки и Тестирования

Postman – ваш помощник в тестировании API

#HttpStatusCode с твич документации ✨

Плюс информация https://dev.twitch.tv/docs/authentication
https://dev.twitch.tv/docs/api

‼️Нельзя терять ни одной найденной ошибки
База дефектов - это база данных, в которую заносятся обнаруженные в приложении дефекты
🔶 За управление перечнем дефектов приложения обычно отвечает тест-менеджер

❗️ Основное назначение базы дефектов - слежение за ошибками с целью исправления всех тех ошибок, которые могут быть исправлены
Каждый, кто должен знать об ошибке, узнает о ней сразу же после ее обнаружения
🖍Ошибка не может остаться неисправленной из-за того, что о ней забыли
🖍Ошибка не может остаться не исправленной из-за прихоти программиста
🖍Ошибка не остается не исправленной из-за плохого взаимодействия между менеджерами, разработчиками и тестировщиками

#дефекты #дефект #теория

#Postman — это мощный набор инструментов для тестирования #API . Он является средой разработки, которая позволяет создавать, тестировать, контролировать и публиковать документацию для API.

#Запросы :

POST добавляет новую запись в базу данных.

GET получает запись из базы данных.

PUT берет запись из базы и заменяет ее новой.

PATCH меняет существующую в базе запись.

DELETE удаляет запись из базы.

📚Справочник по кодам статуса HTTP

#HttpStatusCode
Коды 3xx (перенаправление)
Коды 4xx (ошибка клиента)
Коды 5xx (ошибка сервера)

#SQL - немного про SQL
ОПЕРАТОР SELECT
Хочу напомнить, что данный язык запросов можно
изучить на сайте
https://www.sql-ex.ru/

Оператор SELECT осуществляет выборку из базы данных

Команда DISTINCT позволяет выбирать только уникальные значения из базы данных

Команда WHERE задает условие, по которому будут выбираться строки из базы данных.

SELECT * FROM имя_таблицы SELECT * FROM имя_таблицы WHERE условие

SELECT поле1, поле2... FROM имя_таблицы WHERE условие

При выборке: SELECT DISTINCT поле FROM имя_таблицы WHERE условие

При подсчете: SELECT COUNT(DISTINCT поле) FROM имя_таблицы WHERE условие

При суммировании: SELECT SUM(DISTINCT поле) FROM имя_таблицы WHERE условие

В запросе можно задавать следующие условия:
• сравнение текста;
• сравнение численных значений;
• логические операции AND (и), OR (или) и NOT (отрицание).

Какой проект можно написать в Инстаграме по желанию #SQL

Типы данных #SQL
https://sql-language.ru/sqldatetype.html

Цитирую важное : "Часто на интервью встречаются вопросы про различие верификации и валидации продукта:
📌Верификация – это подтверждение, что были выполнены все требования предъявляемые к ПО

📌Валидация – это проверка того, что ПО соответствует потребностям пользователей и его можно использовать в реальной жизни.

Другими словами: верификация показывает, что у нас есть все необходимые компоненты продукта, он соответствует всем заявленным требованиям, а валидация показывает, что продукт может быть применен в тех условиях и таким образом, как этого ожидал пользователь\заказчик."

#теория

👏🏼
По коробу поскреби, по сусеку помети; авось и виды тестирования и наберутся👀
🤞🏽Возможно, что-то и пропустила, но каждый вид тестирования постараюсь в будущем разобрать, а вы по крайней мере будете знать какова классификация видов тестирования

👇🏻 Классификация видов тестирования👇🏻:
🔷С исполнением и без исполнения кода:
🔸Статическое
🔸Динамическое

🔷Различные знания о структуре кода:
🔸Черный ящик,
🔸серый ящик ,
🔸белый ящик

🔷По свойствам тестируемого объекта:
🔸функциональность,
🔸производительность,
🔸совместимость,
🔸надежность,
🔸удобство

🟧Функциональное тестирование – проверка того, что продукт выполняет свое прямое назначение, предоставляет функции, требуемые заказчиком\пользователями:
🔸🔸тестирование заявленной функциональности,
🔸🔸тестирование установки (инсталляции),
🔸🔸тестирование графического пользовательского интерфейса,
🔸🔸тестирование защищенности (например, банковская сфера),
🔸🔸тестирование целостности данных,
🔸🔸тестирование настройки и лицензирования

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

🔷По изменениям (после установки программного обеспечения для подтверждения работоспособности приложения или правильности исправления дефекта):
🔸регрессионное тестирование,
🔸подтверждающее тестирование,
🔸дымовое тестирование,
🔸тестирование сборки,
🔸санитарное тестирование или проверка согласованности/исправности,
🔸повторное тестирование

🔷По типу прогона тестов:
🔸ручное,
🔸автоматизированное

🔷По изолированности компонент:
🔸системное,
🔸интеграционное,
🔸модульное

🔷По версии функционала:
🔸тестирование новой функциональности
🔸регрессионное тестирование

🔷По ожидаемому результату:
🔸позитивное тестирование
🔸негативное тестирование

🔷По уровню планирования:
🔸тестирование по тестовым кейсам
🔸исследовательское тестирование

🔷По степени подготовки к тестированию тестировщиком:
🔸Ad-hoc - Свободное или Интуитивное тестирование,
🔸Тестирование по документации (формальное тестирование)

🔷По исполнителям тестирования:
🔸Альфа-тестирование,
🔸Бета-тестирование,
🔸приемочное тестирование

🔷Другие виды тестирования:
🔸тестирование файлов cookie,
🔸тестирование потоков,
🔸тестировании интерфейса прикладного программирования,
🔸эталонное тестирование,
🔸параллельное/многопользовательское тестирование,
🔸Fuzz тестирование,
🔸тестирование N+1,
🔸Ramp тестирование,
🔸тестирование на переносимость,
🔸A/B тестирование,
🔸сквозное (E2E - End–to–End) тестирование,
🔸тестирование хранилища,
🔸тестирование на проникновение
#видытестирования