Bdd-тестирование чат-бота

Содержание

Развенчание мифов или как применять исследовательское тестирование

Миф 1:Миф 2:Миф 3:

список протестированных функциональностей продукта (чтобы примерно оценить тестовое покрытие, а также необходимость дополнительных исследований);
список дефектов (найденных вообще или только самых критических – в зависимости от того, для кого и на какой стадии тестирования делается отчет. А также в зависимости от общего количества дефектов в продукте в целом);
внутренние отчеты можно дополнить проблемами, вопросами и/или наблюдениями;
риски

Здесь важно рассказать о том, что не было протестировано и в связи чем это произошло – функциональность не входила в cкоуп работ, не работал сервер, не было подходящих тестовых данных и так далее;
краткий вывод по результатам тестирования (в зависимости от изначальной цели тестирования – например, можно ли передавать продукт заказчику для ознакомления).

Онлайн подготовка к тест-кейсам (ситуационным тестам):

Сегодня готовятся: чел.

Full (Все тесты сайта)

70%
Хит

207 тестов 3030 вопросов + 7 кейсов и 2 пособия

Личный кабинет

Моментальный доступ

Подробные решения

Графики результатов

1 месяц доступа

890 рублей

Подробнее

Сегодня готовятся: чел.

Ситуационные тесты «Сценарии»

6 тестов, 70 сценариев + пособие

Личный кабинет

Моментальный доступ

Подробные решения

Графики результатов

1 месяц доступа

340 рублей

Подробнее

Числовые тесты
30 тестов, 600 вопросов

340 рублей

Вербальные тесты
30 тестов, 450 вопросов

340 рублей

Логические тесты
22 теста, 220 вопросов

340 рублей

Индивидуальные кейсы
5 кейсов + анализ и рекомендации

340 рублей

Групповые кейсы
2 кейса + анализ и рекомендации

199 рублей

Тест-кейсы поощряют менеджмент на основании кейсов

Инструменты управления кейсами приглашают менеджеров руководить командой на основании (количества) тест-кейсов. Бывшая коллега рассказывала, что участвовала в проекте, где нужно было прогонять определенное количество кейсов в день. В итоге были придуманы условные кейсы. Если в ходе тестирования в голову приходила тест-идея, она вносилась в «условный» кейс. Если по количеству тестов в день был недобор, можно было прогнать несколько таких условных кейсов. Управление через тест-кейсы настолько же плохо, как плохо управление программистами через строчки кода или количество коммитов. Задача разработчика не в создании строчек кода – хоть они и будут способом достижения цели. То же самое касается тестировщика – их работа не в запуске тест-кейсов, а в предоставлении информации о продукте.

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

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

Что такое юзкейс?

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

  • Результат — пишется в заголовке юзкейса
  • Что является рассматриваемой системой
  • Участники взаимодействия (действующие лица: люди, внешние системы, кто основной участник?)
  • Последовательность действий
  • На каждом шаге: Кто? Что делает?
  • Что будет если что-то пойдет не так?

Установка курсов для пользователей QIWI КошелькаОсновной сценарий

  1. Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки).
  2. Директор казначейства получает сообщение по электронной почте о необходимости подтвердить заявку.
  3. Директор просматривает заявку и утверждает ее (см. форму утверждения).
  4. АБС сохраняет курсы для использования в QIWI Кошельке начиная с момента, указанного в заявке.
  5. Заинтересованные лица получают по электронной почте сообщение, в котором указаны новые курсы и дата/время их вступления в силу.

Отклонение заявки

  1. На шаге 3 директор отклоняет заявку.
  2. Трейдер получает сообщение по электронной почте об отклонении заявки.

Примеры оформления (несколько ожидаемых результатов)

Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).Когда говорят о нескольких ожидаемых результатах, это может означать:

  • Даны несколько вариантов вводимых данных и для каждого прописан свой ожидаемый результат.
  • Несколько шагов, а не только последний, содержат ожидаемый результат.
  • После одного сценария выполняются сразу несколько проверок.

Несколько вариантов вводимых данных

Тест-кейс № 2. Создание жильца, проверка поля «ФИО».

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, , пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Заполнить поле ФИО (см «Ожидаемый результат»)
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат

