Собес: 6. Тестирование прав доступа: как использовать таблицы решений (Decision Tables) в QA.
#Тестирование #QA #ТестДизайн #ПраваДоступа #DecisionTable #ОбучениеQA #ITСобеседование 6. Давай такая ситуация. Мы сейчас должны дизайнить какие-то тест-кейсы. Но, ситуация вот такая. У нас user story. По 3-ем usеer группам. У нас есть три user группы, допустим, admin user group, project manager user group и обычный user. Каждый из них делает какой-то action, допустим, админ создаёт проект, project-менеджер создаёт task, а обычный юзер делает этот tasк. И может быть ещё много там actions по каждому каждой группе. Мы должны создать тесткейсы. Но для этого мы должны использовать decision table, чтобы дизайнить эти тесткейсы. и да, э, там содержать все, а, и позитивные, и негативные там тестдата. Вот как бы ты там организовала всё это? Знаешь, что такое decision table? Как его использовать? Давай подумать вот так. Каждый usер-групп имеет два экшена. Админ, например, создаёт проект и админ может дашборд видеть. Второй usер-групп - это project-менеджер, кто создаёт и кто может delete делать этот task. А третье - это у нас обычный user, кто может делать этот tasк и может посмотреть свой дашборд. Вот если у нас такая ситуация, то есть actions, которые делают несколько user group, и есть экшены, которые только делает только один user group. Чтобы создавать тест-кейс, нам надо создавать decision table. Вот как бы ты создал, где что положил? Какая информация? Где это бы создала? Допустим, у тебя там колонки есть там где что именно ты поставила? А Expected Result где даёшь? В том же колонке, в том же в ячейке. А как держишь тогда тест дату? позитивный, негативный. Тестирование прав доступа в приложении часто напоминает *настоящий лабиринт*. Как убедиться, что ни один хитрый сценарий не упущен, когда ролей и действий становится слишком много? В этом видео мы разберем *таблицы решений* — мощный инструмент тест-дизайна, который наведет порядок в любом хаосе доступов. *В этом ролике мы покажем:* * *Прямой подход:* Как быстро набросать план тестирования, где каждая строка — это готовый *тест-кейс*. * *Структурированный подход:* Метод для «железобетонного» покрытия, который заставляет систему условий и действий работать на вас. * *Масштабируемый подход:* Разделение логики на *мастер-таблицы* и *таблицы деривации* для огромных и сложных систем. * *Выбор инструмента:* Какой метод подойдет именно вам — от быстрой проверки небольшого проекта до подготовки к *автоматизации*. * *Бизнес-правила vs Тест-кейсы:* Как превратить абстрактные правила в конкретные проверки с кодами ответов API (201, 403 и др.). Умение строить логические модели системы — это признак *высокого профессионализма* QA-инженера. Посмотрите ролик, чтобы перестать путаться в правах доступа и начать использовать системный подход! [00:00] — Введение: Почему тестирование прав доступа — это лабиринт. [00:48] — Исходные данные: Разбираем роли (Админ, Менеджер, Пользователь). [01:07] — Таблица решений как ключ к системному мышлению. [01:25] — Метод №1: Прямой подход. Простота и наглядность для быстрых задач. [02:02] — Метод №2: Структурированный подход. Гарантия полного покрытия. [03:07] — Метод №3: Масштабируемый подход. Для сложных систем и автоматизации. [03:34] — Мастер-таблица: Фиксация бизнес-правил. [03:55] — Таблица деривации: Превращаем правила в детальные тесты. [04:32] — Сравнение подходов: Как выбрать идеальный метод под вашу задачу. [05:00] — Итоги: Эволюция мысли от перечисления кейсов к логической модели. [05:22] — Заключение и вопрос к зрителям. 👉 *Подписывайтесь на канал, чтобы прокачивать свои навыки тест-дизайна и системного анализа!* 💬 *Какой подход к тестированию доступов используете вы в своих проектах? Пишите в комментариях, обсудим!*
#Тестирование #QA #ТестДизайн #ПраваДоступа #DecisionTable #ОбучениеQA #ITСобеседование 6. Давай такая ситуация. Мы сейчас должны дизайнить какие-то тест-кейсы. Но, ситуация вот такая. У нас user story. По 3-ем usеer группам. У нас есть три user группы, допустим, admin user group, project manager user group и обычный user. Каждый из них делает какой-то action, допустим, админ создаёт проект, project-менеджер создаёт task, а обычный юзер делает этот tasк. И может быть ещё много там actions по каждому каждой группе. Мы должны создать тесткейсы. Но для этого мы должны использовать decision table, чтобы дизайнить эти тесткейсы. и да, э, там содержать все, а, и позитивные, и негативные там тестдата. Вот как бы ты там организовала всё это? Знаешь, что такое decision table? Как его использовать? Давай подумать вот так. Каждый usер-групп имеет два экшена. Админ, например, создаёт проект и админ может дашборд видеть. Второй usер-групп - это project-менеджер, кто создаёт и кто может delete делать этот task. А третье - это у нас обычный user, кто может делать этот tasк и может посмотреть свой дашборд. Вот если у нас такая ситуация, то есть actions, которые делают несколько user group, и есть экшены, которые только делает только один user group. Чтобы создавать тест-кейс, нам надо создавать decision table. Вот как бы ты создал, где что положил? Какая информация? Где это бы создала? Допустим, у тебя там колонки есть там где что именно ты поставила? А Expected Result где даёшь? В том же колонке, в том же в ячейке. А как держишь тогда тест дату? позитивный, негативный. Тестирование прав доступа в приложении часто напоминает *настоящий лабиринт*. Как убедиться, что ни один хитрый сценарий не упущен, когда ролей и действий становится слишком много? В этом видео мы разберем *таблицы решений* — мощный инструмент тест-дизайна, который наведет порядок в любом хаосе доступов. *В этом ролике мы покажем:* * *Прямой подход:* Как быстро набросать план тестирования, где каждая строка — это готовый *тест-кейс*. * *Структурированный подход:* Метод для «железобетонного» покрытия, который заставляет систему условий и действий работать на вас. * *Масштабируемый подход:* Разделение логики на *мастер-таблицы* и *таблицы деривации* для огромных и сложных систем. * *Выбор инструмента:* Какой метод подойдет именно вам — от быстрой проверки небольшого проекта до подготовки к *автоматизации*. * *Бизнес-правила vs Тест-кейсы:* Как превратить абстрактные правила в конкретные проверки с кодами ответов API (201, 403 и др.). Умение строить логические модели системы — это признак *высокого профессионализма* QA-инженера. Посмотрите ролик, чтобы перестать путаться в правах доступа и начать использовать системный подход! [00:00] — Введение: Почему тестирование прав доступа — это лабиринт. [00:48] — Исходные данные: Разбираем роли (Админ, Менеджер, Пользователь). [01:07] — Таблица решений как ключ к системному мышлению. [01:25] — Метод №1: Прямой подход. Простота и наглядность для быстрых задач. [02:02] — Метод №2: Структурированный подход. Гарантия полного покрытия. [03:07] — Метод №3: Масштабируемый подход. Для сложных систем и автоматизации. [03:34] — Мастер-таблица: Фиксация бизнес-правил. [03:55] — Таблица деривации: Превращаем правила в детальные тесты. [04:32] — Сравнение подходов: Как выбрать идеальный метод под вашу задачу. [05:00] — Итоги: Эволюция мысли от перечисления кейсов к логической модели. [05:22] — Заключение и вопрос к зрителям. 👉 *Подписывайтесь на канал, чтобы прокачивать свои навыки тест-дизайна и системного анализа!* 💬 *Какой подход к тестированию доступов используете вы в своих проектах? Пишите в комментариях, обсудим!*