кейс тесты по истории

Задачи «спецназа»

Не первая в списке, но одна из важных задач – это «спецназ».

Само название в целом описывает главную задачу – прийти и помочь решить проблему (мы) для успешного внедрения в прод.

Объемы помощи зависят от количества и сложности проблем, а также от сложности тестируемых процессов.

Важная особенность спецназа – скорость погружения в задачу: нужно быстро разобраться в процессах, понять, где проблема и как ее решить.

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

В нашем спецназе только опытные инженеры – задачи разношерстные по сложности и технологиям – знания нужны в различных областях.

В этом году в рамках спецназа мы поучаствовали в таких проектах, как:

Процесс в общих чертах выглядит так:

Далее отчет передается заинтересованным лицам.

Глоссарий

Система управления тестами (Test management system) — это система, которая предназначена для управления процессами тестирования. В ней содержится тестовая документация, тест-планы, история результатов тестов, данные об автотестах и их запусках, а также отчеты о тестовых активностях.

Рабочий элемент (Work item) — это единица тестовой документации, содержащаяся в системе управления тестированием. Рабочие элементы можно упорядочить в библиотеке тестов с помощью разделения на секции. В системе Test IT существует три вида рабочих элементов:

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

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

Предусловия теста (Test preconditions) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель предусловий — предотвращение начала задачи, которое может потребовать больше усилий, чем на устранение не пройденных критериев входа.

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

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

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

Отчет по тест-плану (Test plan report) — это документ, подводящий итог задачам и результатам, составляемый с определенной периодичностью с целью сравнения прогресса тестирования с базовой версией и извещения о рисках и альтернативах, требующих решения руководства.

Автотест (Autotest) — это Unit / API / e2e / интеграционный тест, который выполняет определенный тестовый сценарий.

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

Тест-ран (Test run) — прогон автотестов в системе управления тестированием Test IT, формируется при выборе и запуске автотестов в системе, либо создается через API. На тест-ран ссылаются результаты запуска автотестов, объединенные этим запуском.

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

Адаптер (Adapter) — это расширение для тестового фреймворка, которое осуществляет сбор метаданных автотестов из тестового фреймворка, а также их обработку и передачу в Test IT через API клиент. Адаптер не может работать без API клиента.

API Клиент (API Client) — клиентская библиотека для взаимодействия с Test IT. Это обёртка (синтаксический сахар) для удобства работы с API Test IT через разные языки программирования. API клиент самодостаточен и не требует адаптер для работы. При этом API клиент может работать с любыми API методами Test IT. Вынесен в отдельный компонент для того, чтобы можно было переиспользовать его для других адаптеров на таком же языке программирования.

Тестовый фреймворк (Testing framework) — фреймворк для автоматизации тестирования на разных языках программирования. Создан для того, чтобы при помощи кода можно было создавать автотесты и выполнять их в различных средах разработки. Таких фреймворков очень много на разных языках программирования, к примеру, на Python (Pytest, Robot Framework), Java (Cucumber, JUnit, Selenide), JavaScript (Mocha, Jest, Jasmine), C# (NUnit, xUnit, MSTest).

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

Ключевые задачи

В нашей компании несколько команд, отвечающих за свой продукт и его функциональность. Каждая продуктовая команда состоит из аналитиков, разработчиков, тестировщиков и тд. Такая «группировка» повышает компетенции команды, её сыгранность, что в свою очередь ускоряет TTM и качество выпускаемого командой продукта.

Но наша команда проводит не совсем привычное тестирование и не относится к «продуктовым» командам — мы тестируем на прод среде.

Наши ключевые поинты:

Почему же именно тестирование на проде, а не на тест среде или на отдельной стейдж среде?

По нескольким причинам:

В целом это задача не тривиальная и, скорее всего, не имеет решения а-ля «сделай как 100 человек до тебя», индивидуальна и завязана на ресурсы и процессы внутри компании.

Но вернемся к задаче и поговорим о каждом поинте поподробнее:

Чек-листы