Вводимое значение Ожидаемый результат
Киселева Ольга Евгеньевна Ок, карточка сохраняется
<Оставить поле пустым> Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется
2*4*6*8*11*14*17*20*23*26*29*32*35*38*41*

Ошибка – «Максимальная длина поля – 40 символов, введено — 41», карточка не сохраняется. (Такую строчку легко сформировать с помощью инструмента perlclip)

&*%#(^$@*&; Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
Kiseleva Olga Evgenievna Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!

Результаты для нескольких шагов из кейса

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

Тест-кейс № 3. Создание жильца с худым полным ФИО.

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные».2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись «Здравствуйте, admin». Открыта главная страница сайта.4. Открылась страница «Создание нового жильца» с полями «Фамилия», «Имя» и «Отчество» и кнопкой «Сохранить».6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Несколько проверок после одного сценария

Тест-кейс № 4. Создание жильца с самым полным ФИО.

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, , пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.2. Эту карточку можно открыть.3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Области применения

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы».В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни «ДЕДЛАЙН!», только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:

  1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
  2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.

Тест-кейсы не нужны:

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

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

Example 1

It is very convenient in case when the tester needs to record great detail of each step. Well suited to the case when test cases are made for new testers. It will help them to cover product by quality tests and do not miss any important data.

Project Name: Banking System
Test Case
Test Case ID: BU_001 Test Designed by: <Name>
Test Priority (Low/Medium/High): Med Test Designed date: <Date>
Module Name: Bank login screen Test Executed by: <Name>
Test Title: Test the Login Functionality in Banking Test Execution date: <Date>
Description: Verify login with valid username and password
Pre-conditions: User has valid username and password

Dependencies:

Step Test Steps Test Data Expected Result Actual Result Status (Pass/Fail) Notes
1 Navigate to login page  

User should be able to login

User should is able to login Pass
2 Provide valid username User= Credential can be entered As Expected Pass
3 Provide valid password Password: 1234 Credential can be entered As Expected Pass
4 Click on Login button  User logged User logged successfully Pass
Post-conditions: User is validated with database and successfully login to the account. The account session details are logged in the database.

Пример API и тестовая матрица

Теперь мы можем отобразить все в виде матрицы и использовать ее для написания подробного плана тестирования (для автоматизации тестирования или ручных тестов).

Предположим, что подмножеством нашего API является конечная точка /users, которая включает следующие вызовы API:

Вызов API

Действие

GET /users

Просмотреть всех пользователей 

GET /users?name={username}

Получить пользователя по имени пользователя

GET /users/{id}

Получить пользователя по ID

GET /users/{id}/configurations

Получите все конфигурации для пользователя

POST /users/{id}/configurations

Создать новую конфигурацию для пользователя

DELETE /users/{id}/configurations/{id}

Удалить конфигурацию для пользователя

PATCH /users/{id}/configuration/{id}

Обновить конфигурацию для пользователя

Где {id} — это UUID, а все конечные точки GET позволяют фильтровать, сортировать, исключать и ограничивать дополнительные параметры запроса для фильтрации, сортировки и разбивки на страницы тела ответа.

Основные позитивные тесты (позитивный путь по умолчанию)Позитивные тесты + необязательные параметры проверокНегативное тестирование – валидный ввод данныхНегативное тестирование — неверные входные данныеДеструктивное тестирование

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

Выходим за рамки функционального тестирования

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

Уровни зрелости API

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

Безопасность и авторизация

  • Убедитесь, что API разработан в соответствии с правильными принципами безопасности: отказ по умолчанию, безопасное падение сервиса, принцип наименьших привилегий, отклонение всех невалидных данных в запросе и т. д.

    • Позитивные тесты: убедитесь, что API отвечает на правильную авторизацию всеми согласованными методами аутентификации — ответный токен auth 2.0, файлы cookie, дайджест и т. д. — как определено в вашей спецификации.

    • Негативные тесты: убедитесь, что API отклоняет все несанкционированные вызовы.

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

Проверка протокола: проверьте HTTP / HTTPS в соответствии со спецификацией

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

Политики ограничения скорости, троттлинга и политики контроля доступа

Нагрузочные тесты (позитивные), стресс-тесты (негативные)

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

API как соглашение — сначала проверьте спецификацию!

