Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
QA создатель Mind Map: QA

1. Погружение в QA

1.1. Что такое тестирование?

1.1.1. Тестирование - это проверка функционала на соответствие ожидаемой реальности и фактической, техническое исследование программы которое мы делаем, для того чтобы получить знания о качестве программы, чтобы передать информацию стейкхолдеру (менеджерам или директорам).

1.2. Цели тестирования? За что платят?

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

1.3. Обычный рабочий день QA

1.3.1. Обычный рабочий день QA включает в себя планирование тестов, выполнение тестов, анализ результатов, запись дефектов и взаимодействие с другими членами команды для улучшения качества программного обеспечения.

2. База тестирования

2.1. Что такое QA, QC и Testing?

2.1.1. Тестировщик или специалист по тестированию — это обычно начинающий специалист (джун), который выполняет тестирование по готовой документации, такой как чек-листы и тест-кейсы. Основная задача тестировщика — прохождение тестов и сравнение фактического результата (ФР) с ожидаемым результатом (ОР).

2.1.2. QA инженер — это специалист, занимающийся обеспечением качества программного обеспечения на всех этапах разработки.

2.1.3. QC инженер или специалист по контролю качества подключается к проекту после завершения разработки и занимается проверкой соответствия продукта требованиям заказчика.

2.1.3.1. Разница их в том, что QA занимается и валидацией, и верификацией, а QC занимается только валидацией.

2.2. Верификация и Валидация

2.2.1. Верификация (статическое тестирование) — это процесс проверки, что продукт разрабатывается правильно по спецификациям (делаем продукт правильно). Верификация проводится без запуска кода и включает проверку документации, требований, архитектуры и дизайна.

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

2.3. Что такое требования ПО?

2.3.1. Требования - это спецификация (описание) того, что должно быть реализовано в программном обеспечении. Они играют ключевую роль в обеспечении качественного результата, поэтому важно, чтобы они были четкими и понятными. Бывают системные и бизнес требования.

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

2.3.2. Атрибуты требований

2.3.2.1. Непротиворечивость: Требования не должны содержать внутренних противоречий или противоречий другим документам.

2.3.2.2. Атомарность: Требования не должны быть разбиты на отдельные части без потери деталей.

2.3.2.3. Корректность: Требования должны точно описывать разрабатываемый функционал.

2.3.2.4. Проверяемость: Требования должны быть сформулированы так, чтобы можно было однозначно определить, выполнены они или нет.

2.3.2.5. Полнота: Требования должны содержать всю необходимую информацию для реализации функциональности.

2.3.2.6. Недвусмысленность: Требования должны быть сформулированы однозначно.

2.4. Принципы тестирования

2.4.1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects) Тестирование показывает, что в программном обеспечении есть дефекты. Оно снижает вероятность их наличия, но не гарантирует полное отсутствие ошибок.

2.4.2. Исчерпывающее тестирование невозможно (Exhaustive testing is impossible) Полное тестирование с использованием всех возможных комбинаций входных данных, результатов и предусловий физически невыполнимо, за исключением тривиальных случаев.

2.4.3. Раннее тестирование (Early testing) Тестирование должно начинаться на ранних стадиях жизненного цикла разработки ПО. Это позволяет находить дефекты как можно раньше и устранять их до того, как они станут критическими.

2.4.4. Скопление дефектов (Defects clustering) Большая часть дефектов находится в ограниченном количестве модулей. Это явление называется "скоплением дефектов".

2.4.5. Парадокс пестицида (Pesticide paradox) Если повторять одни и те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты. Это называется "парадоксом пестицида".

2.4.6. Тестирование зависит от контекста (Testing is context depending) Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.

2.4.7. Заблуждение об отсутствии ошибок (Absence-of-errors fallacy) Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю и удовлетворять его ожиданиям и потребностям. Это включает в себя прохождение как верификации, так и валидации.

2.5. Серьезность и приоритет (Severity vs Priority)

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

2.5.2. Severity — это степень влияния дефекта на работу приложения. Дефекты могут быть блокирующими, критическими, значительными, незначительными и тривиальными в зависимости от их влияния на систему.

2.5.3. Priority — это срочность исправления дефекта. Приоритеты могут быть высокими, средними и низкими в зависимости от необходимости их исправления.

2.6. SDLC, STLC и SBLC

2.6.1. SDLC (Software Development Life Cycle) SDLC — это жизненный цикл разработки программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при создании программного продукта.

2.6.1.1. Этапы SDLC: Планирование Анализ требований Проектировка и дизайн Разработка ПО Тестирование Развертывание/релиз

2.6.2. STLC (Software Testing Life Cycle) STLC — это жизненный цикл тестирования программного обеспечения. Он представляет собой структурированный процесс, состоящий из различных фаз и этапов, которые выполняются при проведении тестирования программного продукта.

2.6.2.1. Этапы STLC: Анализ требований Стратегия тестирования (уточнение критериев приемки (DoD, DoR)) Разработка тестов Выполнение тестов и фиксирование результатов Анализ результатов и отчетность

2.6.2.1.1. Definition of Ready (DoR) — это набор критериев, которые должны быть выполнены перед началом работы над задачей или пользовательской историей. DoR помогает команде убедиться, что задача готова к разработке и тестированию.

2.6.2.1.2. Definition of Done (DoD) — это набор критериев, которые должны быть выполнены для того, чтобы задача или пользовательская история считалась завершенной. DoD помогает команде убедиться, что работа выполнена качественно и готова к выпуску или демонстрации.

2.6.3. SBLC (Software Bug Life Cycle) SBLC — это жизненный цикл бага, который описывает этапы, через которые проходит баг от момента его обнаружения до окончательного разрешения.

2.6.3.1. Этапы SBLC: Новый ⬇️ Назначен ⬇️ Открыт ➡️ Отклонен или Отложен ⬇️ Исправлен ⬇️ Ожидает повторного тестирования ⬇️ Повторно тестируется ➡️ Повторно открыт ⬇️ Проверен ⬇️ Закрыт

2.6.3.1.1. Баг — это различие фактического от ожидаемого результата. Это ошибка или дефект в программном обеспечении, который приводит к неправильной работе программы.

3. Компьютер саинс

3.1. Фронтенд

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

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

3.1.2. Технологии фронтенда

3.1.2.1. Различные фреймворки и библиотеки, такие как React, Angular, Vue.js и другие, помогают разработчикам упростить и ускорить процесс создания интерфейса и его функциональности.

3.1.2.2. HTML (HyperText Markup Language) — это язык разметки, используемый для создания структуры веб-страниц. Он определяет элементы, такие как заголовки, абзацы, ссылки, изображения и другие компоненты.

3.1.2.3. CSS (Cascading Style Sheets) — это язык стилей, который используется для описания внешнего вида HTML-документов. Он определяет такие параметры, как цвет, шрифты, отступы и расположение элементов на странице.

