Manual quality assurance engineer
В процессе выполнения задания предстоит работа с небольшой системой учета задач. Нужно будет выполнить полноценное тестирование и составить по нему отчет.
Во второй части задания предстоит разобраться с инструментом, в основе которого лежит метод попарного тестирования и составить список проверок определенного тестового сценария.

Этап 1. Ручное тестирование

Адрес платформы
http://qa-assignment.oblakogroup.ru/board/:id, где id — ваше имя и фамилия в формате alexey_ivanov
Описание платформы для тестирования
Основная цель данного программного решения — создание категоризированных to-do листов.
Основной функционал
  • На странице отображаются все задачи (элементы to-do листа), которые создал пользователь;
  • Все задачи разбиты на категории;
  • Пользователь может добавить новую задачу в список;
  • Задача может быть добавлена в список с новой или уже существующей категорией;
  • Задача в to-do листе может быть выполненной и не выполненной.
Создание задачи
Пользователь нажимает на кнопку добавления новой задачи, появляется интерфейс для создания новой задачи. При создании новой задачи необходимо указать категорию и текст задачи. Если задача добавляется в новую категорию, пользователь должен указать название новой категории. Когда пользователь подтверждает создание, задача появляется в категории, которая была указана.

Изменение статуса задачи
Список дел состоит из элементов, которые могут иметь два состояния: выполнено и не выполнено.

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

У не выполненного элемента чек-бокс пуст, текст никак не форматирован.
Свойства категории
  • Заголовок категории не может быть пустым;
  • Заголовок категорий должны быть разными;
  • Если пользователь добавляет новую запись в новую категорию, но вводит название существующей, то запись добавляется в существующую.
Свойства задачи
  • Название задачи не может быть пустым;
  • Имеет два состояния: выполнена и не выполнена;
  • Принадлежит к заданной пользователем категории.
Дизайн
Что необходимо сделать
  • Изучить описание и дизайн, изложенные в задании;
  • Составить тест-план, по которому будет производиться тестирование;
  • Произвести тестирование;
  • Предоставить тест-план и отчет о произведенном тестировании.
По завершению этапа необходимо отправить результаты с указанием адреса страницы, на которой производили тестирование, с темой письма «MQA — Номер этапа, Имя Фамилия» на:
Затем приступать к выполнению следующего этапа.

Этап 2. Попарное тестирование

Вы достаточно изучили работу системы и можете перейти ко второй части задания. Вам предстоит создать тестовые кейсы для определенной фичи, убрав избыточные проверки и обеспечив хорошее тестовое покрытие при минимальном наборе тестов. Для этого нужно использовать специальный инструмент для попарного тестирования.
Ресурсы для изучения
Инструмент для создания тест-кейсов
Задание
Функционал, который нужно покрыть тестами: Пользователь создаёт 1 задачу в todo-листе

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

Для этого необходимо сделать:
  1. Разберитесь, что означает термин "Попарное тестирование"
  2. Придумайте названия событий, которые могут происходить на странице и составьте их список
  3. Придумайте названия полей для ввода, выпадающих списков и кнопок на странице и составьте списки
  4. Придумайте шаги для сценария, в которых нужно использовать ваши события
  5. Придумайте тестовые данные для позитивных и негативных кейсов
  6. Напишите собственную модель. При написании модели вы должны придерживаться формата, указанного в документе Oblako-Model.txt
  7. Сгенерируйте результат с различными тестовыми сценариями на основе вашей модели в Pairwise PICT Online

При создании названий вы должны придерживаться некоторых правил:
  • Названия событий должны быть в стиле camelCase. Также события бывают разного типа (см. Пример 1)
  • Названия кнопок / инпутов / выпадающих списков должны быть в стиле UPPER_SNAKE_CASE (см. Пример 2)
  • Для каждого из типа событий следует придерживаться определенного стиля при написании модели (см. Пример 3)

Пример 1 - Список с разными типами событий (Events):
  • testEvent1
  • testEvent2(data)
  • testEvent3[Data]
  • testEvent4(data)[Data]

Пример 2 - Название выпадающего списка:
  • FOO_BAR_LIST

Пример 3 - Тестовые модели для каждого типа событий из примера 1:
  • Модель 1:
Step 1: testEvent1, otherEvent1, otherEvent2

  • Модель 2:
Step 1: testEvent2(YES), testEvent2(NO)

  • Модель 3:
Step 1: testEvent3
Step 1 Data: test_data1, test_data2, test_data3

  • Модель 4:
Step 1: testEvent4(FOO_BAR_LIST)
Step 1 Data: test_data1, test_data2, test_data3

Далее вам предстоит создать тестовый сценарий из шагов (см. Пример 4).

Пример 4 - Сценарий с шагами (skipStep - пропуск шага):
Step 1: testEvent4(FOO_BAR_LIST)
Step 1 Data: test_data1, test_data2, test_data3
Step 2: skipStep, testEvent2(YES), testEvent2(NO)
Step 3: skipStep, testEvent1
Step 4: testEvent3
Step 4 Data: test_data1, test_data2, test_data3

Примечания
  • Для написания модели удобно использовать обычный текстовый редактор с поддержкой табуляции
  • Учитывайте эквивалентные значения (не перегружайте ваши тесты лишними кейсами);
  • Желательно пишите условия в вашей модели
  • Можно использовать конструкции: IF THEN, IF NOT THEN и так далее;
  • В конце ваших условий не забывайте ставить точку с запятой, иначе программа ругается на синтаксис
  • Негативные сценарии указываются с помощью знака ~;
  • Данный инструмент не поддерживает русские символы. При формировании модели используйте английские значения (например: "Создать новый список" = "Create new list" и т.д.).
Результаты
Результаты присылайте в виде 2-ух ссылок на Google Docs:
  1. Ссылка на саму модель (Google-документ)
2. Ссылка на полученные результаты (Google-таблица)
По завершению этапа необходимо отправить результаты с темой письма «MQA — Номер этапа, Имя Фамилия» на: