Записки тестировщика: как написать хороший сценарный тест на основе требований

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

В статье будем отталкиваться от функционального тестирования методом черного ящика.

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

Итак, начнем!

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

• Не нужно покрывать больше, чем написано в требовании (и, конечно же, меньше). Имеются в виду те случаи, когда какой-либо объект в одном требовании задействован косвенно, а в другом - напрямую.

  

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

  О полноте покрытия поговорим далее, когда доберемся до примеров.

• Старайтесь не перегружать название теста. Оно должно кратко передавать суть того, что будет проверяться.

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

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

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

• Обращайтесь к формальным техникам тестирования. Они помогут быть уверенным в полноте покрытия требования.

Что ж, давайте перейдем к примерам требований и разберем, как их можно полноценно покрыть

Требование 1

Центральная мониторная станция должна позволять пользователю редактировать Имя пациента для прикроватных мониторов любой комбинацией от 0 до 25 символов с клавиатуры, если:

• на центральной мониторной станции включена настройка для редактирования данных у мониторов пациентов

• на прикроватном мониторе включена настройка для редактирования данных с удаленных устройств

Так как требование специфичное, объясню пару моментов:

1. Прикроватные мониторы (или мониторы пациентов) – устройства, отображающие различные параметры и сигналы с пациентов (ЭКГ, давление и т.д.)

   

2. Центральная мониторная станция – устройство на посту медсестры, на которое можно назначить прикроватные мониторы и наблюдать одновременно за всеми пациентами.

Что ж, переходим к делу!

Требование гласит, что мы сможем сменить имя пациента у кровати на центральной станции, если будут выполнены 2 условия – включена настройка на центральной станции (настройка для редактирования данных у мониторов пациентов) и включена другая настройка на прикроватном мониторе (настройка для редактирования данных с удаленных устройств).

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

Для грамотной проверки в данном случае нужно сделать следующее, воспользовавшись таблицей принятия решений:

• Отключить обе настройки и проверить, что имя ввести нельзя

• Включить первую настройку и проверить, что имя ввести нельзя

• Отключить первую настройку, включить вторую настройку и проверить, что имя ввести нельзя

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

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

Для полной проверки ввода символов для имени пациента сделаем следующее, воспользовавшись граничными и эквивалентными значениями:

• Оставим поле с именем пустым (0 символов) – верное граничное значение, имя введено

• Введем 1 символ – верное граничное значение, имя введено

• Введем 24 символа – верное граничное значение, имя введено

• Введем 25 символов – верное граничное значение, имя введено

• Попытаемся ввести 26 символов – неверное граничное значение, имя не введено

• Введем имя пациента с любым числом символов из представленного диапазона – считаем, что любое количество символов (не включая граничное) эквивалентно, и нам будет достаточно проверить 1 любой вариант – имя введено.

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

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

Давайте составим тест скрипт с учетом того, что в предусловиях мы указали следующее:

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

• Отключите на центральной мониторной станции настройку для редактирования данных у мониторов пациентов

• Убедитесь, что на прикроватном мониторе имя пациента пустое

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

Рассмотрим еще один пример требования.

Требование 2

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

• пароль введен или пароль выключен

• пользователь подтверждает изменения

И привязанное к нему более низкоуровневое требование:

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

Начнем с объяснения некоторых моментов:

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

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

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

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

Включаем настройку и сохраняем изменения – проверяем, что настройка включена.

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

Затем отключаем настройку и сохраняем – проверяем, что настройку можно выключить.

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

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

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

После этого включаем настройку с сохранением изменений – убеждаемся, что настройка включена.

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

Затем выключаем ее с сохранением изменений – убеждаемся, что настройка выключена.

Теперь требование покрыто со всех сторон. Осталась проверка привязанного требования.

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

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

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

Как и с предыдущим требованием, составим тест скрипт:

И вновь получаем тест с целиком и полностью покрытым требованием.

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