API — это, по сути, соглашение между клиентом и сервером или между двумя приложениями

Перед тем, как начать любое тестирование функциональности, важно убедиться в правильности соглашения. Это можно сделать сначала проверив спецификацию (или само соглашение службы, например, интерфейс Swagger или ссылку OpenAPI) и убедившись, что:

  • эндпоинты правильно именованы; 

  • ресурсы и их типы правильно отражают объектную модель;

  •  нет отсутствующей или дублирующей функциональности; 

  • отношения между ресурсами правильно отражаются в API.

Приведенные выше рекомендации применимы к любому API, но для простоты в этом посте мы предполагаем наиболее широко используемую архитектуру веб-API — REST через HTTP

Если ваш API спроектирован именно как RESTful API, важно убедиться, что контракт REST действителен, включая всю семантику, соглашения и принципы HTTP REST. (описание тут, тут, и здесь). 

Если у вас общедоступный API, ориентированный на клиента, такое тестирование может быть вашим последним шансом убедиться, что все требования соглашения выполнены. После публикации и использования API любые внесенные вами изменения могут внести ошибки в код клиента.(Конечно, когда-нибудь вы сможете опубликовать новую версию API (например, /api/v2 /), но даже в этом случае обратная совместимость скорее всего будет обязательной).

LEANTESTING

Итак, поиски инструмента продолжились. Следующим был вариант — https://leantesting.com/ (по сути это бесплатный аналог Test Rail, однако есть возможность приобрести расширенные возможности за дополнительную плату. Сейчас мы рассмотрим особенности бесплатной версии.
 

Пример тестового сценария в LeanTesting
 Преимущества:

  • неограниченное количество пользователей;
  • неограниченное количество проектов;
  • неограниченное количество тестов и тест сайклов;
  • удобные отчеты;
  • в новом обновлении Lean Testing может запускать автоматизированные тесты с Selenium.

Недостатки:

  • интеграция с другими вебхуками (например, Slack, GitGub, BitBucket ) платная;
  • настройка пользовательских статусов и типов ошибок также платная;
  • нет интеграции с какими-либо системами баг-трекеров (в нашем случае Jira);
  • скриншот можно прикрепить только к тест-кейсу в целом, но не к шагам;
  • нет возможности импортировать тест-кейсы из других Test Case Management Tools или Excel.

Изначально приняв решение о переходе на этот инструмент, мы видели одно большое преимущество — более удобный пользовательский интерфейс, чем в HipTest, но спустя год активного использования все-таки решили уйти от Lean Testing. Главной причиной для нас на тот момент стало отсутствие интеграции с Jira (на проекте мы активно ее используем для ведения всех задач и, конечно же, было бы удобно хранить все в одном месте) и возможность прикреплять скриншот только ко всему тест-кейсу, а не к каждому шагу. Также на тот момент в бесплатной версии было ограничено количество создаваемых кейсов. 
То есть изначально при выборе инструмента, мы не задумывались о таких вещах как интеграция с Jira, но впоследствии пришли к выводу, что это было бы очень удобно и полезно для тестирования и разработки. Мы не думали про то, что проект будет так стремительно расти, а с ним и количество наших тестов. Изначально мы просто хотели перенести документацию только для части функционала, а остальную оставить в Confluence. Но со временем, пощупав удобство пользования тест-кейсами в специальной системе их хранения, мы решили переносить туда и другие тесты. 

Что такое предварительные шаги тест-кейса

Шарлотка

Предварительные шаги

Сходить в магазин и купить:
  1. Яйца;
  2. Яблоки;
  3. Муку;
  4. Молоко;
  5. Сахар

Шаги

  1. Яйца взбить с сахаром (взбивать не менее 5–7 минут).
  2. Добавить муку, хорошо перемешать.
  3. Яблоки почистить, удалить сердцевину, нарезать небольшими дольками.
  4. Форму для выпечки смазать маслом.
  5. На тесто выложить половину яблок (яблоки можно посыпать корицей).
  6. На яблоки вылить половину оставшегося теста.
  7. На тесто выложить оставшиеся яблоки.
  8. На яблоки вылить оставшееся тесто.
  9. Поставить в разогретую до 180 градусов духовку.
  10. Выпекать в течение 40–60 минут (в зависимости от размера формы).

Ожидаемый результат