3.1.2.4. JavaScript — это язык программирования, который позволяет создавать динамические и интерактивные веб-страницы. Он может изменять контент HTML и стили CSS на лету, реагируя на действия пользователя.

3.2. Бэкенд

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

3.2.1.1. Бэкенд обрабатывает запросы, поступающие от фронтенда (части приложения, которую видит пользователь), выполняет нужные действия и отправляет обратно результаты фронтенду для отображения пользователю.

3.2.2. Технологии бэкенда

3.2.2.1. Бэкенд может использовать различные технологии и языки программирования в зависимости от его функциональности. Это может быть написано на: Python, JavaScript (Node.js), Java, PHP, Ruby, Go и на других языках.

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

3.2.2.2.1. Сервер обрабатывает запросы от клиентов, выполняет нужные операции, и отправляет ответы обратно клиентам.

3.3. Дополнительные ключевые аспекты

3.3.1. Куки — это небольшие файлы, которые веб-сайты сохраняют на устройстве пользователя для хранения данных о его сессии, предпочтениях и активности на сайте.

3.3.1.1. Сессионные куки: Эти куки сохраняются только на время сеанса браузера. Они удаляются, как только пользователь закрывает браузер. Используются для временного хранения информации, такой как данные аутентификации или корзина покупок.

3.3.1.2. Постоянные куки: Эти куки сохраняются на устройстве пользователя в течение определенного времени, указанного в куке. Используются для сохранения предпочтений пользователя, таких как язык интерфейса или настройки темы.

3.3.1.3. Что можно сохранять в куки? Идентификаторы сеансов Настройки пользователя Историю посещений Данные корзины покупок

3.3.2. Кэш — это временное хранение данных для быстрого доступа в будущем. Кэширование используется для ускорения загрузки веб-страниц за счет сохранения ранее загруженного контента.

3.3.2.1. Кэш на клиенте: Это данные, которые клиент (например, браузер) сохраняет локально, чтобы ускорить доступ к ним при повторных запросах. Это может включать статические ресурсы, такие как изображения, стили CSS и скрипты.

3.3.2.2. Кэш на сервере: Это данные, которые сохраняются на сервере, чтобы уменьшить нагрузку на источники данных (например, базы данных) и ускорить обработку запросов. Кэш может быть реализован на уровне веб-сервера (например, Apache, Nginx) или на уровне приложений.

3.3.2.3. Что можно кэшировать? Полные страницы Фрагменты страниц Результаты запросов в базе данных Данные из внешних источников

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

3.3.3.1. JWT (JSON Web Token): Это cтандартный формат токенов, используемый для передачи информации между сторонами безопасным способом. Содержит полезную нагрузку, которую можно проверить и доверять.

3.3.3.2. OAuth токены: Используются для авторизации доступа к ресурсам. Обычно применяются в системах с внешними сервисами, такими как социальные сети или API.

3.3.3.3. Что можно делать с помощью токенов? Проверка личности пользователя Управление правами доступа Обеспечение безопасности взаимодействия с API

3.4. Сетевые концепции

3.4.1. IP (Internet Protocol) — это протокол, который используется для передачи данных по сети. Он отвечает за адресацию и маршрутизацию пакетов данных, чтобы они могли достичь правильного места назначения.

3.4.1.1. IPv4 — это наиболее распространенная версия IP, использующая 32-битные адреса, что позволяет создать около 4,3 миллиарда уникальных адресов.

3.4.1.2. IPv6 — это новая версия IP, которая использует 128-битные адреса, предоставляя значительно большее количество уникальных адресов (примерно 3,4×10^38 адресов).

3.4.2. DNS (Domain Name System) — это система, которая переводит доменные имена (например, www.example.com) в IP-адреса (например, 192.0.2.1), которые используются для маршрутизации запросов в интернете.

3.4.2.1. DNS-запрос — это процесс, при котором клиент (обычно веб-браузер) отправляет запрос к DNS-серверу, чтобы получить IP-адрес, соответствующий доменному имени.

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

3.4.3. HTTP (HyperText Transfer Protocol) — это протокол для передачи данных в интернете. Он используется для передачи веб-страниц от серверов к клиентам (веб-браузерам).

3.4.3.1. HTTP/1.1 — это версия протокола, которая позволяет поддерживать одно постоянное соединение для передачи нескольких ресурсов, что снижает задержки по сравнению с предыдущими версиями.

3.4.3.2. HTTP/2 — это улучшенная версия HTTP, которая включает мультиплексирование (позволяет отправлять несколько запросов через одно соединение одновременно) и сжатие заголовков, что улучшает производительность и скорость загрузки страниц.

3.4.4. HTTPS (HyperText Transfer Protocol Secure) — это расширение HTTP, которое использует шифрование для обеспечения безопасности передачи данных в интернете. Оно использует SSL/TLS для шифрования данных между сервером и клиентом, чтобы защитить их от перехвата и несанкционированного доступа.

3.4.4.1. Отличия от HTTP: Шифрование: HTTPS использует SSL/TLS для шифрования данных, что делает их недоступными для злоумышленников. HTTP передает данные в открытом виде, что делает их уязвимыми для перехвата. Аутентификация: HTTPS использует цифровые сертификаты для подтверждения подлинности веб-сайта, что помогает предотвратить атаки типа "человек посередине" (MITM). HTTP не предоставляет такого уровня аутентификации. Защита целостности данных: HTTPS обеспечивает целостность данных, предотвращая их изменение во время передачи. HTTP не защищает данные от изменений.

3.4.5. TCP (Transmission Control Protocol) — это протокол транспортного уровня, который обеспечивает надежную, ориентированную на соединение передачу данных. Он гарантирует доставку данных в правильном порядке и без потерь.

3.4.6. UDP (User Datagram Protocol) — это протокол транспортного уровня, который обеспечивает ненадежную, неориентированную на соединение передачу данных. Он не гарантирует доставку данных и порядок их получения.

3.5. Ключевые концепции сетевой безопасности и взаимодействия

3.5.1. Аутентификация — это процесс проверки подлинности пользователя (например, через логин и пароль).

3.5.2. Авторизация — это процесс определения прав доступа пользователя к ресурсам после аутентификации.

3.5.3. WebSocket — это протокол для установления двустороннего взаимодействия между клиентом и сервером. Он позволяет отправлять и получать данные в реальном времени, что полезно для чат-приложений, игр и других интерактивных сервисов.

3.5.4. Браузер — это программа, которая запрашивает, получает и отображает веб-страницы. Браузеры используют HTML, CSS и JavaScript для рендеринга контента, а также управляют сессиями, куки и кэшем для улучшения пользовательского опыта.

4. Фронтенд и бэкенд вместе образуют полноценное приложение. Они взаимодействуют друг с другом, чтобы обеспечить пользователю полноценный опыт использования.

