🕸 Kubernetes: Краткое описание и подборка материалов

Сначала рекомендуем изучить пост про Docker

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

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

Основные понятия

💩Узел (node) – физическая или виртуальная машина, на которой запускаются поды.
💩Под (pod) – группа контейнеров с общими разделами, запускаемых как единое целое. Минимальная единица развёртывания в Kubernetes.
💩Сервис (service) – абстракция, которая определяет политику доступа к подам. Сервис балансирует трафик между подами и предоставляет единую точку входа для клиентов.
💩Replication Controllers – контроллер, который гарантирует, что определенное количество реплик (копий) пода будут запущены в любой момент времени.
💩Раздел (Volume) – директория, которая доступна в контейнере.
💩Лейблы (Labels) – пары ключ-значение которые прикрепляются к объектам, например, к подам.

Главные функции K8s

1️⃣ Централизованное управление (оркестровка) контейнерами. Kubernetes автоматически управляет жизненным циклом контейнеров от развёртывания до откатов обновлений.

2️⃣ Распределение нагрузки и масштабирование кластера. Kubernetes распределяет контейнеры по узлам так, чтобы они не тратили лишние ресурсы. Если нагрузка на систему растёт, Kubernetes может автоматически добавлять контейнеры и узлы.

3️⃣ Управление конфигурациями. В Kubernetes есть средство для центрального управления конфигурациями — ConfigsMaps для настроек и Secrets для конфиденциальных данных. Если разместить в них свои настройки, то приложения смогут получить к ним доступ из любого узла.

Kubernetes 🆚 Docker

🔸 Docker — инструмент для создания и запуска контейнеров. Docker работает в рамках отдельных узлов. Если у вас несколько узлов, то на каждом из них запущен докер-демон, который ничего не знает о существовании других узлов. Каждый демон знает лишь о том, что происходит на его узле.

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

Ещё есть Docker Swarm — встроенный в докер инструмент оркестровки контейнеров. Его как как раз и можно полноценно сравнивать с Kubernetes.

✅ Преимущества Kubernetes

▫️Масштабируемость. Kubernetes позволяет горизонтально масштабировать приложения, добавляя или удаляя поды в зависимости от нагрузки. Kubernetes также поддерживает вертикальное масштабирование, изменяя выделенные ресурсы для подов.

▫️Надежность. Kubernetes обеспечивает высокую доступность приложений, перезапуская поды в случае сбоя. Kubernetes поддерживает стратегии бесперебойного обновления, которые позволяют внедрять новые версии приложений без простоя.

▫️Эффективность. Kubernetes позволяет оптимально распределять поды по доступным узлам. Kubernetes автоматически управляет ресурсами и позволяет задавать ограничения и приоритеты для подов.

⛔️ Недостатки Kubernetes

◾️Сложность. Kubernetes сложно изучать, настраивать и поддерживать, требуются дополнительные инструменты и процессы для работы приложений.

◾️Необходимость адаптации приложений. Kubernetes требует, чтобы приложения соответствовали определенным правилам и практикам. Это может потребовать изменения или создания приложений с нуля.

◾️Высокие требования к ресурсам. Kubernetes занимает много ресурсов. Это может снизить производительность или увеличить стоимость приложений.

Подборка материалов в следующем посте👇

#инструменты

🕸 Подборка материалов по Kubernetes

Конспект по Kubernetes доступен в предыдущем посте.

🌐 Официальная документация

🔹 Наши посты
1. Про Docker
2. Виртуализация, контейнеризация и оркестрация

🗒 Статьи (теория)
1. Кратко о Kubernetes
2. Kubernetes — основные понятия
3. Про возможности Kubernetes в сравнении с Docker
4. Подробнее про компоненты Kubernetes
5. Внутреннее устройство Kubernetes-кластера простым языком
6. Kubernetes: большой обзор технологии, установка и настройка
7. Docker Swarm vs Kubernetes

📝 Практика
1. Инструкция по установке и настройке Kubernetes на Ubuntu
2. Подробный гайд для новичков по установке Kubernetes
3. Попробовать потыкать Kubernetes на тестовом кластере
4. Визуальное руководство по диагностике неисправностей в Kubernetes
5. Шеринг GPU в Kubernetes с помощью MIG и TimeSlicing
6. Гайд по запуску приложений с высокой доступностью (HA) в Kubernetes
7. 10 типичных ошибок при использовании Kubernetes