Вкусная шарлотка! Которую родные уминают за 5 минут.

Предварительные шаги

  1. Зарегистрироваться (см. тест-кейс «Регистрация»).
  2. Пополнить баланс (см. тест-кейс «Пополнение баланса»).
  3. Скачать файл-образец (см. тест-кейс «Скачивание файла-образца»)

Используйте кратчайший маршрут выполнения тест-кейса

Ведите тест кейс по максимально короткому пути. Что это значит?

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

Как ускорить работу автотеста? Задача ручного тестировщика продумать тест-кейс, найти кратчайший маршрут чтобы минимизировать все лишние действия автотеста.

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

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

Плюсы и минусы метода

Оценка персонала при помощи кейс-тестинга имеет ряд несомненных достоинств:

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

Главным недостатком кейс-тестинга является узость оцениваемого направления деятельности.

Примеры оформления (несколько ожидаемых результатов)

Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле «ФИО» по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).Когда говорят о нескольких ожидаемых результатах, это может означать:

  • Даны несколько вариантов вводимых данных и для каждого прописан свой ожидаемый результат.
  • Несколько шагов, а не только последний, содержат ожидаемый результат.
  • После одного сценария выполняются сразу несколько проверок.

Несколько вариантов вводимых данных

Тест-кейс № 2. Создание жильца, проверка поля «ФИО».

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, , пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Заполнить поле ФИО (см «Ожидаемый результат»)
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат

Вводимое значение Ожидаемый результат
Киселева Ольга Евгеньевна Ок, карточка сохраняется
<Оставить поле пустым> Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется
2*4*6*8*11*14*17*20*23*26*29*32*35*38*41*

Ошибка – «Максимальная длина поля – 40 символов, введено — 41», карточка не сохраняется. (Такую строчку легко сформировать с помощью инструмента perlclip)

&*%#(^$@*&; Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
Kiseleva Olga Evgenievna Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!

Результаты для нескольких шагов из кейса

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

Тест-кейс № 3. Создание жильца с худым полным ФИО.

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой «Войти» и сообщением «Для входа в систему введите, пожалуйста, свои данные».2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись «Здравствуйте, admin». Открыта главная страница сайта.4. Открылась страница «Создание нового жильца» с полями «Фамилия», «Имя» и «Отчество» и кнопкой «Сохранить».6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Несколько проверок после одного сценария

Тест-кейс № 4. Создание жильца с самым полным ФИО.

Шаги:

  1. Зайти на сайт www.dev_test.ru (логин — test, пароль — test).
  2. Войти под учеткой администратора (логин — admin, , пароль — 1)
  3. Перейти на вкладку «Жильцы»
  4. Нажать на кнопку «Создать карточку жильца».
  5. Ввести корректные ФИО, например, «Иванов Иван Иванович».
  6. Нажать на кнопку «Сохранить».

Ожидаемый результат1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.2. Эту карточку можно открыть.3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано «Иванов Иван Иванович».

Области применения

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию «чек-листы & тест-кейсы».В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни «ДЕДЛАЙН!», только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:

  1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
  2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.

Тест-кейсы не нужны:

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

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

Как насчет аудита?

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

Альтернатива

Но чем же пользоваться, если не инструментами управления кейсами? На самом деле это два вопроса – что документировать, и посредством какого инструмента это делать.

Для ответа на первый вопрос я предлагаю комбинацию двух вещей – моделей продукта и эвристик для тест-идей.

Модели могут принимать различные формы, воплощения и размеры: архитектурные диаграммы (известные как «прямоугольники и стрелочки»), диаграммы последовательностей, модель SFDIPOT, таблица ACC (Атрибут – компонент – способность)… Это может быть что-то поменьше и поконкретнее ,вроде списка разных типов пользователей – аноним, авторизованный, администратор компании, администратор платформы.

Ряд хороших эвристик для тест-идей можно найти в чит-листе Элизабет Хендриксон и книге Рикарда Эдгрена «Записная книжка тест-дизайнера». В идеале у вас должны быть эвристики для конкретно вашего продукта, основанные на опыте команды.

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

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

View the discussion thread.

blog comments powered by DISQUS

Определения из книг по тестированию

Ron Patton. Software Testing.

Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.

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