4.1. Фронтенд и бэкенд связаны через сетевое взаимодействие посредством API (интерфейса прикладного программирования). Фронтенд отправляет запросы на бэкенд, запрашивая данные или запуская определенные операции. Бэкенд, в свою очередь, обрабатывает эти запросы, выполняет необходимые действия (например, извлечение данных из базы данных, обработка информации) и отправляет обратно результаты на фронтенд для отображения пользователю.

5. Теория тестирования

5.1. Виды тестирования

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

5.1.1.1. Методология функционального тестирования предполагает рассмотрение различных сценариев использования системы. Среди них особое внимание уделяется проверке стандартных путей работы системы (так называемых хеппи пасов) и тестированию в нестандартных, граничных ситуациях, которые могут выявить потенциальные проблемы (это и есть корнер кейсы).

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

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

5.1.2. Нефункциональное тестирование проверяет, как система работает, а не то, что она делает. Оно фокусируется на аспектах, таких как производительность, безопасность и удобство использования. В нефункциональном проверяем как ПО справляется с поставленной задачей, используя разные техники и кейсы

5.1.2.1. Нагрузочное тестирование (Тестирование производительности)

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

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

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

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

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

5.1.2.1.6. Пиковое тестирование проверяет, как система справляется с резкими увеличениями нагрузки в короткие периоды времени. Метафора: Пиковое тестирование — это как проверка, как водопроводная система справляется с неожиданным резким увеличением потребления воды, чтобы убедиться, что она не протечёт и не сломается.

5.1.2.2. Тестирование безопасности Описание: Проверка системы на наличие уязвимостей и обеспечения защиты данных от несанкционированного доступа. Это включает в себя тестирование на предмет защиты от атак и соблюдения стандартов безопасности. Пример: Проверка на наличие уязвимостей, таких как SQL-инъекции или XSS, а также тестирование шифрования данных и механизмов аутентификации.

5.1.2.3. Тестирование удобства пользования (Юзабилити) Описание: Оценка удобства использования системы для конечных пользователей. Проверяется, насколько легко и интуитивно пользователи могут выполнять задачи и достигать своих целей. Пример: Оценка интерфейса и навигации на предмет простоты использования и понятности для пользователей с разным уровнем подготовки.

5.1.2.4. Тестирование на отказ и восстановление Описание: Проверка системы на способность корректно реагировать на сбои и восстанавливаться после них. Это включает в себя проверку резервного копирования и восстановления данных. Пример: Симуляция сбоя сервера для проверки, как система восстанавливается после перезапуска и восстановления данных.

5.1.2.5. Тестирование локализации Описание: Проверка системы на соответствие языковым, валютным, временным и правовым требованиям для разных регионов. Это включает в себя корректное отображение текста и форматирование данных в соответствии с локальными стандартами. Пример: Проверка отображения дат, валют и текстов на разных языках в интерфейсе приложения.

5.1.2.6. Тестирование на совместимость - Кроссбраузерность/Кроссплатформенность Описание: Проверка работы системы на различных платформах и браузерах, чтобы обеспечить её корректное функционирование в разных средах. Пример: Тестирование веб-приложения на разных браузерах (Chrome, Firefox, Safari) и операционных системах (Windows, macOS, Linux).

5.1.2.7. Тестирование установки (Installation testing) – проверка успешности установки приложения, его настройки и удаления. Описание: Проверка процесса установки, настройки и удаления приложения. Это включает в себя тестирование установщика и проверку успешности всех этапов установки и удаления. Пример: Проверка установки приложения на различных операционных системах и проверка корректности удаления приложения, включая очистку всех связанных файлов и настроек.

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

5.1.3.1. Ретестирование (Retesting) Ретестирование - это когда мы однажды завели баг, и разработчик сказал, что пофиксил его “QA, сделай ретест бага плз, я вроде все исправил” и мы начинаем перепроверять наши же замечания или замечания других тестеров

5.1.3.2. Регрессионное тестирование (Regression Testing) Регресс- это когда добавили новый функционал, и мы, исходя из опыта, решаем перепроверить старый функционал тоже, т.к есть подозрение, что старый функционал может сломаться.

5.1.3.3. Смоук-тестирование (Smoke Testing) Описание: Базовое тестирование после внесения изменений, чтобы убедиться, что основная функциональность приложения работает без критических проблем. Это тестирование служит для быстрого выявления серьезных проблем перед проведением более глубоких тестов. Пример: После развертывания новой версии приложения, проверка, что основные функции, такие как логин и загрузка главной страницы, работают корректно. СМОУК мы используем почти всегда, чтобы мы не начинали. Нам нужно проверять, что фича хотя-бы запускается.

5.1.3.4. Тестирование нового функционала (New feature testing) Нью фича тестинг - это когда добавляют что-то новое в наше приложение, например возможность оплатить банковской картой “мир”, и мы проверяем работает ли данная функциональность.

5.1.3.5. Sanity (Санитарное) тестирование Описание: Глубокая проверка определенного модуля, чтобы убедиться, что исправления или новые функции не нарушили основные функции приложения. Это тестирование, которое выполняется после внесения изменений. Пример: После исправления критической ошибки в приложении необходимо проверить основные функции, такие как логин и создание нового пользователя, чтобы убедиться, что исправление не вызвало новых проблем. Санити используем, если нас не поджимают сроки или фича очень серьезна для бизнеса.

5.2. Классификация тестирования

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

5.2.1.1. Модульное тестирование Описание: Проверка отдельных компонентов или функций программы на правильность работы. Обычно выполняется разработчиками. Пример: Тестирование функции, которая вычисляет сумму двух чисел, чтобы убедиться, что она возвращает правильный результат.

5.2.1.2. Интеграционное тестирование (Integration Testing) Описание: Тестирование взаимодействия между различными компонентами системы. Цель — проверить, что модули работают вместе корректно после их объединения. Пример: Проверка, что функция расчета суммы корректно передает данные в систему отчетности.

5.2.1.2.1. Тестирование внутренней интеграции (модулей/компонентов) Описание: Это проверка взаимодействия между различными модулями или компонентами внутри одного приложения. Цель — убедиться, что компоненты корректно обмениваются данными и выполняют свои функции вместе как единое целое. Пример: Представьте, что у вас есть модуль авторизации и модуль личного кабинета. Тестирование внутренней интеграции включает проверку того, как модуль авторизации передает данные о пользователе в модуль личного кабинета, чтобы гарантировать, что информация правильно отображается и доступ к личному кабинету предоставляется без ошибок. Метафора: Это как проверка, что различные отделы в одном офисе (например, отдел продаж и бухгалтерия) правильно обмениваются информацией и работают вместе, чтобы обеспечить успешное выполнение задач.

