Тестирование обеспечения качества доведено до совершенства — руководство пользователя

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

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

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

Традиционное QA-тестирование соответствует пользовательскому потоку

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

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

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

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

Плыть по течению

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

Сначала нам понадобится бесплатный инструмент для составления карт разума. Я лично использую XMind. Не стесняйтесь загружать любой инструмент, который вам удобен — мы будем использовать только основные функции, такие как рисование блок-схемы, добавление «примечаний» к некоторым темам, раскрашивание различных условий и использование меток.

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

Условия, состояния, действия

Мы ограничиваем наш поток, используя только трех актеров. У вас будет Condition , который подобен пользователю с определенной ролью, очищенному кешу или входу пользователя в первый раз. Во-вторых, у нас есть State/Page , который является фактическим компонентом графического интерфейса, таким как домашняя страница или окно входа. Затем следует действие , которое представляет собой физическое взаимодействие с пользователем, вызывающее изменение состояния. Давайте посмотрим на это в действии.

Анализ требований

Это наша домашняя страница, которая является государством. У нас есть два возможных Действия: Зарегистрироваться и Войти.

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

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

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

1. Домашняя страница
2. Окно входа
3. Окно регистрации
4. Панель приборов

Мы записываем наши действия на каждой странице/состоянии, с которыми можно «взаимодействовать»:

1. Домашняя страница
   1. Авторизоваться
   2. регистр
2. Окно входа
   1. Войти
   2. Отмена
3. Окно регистрации
   1. TBD (зависит от продукта)
4. Панель приборов
   1. Создавать
   2. Редактировать
   3. Удалить

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

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

Составление блок-схемы

Мы рисуем вышеизложенное в XMind, чтобы оно выглядело так:

Вы заметите, что я просто выделяю цветом состояние и действие. Я также добавил строку из действия «Отмена» на главную страницу, чтобы точно представить этот процесс. Мы также видим два условия, когда пользователь выбирает «Войти». Хотя оба они относятся к приборной панели, мы все же хотим протестировать оба возможных условия.

Хорошая вещь с XMind заключается в том, что если мы работаем над большим сложным приложением, мы можем создавать разные уровни диаграммы, поэтому, если вы хотите разбить поток на несколько потоков, но сохранить их связанными, это очень легко сделать с помощью связывания темы на отдельных листах. Вы можете вставить гиперссылку, а во всплывающем окне мастера вы можете выбрать «Состояние», к которому ведет действие. Это означает, что если вы выберете «Войти» в XMind, и он перейдет по гиперссылке на «Панель инструментов», курсор мыши переместится на «Панель мониторинга», даже если он находится на другом листе. Довольно круто.

Чего не хватает нашему потоку, так это меток. Мы даем продукту метку 0, так как это корень потока. Затем для каждого состояния (синего цвета) мы добавляем метку S#, для каждого действия (зеленого цвета) мы добавляем метку A# и, наконец, для каждого состояния (голубого цвета) мы добавляем метку C#. Каждая метка должна быть уникальной. В итоге получаем следующее:

Чтобы отследить, какое число вы использовали в последний раз — поскольку по мере роста продукта поиск максимального числа может быть сложной задачей — я сохраняю это в корневой теме потока, как показано ниже:

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

Затем окно входа:

Затем действие входа:

Он действительно обретает форму. Обратите внимание на добавленные тесты границ и безопасности. Вы можете назвать это так, как вам нравится, в зависимости от того, что вам проще всего пометить. Иногда я помечаю заголовок типом теста, например «Безопасность» — «JS Inject» — «Поле электронной почты», а затем перечисляю ожидаемые результаты ниже.

В большинстве команд нам трудно поддерживать изменение требований. Больше не надо. Допустим, мы только что узнали, что всем новым пользователям должно быть представлено окно Ts и Cs, и они должны принять его, прежде чем перейти к своей информационной панели — нет проблем. Мы можем относительно легко добавить состояние и действия, как показано ниже:

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

Создание тестовых случаев из потока

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

Все, что мы делаем сейчас, — это копируем и вставляем то, что есть в нашем потоке, в любой инструмент управления тестовыми примерами, на сайт Confluence или в документ Excel, который вы пожелаете. Я до сих пор пользуюсь старым добрым верным Excel. Я храню записи всех своих тестовых случаев в одном файле под названием «Базовый уровень» — очень оригинально. После того, как я закончу копирование-вставку, я получаю следующее:

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

Есть несколько моментов, на которые стоит обратить внимание. Во-первых, я объединил ячейки с одной и той же информацией — нет необходимости многократно копировать и вставлять, это тратит время и сложнее в обслуживании. Еще один пункт — Шаги. Вы заметите, что в двух тестах есть шаги, которые включают номера состояний и действий. Это можно использовать, если у вас есть поток как часть SDLC в вашей команде. Затем все заинтересованные стороны вносят свой вклад в поток, предоставляя информацию, макеты, повышая риски и т. д. Это означает, что, указав цифры потока, любой в команде будет знать, что делать, а если появится новый член команды, это так же просто. как «следуйте по следу, ссылайтесь на заметки».

Это также помогает автоматизации. Вы можете дать каждому шагу или действию уникальную ссылку. Создав пакет автоматизации, который структурирован как ваш поток, вы обнаружите, что структура автоматизации, которую вы можете создать, может быть очень надежной, модульной и совместимой во всем приложении. Объекты подкачки будут использоваться в большем масштабе, что сократит время обслуживания и позволит заменить тестовые функции новыми.

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

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

Так что насчет тестовых планов?, должно быть, вы думаете. Это просто. План тестирования содержит такие разделы, как:

1. Введение и сфера применения
2. Тестовые задания
3. Возможности для тестирования
4. Функции, которые нельзя тестировать
5. Предположения
6. Критерии входа
7. Критерии выхода
8. WBS
9. Риски
10. Требования к окружающей среде

Введение и объем будут историей JIRA или любой задачей или историей в другом инструменте. Элементы теста — это просто версии программного обеспечения или номера коммитов, развернутых в настоящее время в вашей среде, которые вы можете связать с билетом JIRA или во время выполнения теста либо в Confluence, либо в инструменте управления тестированием.

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

Предположения, риски и даже требования к среде можно скомпилировать в документе или добавить в комментарии в JIRA, иногда даже разместить в Confluence и связать с историей.

WBS — это оценка, которую вы назначаете истории в баллах или часах, в зависимости от вашего проекта. Критерии входа и выхода уже будут частью истории.

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

Чему мы научились?

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

Этот подход помог мне оставаться организованным, охватывать все основы и создавать документацию, понятную всей команде. В Agile это действительно пригодится, и самое приятное в этом то, что мы по-прежнему придерживаемся одного из Agile-подходов: «Упростите документацию».

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