💼 Кейсы по компаниям из цикла статей на Хабре
1. 4200 подов и TessMaster у eBay
2. Concur и SAP
3. GitHub
4. SoundCloud
5. Цифровой банк Monzo
6. BlaBlaCar
7. BlackRock
8. Huawei
9. ЦЕРН и 210 кластеров K8s
10. Reddit

⏯ Видео
1. Курс по Kubernetes с нуля
2. Что такое Kubernetes за 9 минут
3. 49 видеоуроков по Kubernetes
4. Открытая вечерняя школа. Kubernetes для разработчиков
5. Практика по Kubernetes — серия уроков

📚 Подборка книг для развития системного аналитика

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

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

Требования
📖 Вигерс Карл, Битти Джой. Разработка требований к программному обеспечению
📖 Алистер Коберн. Современные методы описания функциональных требований к системам
📖 Дин Леффингуэлл. Принципы работы с требованиями к программному обеспечению
📖 Джефф Паттон. Пользовательские истории. Искусство гибкой разработки ПО
📖 Халл Элизабет. Инженерия требований
📖 Юрий Химонин. Сбор и анализ требований к программному продукту

Архитектура и проектирование
📕 Роберт Мартин. Чистая архитектура. Искусство разработки программного обеспечения
📕 Эрик Эванс. Предметно-ориентированное проектирование (DDD)
📕 Вон Вернон. Реализация методов предметно ориентированного проектирования (DDD)
📕 Крис Ричардсон. Микросервисы. Паттерны разработки и рефакторинга
📕 Сэм Ньюмен. Создание микросервисов
📕 Беллемар Адам. Создание событийно-управляемых микросервисов
📕 C. Cомасегар. Руководство Microsoft по проектированию архитектуры приложений

Проектирование
📒 Александр Швец. Погружение в Паттерны Проектирования
📒 System Design. Подготовка к сложному интервью
📒 Мартин Фаулер. P of EAA: Шаблоны корпоративных приложений

Интеграции
📗 Грегор Хоп и Бобби Вульф. Шаблоны интеграции корпоративных приложений
📗 Джей Гивакс. Паттерны проектирования API
📗 Арно Лоре. Проектирование веб-API
📗 Сергей Константинов. API
📗 Дилан Скотт. Kafka в действии
📗 Ian Robinson. REST in Practice: Hypermedia and Systems Architecture
📗 Emil Koutanov. Effective Kafka

Своды знаний
📔 SEBoK — Systems Engineering Body of Knowledge
📔 BABOK — Business Analysis Body Of Knowledge
📔 INCOSE Guide for Writing Requirements
📔 DAMA-DMBOK — Data Management Body of Knowledge

Навыки
📓 Ф.П. Тарасенко. Прикладной системный анализ
📓 Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке
📓 Алан Купер. Психбольница в руках пациентов
📓 Карл Андерсон. Аналитическая культура
📓 Вера Иванова. Путь аналитика. Практическое руководство
📓 Максим Ильяхов и Людмила Сарычева. Пиши, сокращай: Как создавать сильный текст
📓 Роберт Фитцпатрик. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?
📓 Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы

UML
💣 Мартин Фаулер. UML. Основы
💣 Буч Грэди. Язык UML. Руководство пользователя
💣 Дж. Шмуллер. Освой самостоятельно UML за 24 часа
💣 Крэг Ларман. Применение UML и шаблонов проектирования
💣 Джим Арлоу. UML 2 и Унифицированный процесс
💣 М. Блаха. UML 2.0 Объектно-ориентированное моделирование и разработка
💣 Александр Леоненков. Самоучитель UML

Python
🐍 Эрик Мэтиз. Изучаем Python: программирование игр, визуализация данных, веб-приложения
🐍 Пол Бэрри. Изучаем программирование на Python
🐍 Эл Свейгарт. Автоматизация рутинных задач с помощью Python
🐍 Марк Лутц. Python. Карманный справочник
🐍 Аллен Б. Дауни. Основы Python. Научитесь думать как программист