5.2.1.2.2. Тестирование внешней интеграции (системное) Описание: Это проверка взаимодействия между различными системами или приложениями, которые могут быть независимыми друг от друга. Цель — убедиться, что системы корректно обмениваются данными и взаимодействуют через внешние интерфейсы или API. Пример: Представьте, что на вашей форме авторизации есть кнопка "Войти через Госуслуги". При нажатии на эту кнопку происходит перенаправление на внешний сервис Госуслуг для аутентификации. Тестирование внешней интеграции проверяет, что процесс перенаправления и обмен данными между вашим сайтом и Госуслугами проходит без проблем, и вы успешно возвращаетесь на сайт после аутентификации. Метафора: Это как проверка, что ваш офис правильно взаимодействует с внешними поставщиками и партнерами, чтобы обеспечить бесперебойное выполнение бизнес-процессов, таких как получение материалов или услуг.

5.2.1.2.3. Техники интеграционного тестирования

5.2.1.3. Системное тестирование (System Testing) Описание: Полное тестирование всей системы в целом, чтобы убедиться, что все компоненты работают вместе как ожидается и соответствуют требованиям. Пример: Проверка веб-приложения, чтобы убедиться, что оно функционирует правильно при различных сценариях использования, включая вход в систему и выполнение транзакций.

5.2.1.4. Приемочное тестирование (Acceptance Testing) Описание: Тестирование, проведенное для проверки, соответствует ли система требованиям и ожиданиям заказчика. Часто выполняется пользователями или тестировщиками по заказу. Пример: Тестирование функциональности нового модуля пользователем, чтобы убедиться, что он удовлетворяет его потребности и работает в реальных условиях.

5.2.1.5. Компонентное тестирование Описание: Компонентное тестирование проверяет более крупные части программного обеспечения, гарантируя их правильное функционирование при совместной интеграции. Оно выполняется тестировщиками и проверяет общее поведение и удобство использования программных компонентов в реальных сценариях.

5.2.2. Методы тестирования (По знанию кода)

5.2.2.1. Тестирование методом черного ящика (black box testing): Тестирование, функциональное или нефункциональное, без знания внутренней структуры или кода. Тестировщик проверяет входные данные и ожидает правильные выходные данные, не беспокоясь о внутреннем устройстве системы.

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

5.2.2.3. Тестирование методом белого ящика (white-box testing): Метод тестирования, при котором тестировщик имеет доступ к внутреннему коду и структуре программы. Цель — проверка логики работы программы, её функций и структур. Пример: Проверка алгоритма сортировки в коде, тестирование его на различных наборах данных, чтобы убедиться, что он правильно сортирует элементы. У нас есть прямой доступ к коду, и мы можем прямо как разработчик дописать новые функции или поправить старые методы.

5.2.3. В зависимости от исполнителя

5.2.3.1. Альфа тестирование — это ранний этап тестирования программного обеспечения, проводимый внутри компании-разработчика. Цель этого тестирования — обнаружить дефекты, которые могли быть упущены во время разработки и предварительного тестирования. Оно проводится до выпуска программного обеспечения на рынок.

5.2.3.2. Бета тестирование — это этап тестирования, проводимый после альфа тестирования, когда программное обеспечение выпускается для использования ограниченной группой внешних пользователей. Цель — получить отзывы от реальных пользователей и выявить ошибки, которые не были обнаружены на предыдущих этапах. Бета тестирование могут проводить как в закрытой форме, так и в открытой. Закрытый бета тест подразумевает под собой, что доступ к программе выдается определенному количеству пользователей и они используют его в привычной форме. Открытый бета тест проводится в доступной форме, чтоб большее количество пользователей могло протестировать продукт.

5.2.4. По степени позитивности

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

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

5.2.5. Типы тестирования (По запуску кода)

5.2.5.1. Статическое тестирование Этот вид тестирования проводится без выполнения кода программы. Оно включает в себя анализ исходного кода, проектной документации и других артефактов. Цель — найти ошибки и уязвимости до того, как программа будет запущена. Методы: Анализ кода: Использование инструментов статического анализа для проверки кода на ошибки, уязвимости, нарушения стиля кодирования и потенциальные проблемы. Примеры инструментов: SonarQube, Checkmarx. Пример: Инструмент может обнаружить непроверенные исключения или потенциальные утечки памяти в коде. Анализ требований: Оценка документации и спецификаций на соответствие требованиям, проверка полноты и ясности требований. Пример: Проверка документации на наличие ошибок и несоответствий, таких как отсутствие важной функциональности. Ревью: Процесс, в котором разработчики и тестировщики просматривают код или документацию, чтобы найти ошибки и предложить улучшения. Не может выявить ошибки, которые зависят от выполнения кода. Пример: Код-ревью может выявить логические ошибки или улучшения, которые улучшат читаемость и поддержку кода. Преимущества: Выявление ошибок на ранних этапах разработки. Улучшение качества кода и документации. Снижение количества дефектов, которые могут быть обнаружены на более поздних этапах. Ограничения: Не может выявить ошибки, которые зависят от выполнения кода. Может пропустить проблемы, которые проявляются только при реальном использовании программы.

5.2.5.2. Динамическое тестирование Этот вид тестирования проводится с выполнением кода программы. Оно фокусируется на проверке функциональности программы в реальных условиях, чтобы убедиться, что она работает правильно и эффективно. Методы: Функциональное и нефункциональное тестирование. Тестирование по уровню детализации приложения. Преимущества: Выявление ошибок и дефектов, которые проявляются только при фактическом выполнении программы. Позволяет проверить реальные условия эксплуатации и производительность. Ограничения: Может выявить ошибки слишком поздно в процессе разработки, когда исправление может быть сложным и затратным. Не всегда охватывает все возможные сценарии использования, особенно если тестовые случаи не полностью отражают реальные условия.

5.2.6. По степени автоматизации

5.2.6.1. Ручное тестирование В ручном тестировании все проверки и тестовые сценарии выполняются вручную. Тестировщик сам вводит данные, проверяет результаты и фиксирует баги, если они есть. Применяется для уникальных тестов, требующих визуальной оценки, проверки интерфейса или анализа пользовательского опыта (UX). Плюсы: Простота выполнения. Возможность адаптироваться к изменениям в процессе тестирования. Подходит для небольших проектов и тестирования специфичных кейсов. Минусы: Высокая вероятность ошибок из-за человеческого фактора. Большие временные затраты на выполнение тестов. Трудность в повторном выполнении тестов, особенно на больших объемах данных.

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

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

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

5.3.1.1. Scrum Scrum — это набор правил, благодаря которым команда налаживает гибкий рабочий процесс, разработка ведется итерациями, четко обозначаются цели каждой итерации и задачи каждого члена команды. Благодаря фреймворку компании могут применять принципы и ценности методологии управления проектами по Agile.

5.3.1.2. Kanban Канбан ― это система постановки задач и организации рабочих процессов для эффективного достижения поставленных целей. Данная методология предполагает прозрачность продвижения работы и является одним из подходов Agile. Киллер фича это визуализация работы при помощи канбан доски.