Lee Copeland. A Practitioner’s Guide to Software Test Design.

The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:

  • Test case specification identifier — A unique identifier so that this document can be distinguished from all other documents.
  • Test items — Identifies the items and features to be tested by this test case.
  • Input specifications — Specifies each input required by this test case.
  • Output specifications — Specifies each output expected after executing this test case.
  • Environmental needs — Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
  • Special procedural requirements — Defines any special setup, execution, or cleanup procedures unique to this test case.
  • Intercase dependencies — Lists any test cases that must be executed prior to this test case.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

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

Гленфорд Майерс, Искусство тестирования программ

Любой тест должен включать две составляющие:

  • описание входных данных программы;
  • точное описание корректных выходных данных для каждого набора входных данных.

На этом, пожалуй, все 

PS — Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!PPS — Уже скоро стартует мой курс Онлайн-интенсив для начинающих тестировщиков, в котором мы будем практиковаться составлять тест-кейсы, более полезные чек-листы и прочими полезными вещами! Записаться на курс 1-7 сентября.

Tags:

  • начинающему тестировщику
  • общие вопросы

View the discussion thread.

blog comments powered by DISQUS

Категории тестовых сценариев

Наши тест-кейсы делятся на следующие общие группы тестовых сценариев:

Основные позитивные тесты (прохождение успешного сценария по умолчанию)

Расширенное позитивное тестирование с дополнительными параметрами

Негативное тестирование с валидными входными данными

Негативное тестирование с недопустимыми входными данными

Деструктивное тестирование

Тесты безопасности, авторизации и доступности (которые выходят за рамки этой статьи)

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

Следующая группа тестов — это негативное тестирование, при котором мы ожидаем, что приложение будет корректно обрабатывать проблемные сценарии как с валидным вводом пользователя (например, попытка добавить существующее имя пользователя), так и с недопустимым вводом пользователя (попытка добавить имя пользователя, которое имеет значение null). 

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен иметь 3 части:

PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной
проверки. Либо список условий, выполнение которых говорит о том, что система находится в
пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на
основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста —
initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего —
правило хорошего тона: «намусорил — убери за собой». Это особенно актуально при автоматизированном
тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных
документов.

Пример тест кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

В приведенном примере конечная проверка — В3. Это значит, что именно она является ключевой. Значит, A1 и
А2 — это действия приводящие систему в тестопригодное состояние. А В1 и В2 — условия того, что система
находится в состоянии пригодном для тестирования. Таким образом имеем:

Action Expected Result Test Result (passed/failed/blocked)
PreConditions    
do A1 verify B1  
do A2 verify B2  
Test Case Description    
do A3 verify B3  
PostConditions    
     

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

Теперь ответим на вопрос: «Почему данное разбиение удобно использовать?»

Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно
из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test
blocked
), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние
пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Action Expected Result Test Result(passed/failed/blocked)
PreConditions    
do A1 verify B1 passed
do A2 verify B2 failed
Test Case Description:
do A3 verify B3 blocked
PostConditions    
     

What is a Test Case

Test case – is the smallest unit of the testing plan – which includes a description of necessary actions and parameters to achieve and verify the expected behaviour of a particular function or the part of the tested software.
If you have a task to check some functionality, you can create a test script or user story. So you need to understand where to start testing, which general steps need to be executed and what the result should be.
And then this scenario is broken down into more detailed parts – test cases – to define all positive, negative, localisation and other behaviours of the software.
For example, testers need to test the functionality of uploading photos.

Now, this scenario should be divided into detailed test cases, for example:

  • Check the logged user possibility to go to the “upload photos” page
  • Check the not logged user possibility to go to the “upload photos” page
  • Check whether the user can click “upload” button
  • Is it opens a form to select a photo and possibility to close it
  • What happens if you do not select photos, choose another file format (for example video), choose photos of a maximum size and so on
  • Check the possibility to upload photos
  • Check if photo is saved
  • Possibility to reload or delete photos
  • What happens with photos in the case of the disappearance of the Internet or the device is switched off
  • Are all buttons displayed correctly at another location or on different operating systems (if any difference)

And so on. The number of test cases depends on the experience and imagination of the tester.

Therefore, the process of writing test cases starts from forming a test scenario or user story, and then it can be divided to check different occasions.