Эта навигация будет дополняться в Библиотеке Системного Аналитика

#подборка

Подписка на закрытый канал для системных аналитиков

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

Оформить подписку можно через кнопки ниже:
1. Нажимаете на кнопку с выбранным тарифом
2. Бот Donate присылает ссылку на оплату
3. После оплаты вам будет предоставлен доступ к закрытому каналу. Ссылки на чаптер системных аналитиков и канал с тестовыми заданиями будут в описании закрытого канала.

Что будет входить в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес)

Что будет с текущим каналом?
Все уже опубликованные материалы в текущем канале (Системный Аналитик) останутся бесплатными. Однако новые материалы будут выходить реже:
— 2-3 полноценные подборки в месяц
— 1-2 конспекта по темам системного анализа еженедельно
— 1 книга каждую неделю

Текущие цены действуют для первых 50-ти подписчиков.

💠 Микрофронтенды – разбираем, что это такое

Микрофронтенды – это применение принципов микросервисного подхода к разработке фронтенда, при котором монолитный фронт разбивается на независимые части.

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

✏️ Пример использования

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

Разделяем функциональность приложения на несколько микрофронтендов:
➖ Каталог товаров: отвечает за отображение списка товаров, фильтрацию и сортировку.
➖ Корзина: обрабатывает добавление товаров в корзину и оформление заказа.
➖ Профили пользователей: Отображает персональную информацию и историю заказов.
➖ Система оплаты: обрабатывает оплату заказов.

✅ Преимущества микрофронтендов

💩Сокращение времени до релиза (time-to-market). Так как команды могут релизить свои части независимо от других, это ускоряет процесс доставки нового функционала.

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

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

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

⛔️ Недостатки микрофронтендов

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

💩Необходимость согласования и совместимости между разными технологиями и командами. Если мы захотим в мире микрофронтендов поменять брендовый цвет с оранжевого на красный, то нам нужно будет попросить все команды изменить этот цвет у себя в компонентах, а в монолите на это ушло бы минут 20.

💩Дублирование кода. В микрофронтендах сложнее переиспользовать код. Конечно, есть решения: сделать библиотеку компонентов, вынести все утилиты в одно место, написать шаблоны, Но всё равно встречаются места, которые идентичны во всех проектах (например, конфиг) и когда наступит время это править, может быть больно.

Подборка материалов по микрофронтендам доступна в базе знаний по системному анализу

#архитектура

🔎 Elasticsearch: краткое описание и подборка материалов

Elasticsearch (ES) — это распределенный поисковой и аналитический движок, построенный на основе Apache Lucene. Предоставляет открытый и гибкий интерфейс для хранения, поиска и анализа данных в реальном времени. Условно говоря, ES — это документоориентированная NoSQL БД и гугл одновременно.

Elasticsearch является частью стека ELK (Elasticsearch, Logstash и Kibana).

💩Logstash собирает, обрабатывает и передает данные из различных источников в хранилище, такое как ES. Поддерживает различные источники данных и форматы логов.
💩Elasticsearch индексирует и анализирует собранные данные и производит поиск в них.
💩Kibana предназначена для работы с логами, поддерживает гибкий и сложный поиск по логам. Так же в Kibana можно строить дашборды, отчёты и визуализировать данные.
💩Также есть Beats — легковесные агенты для отправки логов в ES. Они более примитивны, чем Logstash, т.к. только собирают и отправляют данные, без преобразований

Архитектура Elasticsearch распределенная:

1. Данные хранятся в виде JSON-документов
2. Эти документы индексируются для быстрого поиска
3. Каждый индекс разбивается на шарды для распределения их по узлам кластера, что позволяет балансировать нагрузку.
Кластер состоит из одного или нескольких узлов, объединенных в единое целое для совместной работы.

Как работает ES?

1. Данные отправляются в ES в виде документов JSON с помощью API или инструментов приема, например, Logstash.
2. ES автоматически сохраняет исходный документ и добавляет ссылку на него в индекс кластера, включая возможность поиска.
3. Следом можно найти и извлечь документ, используя API Elasticsearch.
4. Также для визуализации данных и создания интерактивных панелей управления можно задействовать Kibana.