5.3.1.3. Принципы Agile: Гибкость: Способность команды адаптироваться к изменениям, даже если они происходят на поздних стадиях разработки. Непрерывная доставка: Постоянная поставка работающего программного обеспечения с короткими циклами (итерациями), обычно от нескольких недель до месяца. Сотрудничество: Тесное взаимодействие между разработчиками и заказчиками на протяжении всего проекта. Уделение внимания качеству: Постоянное улучшение и рефакторинг кода для поддержания высокого качества продукта. Методологии Agile: Agile — это не конкретная методология, а подход, включающий несколько методологий, таких как Scrum, Kanban, XP (Extreme Programming) и другие. Итеративный процесс: Проекты в Agile развиваются через итерации, каждая из которых включает планирование, разработку, тестирование и оценку. Итерации короткие, что позволяет быстро адаптироваться к изменениям и поставлять частично готовый продукт.

5.3.1.4. Преимущества Agile: Быстрая реакция на изменения: Команды могут легко адаптироваться к изменениям требований или приоритетов. Удовлетворенность заказчика: Регулярные поставки работающего программного обеспечения и тесное сотрудничество с клиентом помогают удовлетворять его ожидания. Повышение мотивации команды: Постоянные улучшения и участие команды в принятии решений способствуют более высокому уровню вовлеченности. Недостатки Agile: Трудности с масштабированием: Agile может быть сложным для внедрения в крупных организациях или на масштабных проектах, требующих координации множества команд. Требования к вовлеченности: Agile требует высокого уровня вовлеченности от заказчика и команды на протяжении всего проекта, что может быть сложно обеспечить. Недостаток документации: В Agile основной упор делается на работающий продукт, а не на документацию, что может создать проблемы при передаче проекта другой команде или при поддержке.

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

5.3.2.1. Этапы Waterfall: Сбор требований (Requirements): На этом этапе собираются все требования к системе. Эти требования фиксируются в документации, и любые изменения после этого этапа усложняются. Проектирование (Design): На основе собранных требований разрабатывается архитектура системы, определяются технологии, базы данных и интерфейсы. Реализация (Implementation): На этом этапе осуществляется разработка программного кода на основе проектной документации. Разработчики пишут код в соответствии с проектными спецификациями. Тестирование (Testing): После завершения кода начинается этап тестирования, чтобы убедиться, что все функции работают корректно и нет критических ошибок. Внедрение (Deployment): На этом этапе готовое программное обеспечение разворачивается в рабочую среду и передается пользователям. Поддержка (Maintenance): После внедрения начинается этап сопровождения, включающий исправление ошибок, обновление и доработку системы.

5.3.2.2. Особенности: Линейный процесс: Каждая фаза проекта строго следует за предыдущей и возврат на предыдущие этапы затруднен. Жесткая структура: Waterfall предполагает четкую последовательность шагов, что требует тщательного планирования и строгого следования процессу. Документированность: На каждом этапе создается подробная документация, которая фиксирует все требования, дизайн и процессы, что облегчает контроль и понимание процесса разработки.

5.3.2.3. Преимущества Waterfall: Четкая структура и контроль: Благодаря четкой последовательности этапов, легко контролировать процесс и управлять проектом. Документированность: Подробная документация на каждом этапе облегчает переход проекта между командами или передачу знаний. Подходит для проектов с четкими требованиями: Если требования проекта заранее известны и не предполагают значительных изменений, Waterfall может быть эффективным подходом. Недостатки Waterfall: Жесткость: Из-за линейной природы модели, внесение изменений на поздних этапах разработки сложно и дорого. Длительные циклы разработки: Весь продукт разрабатывается как единое целое, что может привести к тому, что пользователи увидят готовую систему только на финальном этапе. Риск потери актуальности: В случае долгих проектов требования могут измениться до момента завершения, что приведет к устареванию системы еще до её завершения.

5.4. Пирамида тестирования

5.4.1. Пирамида тестирования — это концепция, которая визуально показывает оптимальное распределение автоматизированных (ручных тоже) тестов на различных уровнях программного обеспечения. Она подчеркивает важность использования большего количества простых и быстрых тестов (например, модульных) и меньшего количества сложных и медленных (например, интеграционных или пользовательских).

5.4.1.1. Пирамида тестирования: Нижний уровень - юнит тесты Апи тесты в середине Ui test/e2e наверху Чем выше находимся в пирамиде, тем выше затраты времени (а время это деньги) на поддержку, на разработку, медленно прогоняются, менее стабильные. Чем ниже - меньше затрат на поддержку и разработку, быстрее прогоняются и более стабильные.

5.4.1.1.1. Уровни пирамиды: Нижний уровень: Юнит-тесты (Unit Tests): Юнит-тесты составляют основу пирамиды и являются наиболее многочисленными. Они проверяют работу отдельных компонентов или функций приложения в изоляции. Юнит-тесты быстры, дешевы в разработке и легки в поддержке. Они также стабильны и позволяют быстро находить ошибки на ранних этапах разработки. Затраты: Низкие на разработку и поддержку, быстрые в выполнении. Средний уровень: API-тесты (Integration/API Tests): API-тесты проверяют взаимодействие между различными модулями или сервисами приложения. Они помогают убедиться, что компоненты правильно работают вместе. Эти тесты занимают среднее место в пирамиде, так как их сложнее поддерживать, чем юнит-тесты, и они выполняются дольше. Затраты: Средние на разработку и поддержку, умеренные по времени выполнения. Верхний уровень: UI-тесты/End-to-End тесты (UI Tests/E2E Tests): Вершину пирамиды занимают тесты пользовательского интерфейса (UI-тесты) и End-to-End тесты. Они проверяют работу приложения в целом, включая взаимодействие с интерфейсом и работу всех компонентов вместе. Эти тесты наиболее сложные, дорогие в разработке и поддержке, а также выполняются дольше и менее стабильны по сравнению с другими типами тестов. Затраты: Высокие на разработку и поддержку, медленные по времени выполнения.

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

7. Тестовая документация и Техники тест дизайна

7.1. Теория “Тестовая документация”

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

7.1.1.1. Написание тестовой документации на проекте

7.1.1.1.1. 1 этап. Уточнение требований.

7.1.1.1.2. 2 этап. Дизайн тестов

7.1.1.1.3. 3 этап. Написание тест-кейсов

7.1.1.1.4. 4 этап. Ревью кейсов

7.1.2. Тестовые Артефакты

7.1.2.1. **Чек-листы** — это упорядоченный список элементов или задач, которые необходимо проверить или выполнить в ходе тестирования.

7.1.2.2. **Тест-кейс** — алгоритм действий для проверки написанной программы. Он подробно описывает короткую последовательность действий, например успешную авторизацию пользователя. В тест-кейсе фиксируют подготовку к проверке, саму диагностику и ожидаемый результат, включая информацию о количестве проверок и нюансах.

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

7.1.2.3. **Тест-план** — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