Правила составления чек-листов:
Одна операция.
Пункты чек-листа — это минимальные полные операции. Например, заказать
изготовление визиток и доставить визитки в офис — это 2 разных операции.
Поэтому в чек-листе они отображаются отдельными пунктами: визитки заказаны и
визитки доставлены в офис.
Пункты пишутся в утвердительной форме. Цель чек-листа – проверка готовности
задачи, поэтому лучше составлять пункты в утвердительной форме — «заказаны,
доставлены». Сравните формулировку: «заказать визитки» и «визитки заказаны».
Оптимальное количество пунктов — до 20. Чек-листы не должны быть длинными.
Если все же это требуется, то лучше разбить задачу на несколько этапов и
составить к каждому этапу отдельный чек-лист.

Структура тест кейса

Идентификатор представляет собой уникальное значение, позволяющее однозначно
отличить один тест-кейс от другого и используемое во всевозможных ссылках.
Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B,
C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний»,
«низкий», «крайне низкий») или иным удобным способом. Количество градаций
также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.
Связанное с тест-кейсом требование показывает то основное требование, проверке
выполнения которого посвящён тест-кейс.
Модуль и подмодуль приложения указывают на части приложения, к которым
относится тест-кейс, и позволяют лучше понять его цель.

Тест план

Преимущества тест плана:
• Возможность приоритезации задач по тестированию.
• Построение стратегии тестирования, согласованной со всей командой.
• Возможность вести учет всех требуемых ресурсов (как технических, так и
человеческих).
• Планирование использования ресурсов на тестирование.
• Просчет рисков, возможных при проведении тестирования.
Составляющей частью планирования тестирования (как отдельного документа или
же процесса планирования в целом) является стратегия тестирования. Стратегия
может быть:
• Частью общего тест-плана.
• Отдельным документом.

Шаг 3. Как запланировать тесты

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

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

Создание плана тестирования

Чтобы создать новую задачу с типом «План тестирования», выполните следующие действия.

Шаг 1. В верхней части экрана нажмите Create (Создать), чтобы открыть диалоговое окно (страницу) Create Issue (Создать задачу). Можно также нажать на клавиатуре клавишу C.

Шаг 2. Выберите Project (Проект). В поле Issue Type (Тип задачи) выберите Test Plan (План тестирования).

Шаг 3. Заполните поле Summary (Описание) плана тестирования и другие обязательные поля (отмечены звездочкой). По желанию заполните необязательные поля.

Шаг 4. После заполнения формы для плана тестирования нажмите Create (Создать).

Ошибки при создании тест-кейсов

Посмотрим, как правильно писать тест-кейсы и какие ошибки в них недопустимы.

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

Неправильно: Уведомление пользователя об отсутствии интернет-соединения.
Правильно: Уведомление пользователя о потере Wi-Fi сигнала вручную.

Дело не в практической целесообразности, а в элементарной вежливости.

Неправильно: перейди на страницу; введи значение и т.д.
Правильно: перейти на страницу; ввести значение и т.д.

Это касается как гиперссылок внутри программы, так и внешних ресурсов. Каждую ссылку надо делать кликабельной с помощью Ctrl + K.

Формулировки шагов тест-кейса не должны вызывать вопросов, но при этом не надо писать очевидные вещи.

Неправильно: Наведите мышку и нажмите на зеленую кнопку внизу страницы посередине с надписью «Согласен».

Правильно: Нажмите на кнопку «Согласен».

Правильный тест-кейс лаконичен, но при этом не требует дополнительных объяснений.

Неправильно: Открыть меню «Дополнительные возможности».
Правильно:

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

Ошибки при создании тест-кейсов

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

Два или три тест-кейса для проверки граничных значений?

Большинство тестировщиков знакомы с такими техниками тест-дизайна, как разбиение на эквивалентные классы и анализ граничных значений.

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

В двух словах напомню.

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