🔨Применение ES

— Мониторинг и логирование. Хранение, поиск и анализ логов для отслеживания работы приложений, системы, серверов .

— Аналитика и BI. Поиск, фильтрация, агрегация, анализ больших объемов данных в реальном времени для выявления паттернов, создания отчетов. Например, компании в финансовой сфере используют ES для анализа данных о транзакциях, инвестициях и рынке

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

✅Преимущества ES

💩Быстрый поиск и агрегация данных. Обеспечивает мгновенный доступ к данным и эффективный поиск за счет распределенной архитектуры, индексации и возможности добавлять новые узлы в кластер
💩Отказоустойчивость. Достигается благодаря распределению данных и запросов между различными узлами кластера и шардами. В случае проблем ES автоматически восстанавливает реплики и данные.
💩Масштабируемость и гибкость. ES можно масштабировать горизонтально без потери производительности. Кластеры ES могут расширяться и сжиматься в зависимости от потребностей с помощью добавления новых узлов.
💩Экосистема ELK: входит в стек ELK, предоставляя комплексное решение для обработки, хранения и визуализации данных.

⛔️Недостатки ES

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

⭐️ Подборка материалов по Elasticsearch доступна в базе знаний по системному анализу

#инструменты

Обзор популярных нотаций моделирования

Владение нотациями крайне важно для системного аналитика. Это must have, который встречается практически в любой вакансии

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

Зачем нужны нотации

1️⃣ Визуализация сложного в картинках

2️⃣ Моделирование — позволяют создавать описание структуры данных для анализа системных процессов (например, для фиксации требований)

3️⃣ Стандартизация — единый язык для коммуникации между разными специалистами (например, бизнеса, разработки)

Виды нотаций

💩 Структурные нотации: отображают состав объекта и взаимодействие между его частями. Примеры: UML-диаграммы классов, компонентов, кооперации, композитной структуры, развертывания, пакетов, объектов и профилей. К таким нотациям относятся IDEF0, IDEF1x, IDEF4, IDEF5 и IDEF6 из стандарта IDEF.

💩 Динамические нотации: показывают потоки данных или логику выполнения процессов. Примеры: DFD, EPC, BPMN, а также UML-диаграммы деятельности, состояний, вариантов использования и последовательностей.

Примеры распространённых нотаций

🔹 BPMN (Business Process Model and Notation) — используется для моделирования бизнес-процессов. Представляет собой набор графических элементов, которые отображают задачи, события, шлюзы, потоки, пулы, дорожки и т.д. BPMN позволяет наглядно и однозначно описать логику, последовательность, роли и правила выполнения бизнес-процессов.

🔸 eEPC (extended Event-driven Process Chain) — нотация моделирования бизнес-процессов с фокусом на события и их результаты. eEPC показывает, какие события инициируют, контролируют и завершают функции, а также какие ресурсы и данные участвуют в процессах.

🔹 IDEF (Integrated DEFinition) — семейство нотаций (IDEF0, IDEF1, IDEF2 и т. д.) для описания разных видов моделирования, например, функционального, данных, логики и т.д. Одна из старейших нотаций.

🔸 UML (Unified Modeling Language) — это система обозначений, которую можно применять для объектно-ориентированного анализа и проектирования. UML имеет 12 диаграмм, которые показывают структуру и поведение системы на разных уровнях.

🔹 DFD (Data Flow Diagram): для визуализации и анализа потоков данных в информационной системе. Помогает выявить входы, выходы и обработку данных в различных процессах.

🔸 ERD (Entity-Relationship Diagram) — нотация для моделирования сущностей и их отношений в базах данных. ERD показывает, какие сущности существуют в базе данных, какие атрибуты их описывают, какие связи между ними устанавливаются и какие ключи обеспечивают их идентификацию и целостность.

🔹 С4 (Context, Containers, Components, Code) – простая нотация для описания архитектуры. Модель объединяет 4 иерархических уровня: контекст, контейнеры, компоненты и классы.

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