7.1.2.3.1. **Детали:** Тестплан определяет, какие области системы будут тестироваться, какие методы тестирования будут использоваться, кто будет выполнять тестирование, и когда оно будет происходить. Также тестплан включает информацию о рисках, допущениях, критериях начала и окончания тестирования, а также требования к оборудованию и инструментам. Тестплан служит ориентиром для всех участников процесса тестирования и помогает координировать работу команды.

7.1.2.4. **Баг репорт** — это документ, который описывает найденную проблему или дефект в программном обеспечении, требующий исправления.

7.1.2.4.1. **Детали:** Баг репорт включает в себя описание ошибки, шаги для ее воспроизведения, ожидаемый результат, фактический результат, а также прилагает необходимые скриншоты или логи. Цель баг репорта — предоставить разработчикам полную информацию о дефекте, чтобы они могли его исправить. Важными элементами баг репорта являются: уникальный идентификатор, приоритет, статус, версия ПО, описание проблемы, среда тестирования, и шаги для воспроизведения. **Пример:** Баг репорт может описывать проблему с кнопкой "Отправить", которая не работает при определенных условиях, включая шаги по воспроизведению проблемы, и прилагаемые скриншоты.

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

7.1.3. Ревью тест-кейсов

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

7.1.3.1.1. **Детали:** Ревью тесткейсов играет важную роль в обеспечении качества процесса тестирования. В этом процессе: **Проверка логики и корректности:** Проверяются сами тестовые сценарии на наличие ошибок, логических несоответствий и правильность последовательности шагов. **Оценка полноты тестирования:** Проверяется, охватывают ли тесты все возможные случаи, включая позитивные и негативные сценарии, граничные значения и случаи на основе классов эквивалентности. **Анализ на дублирование:** Выявляются повторяющиеся тесты, чтобы избежать избыточности и сосредоточить внимание на уникальных аспектах приложения. **Проверка соответствия требованиям:** Оценивается, соответствуют ли тесты исходным требованиям и спецификациям, если таковые имеются. **Обратная связь и предложения:** В процессе ревью участники могут предлагать улучшения, альтернативные подходы или добавлять новые тестовые случаи для улучшения покрытия.

7.1.4. TMS (Test Management System)

7.1.4.1. TMS (Test Management System) — это система управления тестированием, которая помогает организовать и управлять процессом тестирования программного обеспечения. TMS используется для планирования тестирования, создания и хранения тестовых случаев, отслеживания их выполнения и результатов, а также для управления багами и отчетами о тестировании. Эти системы помогают тестировщикам и разработчикам работать более эффективно и упорядоченно.

7.1.4.1.1. TMS - Это “домик” для хранения тест-кейсов Иначе обычно это сайты (веб-приложения), такие, как TestIT или Allur TestOps где мы храним ручные тест-кейсы, автоматические или чек-листы. Так же они могут быть в виде программы desktop.

7.1.5. JIRA

7.1.5.1. Тасктрекеры - Это “домик” для хранения задач и баг репортов. Иначе обычно это сайты (веб-приложения), такие как JIRA или Yandex Tracker, где у нас есть канбан доска и на ней мы планируем свой день, грубо говоря, трекаем таски. Так же мы имеем возможность создавать баг репорты на эту доску и линковать их с задачами для отслеживания связей.

7.1.5.2. Это инструмент для управления проектами и отслеживания задач, разработанный компанией Atlassian. Он широко используется в IT-индустрии для планирования, отслеживания и управления программными проектами. Jira особенно популярна среди команд, использующих методологии Agile, такие как Scrum и Kanban.

7.1.6. Confluence

7.1.6.1. Confluence — это онлайн-пространство, где команды могут создавать и хранить документы, делиться информацией и работать вместе над проектами. Это как общий блокнот для всей компании, где все могут оставлять заметки, редактировать их и легко находить нужные данные. Confluence — это “домик” для хранения инструкций и документации.(как Wiki)

7.1.7. Прогон

7.1.7.1. **Тестовый прогон, или тест-ран (test run)** - это процесс выполнения одного или нескольких тест-кейсов для проверки части или всего программного продукта на наличие ошибок и проверку соответствия его требованиям и спецификациям. В процессе тестового прогона могут быть задействованы как ручные, так и автоматизированные тесты.

7.1.7.2. **Детали:** **Подготовка:** 1) Определение набора тестов для выполнения. 2) Подготовка тестового окружения. **Запуск тестов:** 1) Выполнение тестов согласно плану. 2) Фиксация результатов тестов. **Анализ результатов:** 1) Анализируется статистика выполнения тестов, включая количество пройденных, не пройденных тестов, и выявленные дефекты. 2) Оценивается, насколько система соответствует установленным критериям качества. **Документация:** 1) Результаты тестового прогона документируются в виде отчета, который может включать список пройденных тестов, выявленные дефекты и рекомендации по их устранению. 2) Отчет о тестовом прогоне обычно передается заинтересованным сторонам (например, команде разработчиков, менеджерам проекта) для принятия решений о дальнейших действиях.

7.1.7.3. **Виды тестовых прогонов:** 1) Полный тестовый прогон 2) Частичный тестовый прогон 3) Регрессионный тестовый прогон 4) Sanity тестовый прогон

7.2. Техники тест дизайна

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

7.2.1.1. Основные техники тест-дизайна

7.2.1.1.1. **Классы эквивалентности (Equivalence Partitioning)** Классы эквивалентности — это техника, при которой входные данные разбиваются на группы, где данные в каждой группе обрабатываются одинаково. **Пример:** Если функция проверяет только положительные целые числа, классы эквивалентности могут быть: положительные числа, отрицательные числа, ноль, и нецелые числа.

7.2.1.1.2. **Граничные значения (Boundary Value Analysis)** Граничные значения — это техника, при которой тестируются пограничные значения диапазонов входных данных. **Пример:** Для поля ввода числа от 1 до 100 тестирование будет включать значения 0, 1, 100 и 101.

7.2.1.1.3. **Ошибка и предположение (Error Guessing)** Ошибка и предположение — это техника, основанная на интуиции и опыте тестировщика для предсказания потенциальных ошибок. **Пример:** Обычно тестировщики начинают с проверки следующих распространенных ошибок: 1) Ввод пробелов в текстовые поля. 2) Нажатие кнопки "Submit" без ввода данных. 3) Ввод некорректных параметров (например, адрес электронной почты вместо номера телефона). 4) Загрузка файлов, превышающих максимально допустимый размер, и другие подобные действия.

7.2.1.1.4. **Тестирование на основе чек-листов (Checklist-based Testing)** Тестирование на основе чек-листов включает использование списков проверок для обеспечения выполнения всех необходимых тестов. **Пример:** При тестировании нового веб-приложения чек-лист может включать проверки для каждой страницы, всех функций и всех возможных пользовательских сценариев, таких как регистрация, вход, редактирование профиля и т.д.