Граничные значения – значения диапазона входных данных, при которых меняется поведение приложения. Это соседние значения диапазона, но относящиеся к разным эквивалентным классам. И хотя сами граничные значения являются элементами/представителями своих классов, они должны быть протестированы в дополнение к проверке значения из середины класса. Почему? Необходимость заложена из предпосылок, что при написании кода, разработчик может ошибиться при указании границ и/или логики.

Перейдем к рассмотрению конкретного примера и оценки количества необходимых тест-кейсов.

Вопрос: сколько тест кейсов необходимо для покрытия граничных значений и классов эквивалентности на примере доступа к функционалу приложения на основе возраста (для целочисленных значений от 1 до 100)?

Здесь будут рассмотрены только позитивные сценарии без проверки границ диапазона 1 и 100 (без тестирования 0, отрицательных чисел, букв, спец. символов).

Граничные значения: 17 и 18.

Классически тестируются два значения для границы (17 и 18 для нашего примера), когда при переходе от одного к другому меняется поведение (выходной результат). При этом граница не является конкретным значением, она определена граничными значениями двух соседних классов эквивалентности.

Значение 18 является элементом класса 18-100, и логически, если проверка проходит на 18, то нет никакой вероятности (кроме умышленного исключения значения 19 в коде), что 19 не пройдет проверку, т.к. оно является элементом того же класса 18-100.

То же самое справедливо для значения 17, если мы рассматриваем класс 1-17, нет никакой необходимости тестировать значение 16.

Встречается мнение о необходимости тестирования границы с двух сторон, при этом граница определяется как конкретное значение, указанное в ТЗ (или первое, граничное значение класса). Этот подход либо не объясняется вообще (давайте на всякий случай протестируем +/- «границу»), либо тем, что программист может ошибиться в выборе границы и указать 17 (или 19) вместо 18.

И в дальнейшем предлагается тестировать три значения: 17 – нижняя граница, 18 – собственно граница, 19 – верхняя граница.

Составим некое подобие матрицы трассируемости/прослеживаемости (traceability matrix) для анализа покрытия случайных ошибок в коде нашими выбранными значениями.

Смоделированы следующие ошибки в коде: неверное определение границ (соседние числа к «границе» значений) и/или неверная логика (вариации со знаками неравенств).

В самих таблицах:

+ — значение покрывает тестируемую ситуацию (ошибку в коде).

Если вводим значение в пределах класса, и результат FALSE (должен, а не пускает) – у нас выявлена ошибка в коде.

Если вводим значение за пределами класса, и результат TRUE (не должен, а пускает) – у нас выявлена ошибка в коде.

Таблица покрытия для ошибок «17 вместо 18 и неверная логика»

Таблица покрытия для ошибок «неверная логика»

Таблица покрытия для ошибок «19 вместо 18 и неверная логика»

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

Ответ на поставленный ранее вопрос: 2 тест-кейса на каждую границу + 1 на каждый класс (для нашего примера проверяем значения 10, 17, 18, 25).

Шаг 2. Как организовать тесты

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

Организовать тесты в Xray можно двумя способами.

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

Создание набора тестов

Чтобы создать новую задачу с типом «Набор тестов», выполните следующие действия.

Шаг 1. В верхней части экрана нажмите Create Issue (Создать задачу), чтобы открыть диалоговое окно (страницу) Create Issue (Создать задачу).

Шаг 2. Выберите Project (Проект). В поле Issue Type (Тип задачи) выберите Test Set (Набор тестов).

Шаг 3. Заполните поле Summary (Описание) набора тестов и другие поля, отмеченные звездочкой. По желанию заполните необязательные поля.

Шаг 4. После заполнения формы для набора тестов нажмите кнопку Create (Создать).

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

Создание репозитория тестов

Чтобы создать репозиторий тестов, создайте новую папку.

Шаг 1. Нажмите родительскую папку.

Шаг 2. Нажмите значок добавления в верхней части раздела папок.

Шаг 3. В диалоговом окне Create Folder (Создать папку) укажите имя папки.

Шаг 4. Нажмите кнопку Create (Создать), чтобы создать папку.

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

Для техники «Парное тестирование» нужно открыть любой интернет-магазин и каталог товаров. Пусть это будут «Cмартфоны, ТВ и электроника».