📎 Ссылки
1. Один пример и три нотации: сравниваем BPMN, EPC и DMN
2. Ликбез по BPMN, EPC и UML activity с примерами для начинающих аналитиков
3. Основные нотации моделирования бизнес процессов и их применение
4. Плюсы и минусы IDEF, eEPC, BPMN
5. ТОП-5 нотаций моделирования архитектуры

⭐️ Подборка материалов по каждой нотации доступна в базе знаний по системному анализу

#проектирование #подборка

User Story vs Job Story

📄User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт

Цель: декомпозировать требования на понятные и выполнимые элементы
Формула: Я, как [тип пользователя], хочу [желание], чтобы [ценность или результат]
Пример: Я, как пользователь сайта, хочу получить трек-номер, чтобы следить за посылкой. Я, как пользователь, могу запросить напоминание пароля, чтобы восстановить пароль

Как составить user story:
➖Определите пользователя, для которого создается функция
➖Сформулируйте результат, который получит пользователь после использования функции
➖Опишите ситуацию, в которой пользователь может использовать функцию
➖Укажите ограничения или условия, при которых функция должна работать

Способ проверки “INVEST”:
➖«I» Independent — независима от других историй
➖«N» Negotiable — обсуждаема, по ней можно спланировать дальнейшие действия
➖«V» Valuable — ценная, отвечает на вопрос «зачем»
➖«E» Estimable — оцениваемая, можно установить критерии успеха
➖«S» Small — маленькая или короткая, описывает одну задачу
➖«Т» Testable — тестируемая - можно получить обратную связь от пользователей и сделать выводы


🎯Job Story (инструмент из концепции Jobs To Be Done (JBTD)) - это описание возможных ситуаций, при которых пользователь хочет воспользоваться нашим продуктом

Цель: определить ситуации, в которых у пользователя возникает потребность в продукте
Формула: Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]
Пример: когда пользователь оплатил заказ на сайте, он беспокоится, доставят ли ему товар и хочет получить трек-номер, чтобы следить за посылкой

Способ проверки:
➖Описывает результат, который получит пользователь
➖Не содержит готовое решение
➖Описывает контекст, в котором человек находится при возникновении проблемы, а не саму проблему
➖Отвечает на вопрос «Почему/для чего?» мы должны это сделать

Отличия:
💩User Story описывает конкретный сценарий с точки зрения пользователя, Job Story - общую задачу, которую он выполняет в системе
💩User Story фокусируется на описании одной задачи, Job Story может включать в себя несколько User Story
💩User Story помогать лучше узнать пользователей, Job Story отвечают на вопрос почему они продолжают пользоваться продуктом и почему приходят новые


Совмещение инструментов:
1. Изучить потребности пользователей
2. Описать потребности по шаблону Job Story, это позволит видеть картину пользователя целиком: его чувства, эмоции, привычные реакции
3. Придумать как удовлетворить потребности, описанные в Job Story
4. Выбрать решение и описать его по шаблону User Story
5. Передать User Story в разработку

Итог:
💩Job Story подходит, если нужны идеи для доработки текущего продукта или создания нового
💩User Story подходит, если нужно декомпозировать и описать уже выбранное решение

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#требоваия

Тест-кейсы: как и зачем писать📝

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

Виды тест-кейсов:

✅ Позитивные (положительные). Проверяют, что система правильно реагирует на корректные данные
Пример: пользователь существует в системе и он может пройти авторизацию

❌ Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными
Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный

🚫 Деструктивные. Служат для проверки прочности системы
Пример: метод для получения заказов пользователя нельзя выполнить без авторизации


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


Содержание тест-кейса

💫Уникальный номер. Позволит ссылаться на тесты по номеру
💫Заголовок. Отражает цель - что именно нужно проверить
💫Предусловия. Что нужно сделать перед началом тест-кейса
💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных
💫Шаги. Что нужно сделать для проверки
💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”
💩Скриншоты можно использовать только как дополнение к текстовому описанию
💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов
💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком


Use Case 🆚 Test Case

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

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


👨‍💻 Аналитик и тест-кейсы
➖На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем
➖Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе
➖Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям


Инструменты ведения для тест-кейсов:
➖Zephyr for Jira
➖TestRail
➖Qase
➖Test IT


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#тестирование