7.2.1.1.5. **Диаграмма переходов и состояний (State Transition Testing)** Таблица переходов и состояний используется для проверки системы, когда она переходит из одного состояния в другое в зависимости от входных данных. **Пример:** В системе авторизации состояние "Гость" может перейти в состояние "Зарегистрированный пользователь" после успешной регистрации, и состояние "Зарегистрированный пользователь" может перейти в "Администратор" после получения соответствующих прав.

7.2.1.1.6. **Таблица принятия решений (Decision Table Testing)** Таблица принятия решений помогает тестировать различные комбинации входных данных и условий для проверки их влияния на результат. **Пример:** Таблица может включать различные условия, такие как "проверка возраста пользователя" и "наличие подписки", и определять, что должно произойти в зависимости от этих условий, например, предоставление доступа или отказ в доступе.

7.2.1.1.7. **Попарное тестирование (Pairwise testing)** Попарное тестирование — это метод, при котором тестируются все возможные пары значений входных данных для выявления дефектов, которые могут возникнуть из-за взаимодействия этих пар. **Пример:** Предположим, у нас есть веб-приложение для заказа пиццы. У этого приложения есть следующие параметры: 1) Размер пиццы: Маленькая, Средняя, Большая 2) Тип корки: Тонкая, Пышная 3) Соус: Томатный, Сливочный 4) Дополнительные ингредиенты: Пепперони, Грибы, Оливки, Ветчина Без применения парного тестирования нам нужно было бы создать 3 * 2 * 2 * 4 = 48 тестовых случаев, чтобы протестировать все возможные комбинации параметров. Однако с использованием парного тестирования мы можем сократить это количество до значительно более управляемого уровня, например, 6 или 7 тестов, покрывающих все основные комбинации параметров. Пример комбинаций (применение парного тестирования): 1) Маленькая, Тонкая, Томатный, Пепперони 2) Средняя, Тонкая, Сливочный, Грибы 3) Большая, Тонкая, Томатный, Оливки 4) Маленькая, Пышная, Сливочный, Ветчина 5) Средняя, Пышная, Томатный, Грибы 6) Большая, Пышная, Сливочный, Пепперони

7.2.1.1.8. **Классы эквивалентности + Граничные значения (Equivalence Partitioning and Boundary Value Analysis)** Комбинация двух техник, где сначала разделяются входные данные на эквивалентные классы, а затем проверяются граничные значения в этих классах. **Пример:** Для поля ввода числа от 1 до 100, классы эквивалентности могут быть: положительные числа, отрицательные числа, ноль и нецелые числа. Граничные значения будут 0, 1, 100 и 101.

7.3. Тестирование без документации

7.3.1. Тестирование без документации требует использования исследовательского подхода, глубокого анализа приложения и взаимодействия с разработчиками или пользователями. Это помогает понять функциональность продукта и выявить возможные дефекты, несмотря на отсутствие формальной спецификации.

7.3.2. **Детали:** Когда тестировщику приходится работать без документации, он сталкивается с рядом вызовов. В таких ситуациях важно: **Исследовательское тестирование:** Исследовательское тестирование — это подход к тестированию программного обеспечения, при котором тестировщик активно изучает приложение без заранее подготовленных тест-кейсов, исследует его, пытается предсказать поведение системы и выявляет баги на основе своего опыта и интуиции. **Обратная связь с разработчиками:** В отсутствие документации, тестировщики могут обращаться к разработчикам за разъяснениями. Разработчики могут дать представление о том, как должно работать приложение, и что именно нужно тестировать. **Анализ существующего кода:** Если доступны исходные коды, тестировщики могут просматривать их, чтобы понять, как должна работать система. **Пользовательские сценарии:** Если доступны конечные пользователи или бизнес-аналитики, можно провести сессии для понимания того, как они используют приложение в реальных условиях. Это помогает создать тестовые сценарии, которые приближены к реальным условиям эксплуатации. **Исторические данные и баг-репорты:** Анализ предыдущих багов и работа над исправлениями может дать полезную информацию о проблемных местах приложения. **Ad-hoc тестирование:** Это неформальный метод тестирования, при котором тестировщик проверяет систему без заранее подготовленных тест-кейсов или плана. Основная цель этого вида тестирования — выявить дефекты случайным образом, полагаясь на опыт, интуицию и понимание приложения. Оно часто используется в тех случаях, когда времени на подготовку полноценного тестирования нет, или чтобы быстро проверить новый функционал. **Monkey Testing:** Это вид тестирования, при котором приложение тестируется путем случайных действий и ввода данных, как будто с ним взаимодействует "обезьяна" — то есть абсолютно непредсказуемо и хаотично. Цель такого тестирования — попытаться выявить неожиданные сбои или баги, которые могут возникнуть из-за некорректного ввода или необычного поведения пользователей.

7.4. Тестирование критических путей

7.4.1. **Тестирование критических путей (Critical Path Testing)** — это метод тестирования, который фокусируется на проверке наиболее важных и часто используемых функциональных сценариев в приложении. Эти сценарии представляют собой "критические пути" пользователя, то есть те, которые имеют наибольшее значение для функционирования системы и наиболее важны для конечных пользователей.

7.4.1.1. **Отличие от хэппи паса:** Хеппи пас проверяет основной успешный сценарий, при котором система работает без ошибок. Критикал пас фокусируется на ключевых функциях, которые могут быть более сложными и критичными для бизнеса, включая сценарии с ошибками, неправильными действиями пользователя и сбоями системы. Хеппи пас — это только положительный сценарий, а критикал пас может включать тестирование и других важных, не всегда "положительных" сценариев.

7.4.2. **Детали:** **Критические пути** — это ключевые сценарии использования системы, такие как регистрация пользователя, оформление заказа или процесс оплаты. Эти функции должны работать безотказно, поскольку сбой в их работе может сильно повлиять на пользовательский опыт и бизнес в целом. **Фокус на важности:** В процессе тестирования критических путей тестировщики выделяют те сценарии, которые имеют наибольшее значение для работы системы. Эти сценарии проходят приоритетное тестирование, чтобы гарантировать их стабильную и правильную работу. **Минимизация рисков:** Поскольку критические пути включают наиболее важные функции, их тестирование помогает минимизировать риски отказа системы и улучшить качество продукта.

8. **Клиент-серверная архитектура**

8.1. **Теория**

8.1.1. **Клиент-серверная архитектура** — это модель взаимодействия, где клиент (например, веб-браузер или мобильное приложение) отправляет запросы серверу (например, веб-серверу или базе данных) для получения или передачи данных. Сервер обрабатывает запросы, выполняет бизнес-логику, хранит информацию и возвращает результаты клиенту. Клиент занимается пользовательским интерфейсом и взаимодействием с пользователем, а сервер управляет данными и обеспечивает безопасность и стабильность системы. **Канал связи между клиентом и сервером это API.** Взаимодействие клиента и сервера основано на протоколах коммуникации, таких как HTTP, TCP/IP.