Давайте посмотрим на левую панель. Здесь есть обширный фильтр: по продавцу, отправке, бренду, алфавиту, цене, беспроцентному кредиту и т.д. В чем суть парного тестирования? Мы имеем много разных характеристик, по которым нужно сортировать, но мы будем тестировать не по одной характеристике, а сразу по двум. Для чего? Чтобы проверить, какая будет реакция у системы, какой будет результат. Переходим к практике. Сначала мы должны протестировать продавца и готовность к отправке. Ставим две галочки:

Ставим две галочки в фильтрах

И проверяем, что есть товары, отфильтрованные по продавцу и по готовности к отправке. Теперь убираем галочку с «Готов к отправке» и ставим следующий фильтр, например, бренд:

Применяем следующий фильтр

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

Идем дальше, убираем фильтр цены и ставим на «страну производителя», допустим, Индонезия. Видим, что отфильтровано два товара — тест пройден:

Убираем страну-производителя и ставим фильтр на страну регистрации бренда — Австралию. И так проходимся по комбинациям из двух разных фильтров, пока не протестируем все со всеми (первый и второй, первый и третий, второй и третий).

Угадывание ошибок

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

Какие типичные условия следует попробовать, чтоб пройти угадывание ошибок:

Это самые часто встречающиеся ошибки.

Тесты на прод. Наша история

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

Меня зовут Дмитрий Пирумов, я возглавляю команду автоматизированного и приемочного тестирования в РТЛабс. В этой статье я хочу поделиться опытом проведения тестирования на проде, внедренного у нас в компании, и попробовать показать профит и болевые точки такого подхода.

Определения

Использование кейс-метода на уроках истории и обществознания как один из способов реализации деятельностного подхода в современном школьном образовании.

ФГОС предусматривают широкое использование активных, в том числе ситуативных методов обучения. Именно к таким относится кейс-метод.

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

Для применения в обучении кейс- метод имеет следующие особенности:

Рекомендуется следующая последовательность работы над кейсом:

Для представления результатов работы рекомендуется:

Критерии эффективности работы группы:

Алгоритм работы в группе:

Таким образом, кейс – метод действительно может рассматриваться как один из способов достижения новых образовательных результатов в условиях внедрения ФГОС.

Пример №1. Кейс по истории.

Тема: «Мир на пути ко второй мировой войне».
9 класс. Базовый уровень.

А. Прочитайте информацию о своей стране.
Б. Сформулируйте письменно 2-3 основные внешнеполитические задачи данной страны.

Сформулируйте вывод по основной заданной проблеме (1-2 предложения):
«Можно ли было предотвратить начало второй мировой войны?»

Материалы для кейса:

Особенности внешней и внутренней политики стран Европы в 20-30 ее гг. XX века (Франция, Великобритания, США. Германия, СССР).

1 страна — 1 группа.

Пример №2. Кейс по обществознанию.

Тема: Система ценностей личности в современном мире.
11 класс. Базовый уровень.

Каковы принципы Христианской морали по тексту Нагорной проповеди? Сохранили ли они свое значение в наши дни?
(при ответах нужно использовать текст)

Что значит «быть человечным», по мнению Д.С. Лихачева?
(при ответах нужно использовать текст)

Нагорная проповедь Иисуса Христа, Евангелие от Матфея (выдержки);
10 заповедей человечности Д.С. Лихачева.

Список использованной литературы:

Порядок вывода комментариев:

В помощь учителю

Уважаемые коллеги! Опубликуйте свою педагогическую статью или сценарий мероприятия на Учительском портале и получите свидетельство о публикации методического материала в международном СМИ.

Диплом и справка о публикации каждому участнику!

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

Все материалы, размещенные на сайте, созданы пользователями сайта и представлены исключительно в ознакомительных целях. Использование материалов сайта возможно только с разрешения администрации портала.

Что такое тест кейс простыми словами?

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

Что должно входить в тест кейс?

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

В чем заключается различие между тест кейсом и баг Репортом?

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