8.1.1.1. **API** - это сокращение от **Application Programming Interface** (интерфейс прикладного программирования). Это набор определенных правил, протоколов и инструментов, которые позволяют различным программным приложениям взаимодействовать между собой. API определяет способы, с помощью которых приложения могут отправлять запросы друг к другу для получения данных или выполнения определенных операций. Это позволяет разным системам обмениваться информацией и функциональностью без необходимости раскрытия своей внутренней реализации.

8.1.1.1.1. API определяет набор правил и инструкций, которые определяют способы взаимодействия между разными программами или компонентами программного обеспечения. **Рассмотрим некоторые из основных правил общения, которые могут быть частью API.**

8.1.1.2. **Уровни клиент-сервера**

8.1.1.2.1. **Двухуровневая архитектура (Client-Server):** *Пример: * - **1.** Веб-приложение, где клиент — это браузер, а сервер отвечает за обработку запросов и управление базой данных. - **2.** Клиент-серверные базы данных, такие как приложение на компьютере, которое напрямую подключается к серверу базы данных.

8.1.1.2.2. **Трехуровневая архитектура (Three-Tier Architecture):** *Пример: * Веб-приложение, где клиент (браузер) взаимодействует с сервером приложений (например, фреймворк на Python), который обрабатывает логику и обращается к базе данных для получения информации.

8.1.1.2.3. **Многоуровневая архитектура (N-Tier Architecture):** *Пример: * Комплексная система с фронтендом, сервером приложений, несколькими микросервисами, базой данных и системой управления очередями сообщений.

8.1.1.3. **Архитектура приложений**

8.1.1.3.1. **Монолитная архитектура** — это способ разработки, при котором все компоненты приложения собираются в единый проект и тесно связаны между собой. В такой архитектуре интерфейс, логика приложения, базы данных и т. д. собраны в одно целое. Система работает как единое целое в рамках одного процесса.

8.1.1.3.2. **Микросервисная архитектура** — это способ создания программных продуктов, при котором большая сложная система разбивается на много маленьких независимых блоков — микросервисов.

8.1.2. **Гайд по микросервисам**

8.1.2.1. 🖥️ **Клиент (Client)** *Программа: веб-браузер (гугл хром) * **Клиент** — это любое приложение или устройство, которое взаимодействует с сервером для получения или отправки данных. В контексте веб-приложений клиентом обычно является веб-браузер. **Существуют два вида клиентов.**

8.1.2.1.1. **Толстый клиент** — клиент, у которого основная логика и обработка данных выполняются на стороне клиента. Примером может служить компьютерная игра.

8.1.2.1.2. **Тонкий клиент** — клиент, где основная логика и обработка данных происходят на сервере, а клиентская часть (например, браузер) просто отображает информацию и отправляет запросы на сервер. Примером служит веб-браузер, который загружает страницы с сервера и отображает их пользователю, но вся основная логика обработки данных происходит на стороне сервера.

8.1.2.2. 💻 **Сервер (Бизнес логика) (Server - Business Logic)** *Программа: Python (с использованием фреймворков, таких как Django или Flask) * **Назначение:** Серверы, написанные на Python, обрабатывают бизнес-логику приложения. Это включает обработку запросов пользователей, взаимодействие с базой данных и другими компонентами системы.

8.1.2.3. ⚙️ **Балансировщик нагрузки** *Программа: Kubernetes * **Назначение:** Kubernetes управляет контейнерами и выполняет роль балансировщика нагрузки. Он распределяет входящие запросы между контейнерами с вашими приложениями (сервером бизнес-логики), обеспечивая масштабируемость и отказоустойчивость.

8.1.2.4. 🌐 **Веб-сервис** **Определение:** Веб-сервис — это специализированный тип API (Application Programming Interface), работающий через Интернет. Он позволяет программным приложениям взаимодействовать друг с другом с помощью веб-технологий, таких как HTTP, HTTPS, SOAP и REST. **Примеры:** - Веб-сервис погоды, предоставляющий информацию о текущей погоде и прогнозах. - Веб-сервис обмена валют, предоставляющий курсы валют в реальном времени.

8.1.2.5. 📦 **Брокер очередей (Message Broker)** *Программа: Apache Kafka * **Назначение:** Apache Kafka используется для асинхронного обмена сообщениями между различными компонентами системы. Сервер может отправлять сообщения в очереди Kafka, чтобы их позже обработали другие сервисы или воркеры.

8.1.2.6. 🗄️ **Сервер базы данных (Server - Database)** *Программа: Oracle Database * **Назначение:** Oracle Database хранит структурированные данные, необходимые для работы вашего приложения. Серверы бизнес-логики обращаются к этой базе данных для чтения и записи информации.

8.2. **Сетевые технологии, которые так же используются в современных архитектурах**

8.2.1. Сетевая модель TCP/IP состоит из четырех уровней: прикладного, транспортного, сетевого и канального. Каждый из этих уровней выполняет определённую функцию в передаче данных по сети.

8.2.1.1. 1. **Прикладной уровень (Application Layer):** - Это верхний уровень модели TCP/IP, который отвечает за взаимодействие с приложениями пользователя. Он обеспечивает интерфейс для взаимодействия приложений с сетью, используя протоколы, такие как HTTP, FTP, SMTP и DNS. - **Пример:** Когда вы открываете веб-страницу в браузере, прикладной уровень использует протокол HTTP для передачи данных.

8.2.1.2. 2. **Транспортный уровень (Transport Layer):** - Этот уровень отвечает за установление, поддержание и завершение соединений между устройствами, а также за надежную передачу данных. Основные протоколы этого уровня — TCP (обеспечивает надёжную доставку данных) и UDP (быстрая, но ненадёжная передача). - **Пример:** Когда вы отправляете файл через интернет, транспортный уровень гарантирует, что все части файла будут доставлены правильно и в нужном порядке (если используется TCP).

8.2.1.3. 3. **Сетевой уровень (Network Layer):** - Сетевой уровень отвечает за определение маршрута и передачу пакетов данных между устройствами в разных сетях. Основной протокол на этом уровне — IP (Internet Protocol), который использует IP-адреса для маршрутизации пакетов. - **Пример:** Когда вы отправляете электронное письмо, сетевой уровень определяет путь, по которому данные будут переданы от вашего устройства к получателю.

8.2.1.4. 4. **Канальный уровень (Link Layer)_физический уровень:** - Это самый нижний уровень модели TCP/IP, который управляет физической передачей данных между устройствами в одной сети (например, в локальной сети). Он обеспечивает правильную передачу битов по физическому каналу связи, управляет доступом к среде передачи и обработкой ошибок на уровне канала. - **Пример:** Когда ваше устройство подключается к Wi-Fi, канальный уровень управляет передачей данных между вашим устройством и маршрутизатором.