Рутинное – тест кейсы

Рекомендации были написаны для внутреннего употребления и пришлось вырезать некоторые части и ссылки. Что то вообще не соответствует теории.

Общее

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

Объект – Действие – Результат

Объект – это всё что угодно: от расположения точек в картинке, до строк файлов, от кнопок до всей платформы целиком.
Действие – что мы делаем с объектом.
Результат – что получилось в результате действия с объектом.

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

Термины

В зависимости от продукта они разные, но это и понятно. Точное название зачастую могут дать разработчики, и если вы стопроцентно не уверены как правильно называется элемент – спросите девелопера, ткните девелопера, кусите девелопера, порвите его как грелку, но точное название должно быть.
Будьте внимательны и используйте правильно следующие термины «Panel» и «Form» (группировка и интерактивность), «Window» и «Dialog» (окно, контролируемое процессом и окно, желающее пользователя). Так же используйте правильно «left» и «right» (лево и право).
Не забывайте, так же что:

  • «button» нажимают: «press» или «push»;
  • «link» и большую часть элементов кликают: «click»;
  • «menu», «menu+tree+list+grid item» выбирают: «select»;
  • «check box» и «radio box» выделяют: «check» или «flag»;
  • текст вводят: «type» или «enter»;
  • информацию и объекты показывают: «show», «display», «pop-up» и иногда «appear» (когда хоба, его никто не ждал, а оно появилось);
  • последовательность существительных в английском переводится задом наперёд;
  • «number» – это и «integer» и «float» («real»);
  • «string» – это и буквы и «number»;
  • «number» может включать в себя буквы от «A» до «F» и «E», точки или запятые, как указатель дробной части;
  • «text» – это набор «string», обычно со смыслом.

Подходы к написанию тест кейсов.

  1. Прямое описание
  2. Описание на основе определений
  3. Группировка объектов по признаку
  4. Зацикливание тест кейса
  5. Ссылки на другие тест кейсы
  6. Alias
  7. Начальные и пост- условия

Частенько они переплетаются в одном тест кейсе.

Прямое описание

В двух словах – это то, что вижу, то и пишу. Удобно, когда сценарий простой, а объекты четко определимы. Если взять главную страницу Google.com (классическое представление), то там можно четко определить следующие элементы:

  • Логотип (image)
  • Поле ввода (input box, input field)
  • Две кнопки (button)
  • Группа из двух радио боксов (я не знаю, как правильно перевести radiobox на русский, никогда не задумывался).

Можно так же определить все ссылки, назвав их, но это будет неправильно, потому что они явно представлены в разных блоках и имеют косвенное отношение к главной функции – поиску, но об этом позже.
Имея эти элементы легко составить тест кейсы по проверке формы для поиска:
Step 1. Type “wiki test case” string into input box and press “Google Search” button
Result: New page will be opened in same window with list of sites
Step 2. Check that any word from search phrase present in any part of site representation (in title, description, URI or Sitelinks)
Result: Each site in search results list contains any or few words from search phase

Хозяйке на заметку: «Sitelinks» – это определение используется только в гугл (в контексте показа результатов поиска) и означает небольшой блок из 1 – 8 ссылок на внутренние ресурсы сайта. Причем будет или не будет показываться этот блок для сайта и какие ссылки он будет содержать решают только в Google. Впрочем, если у вас есть доступ в Webmaster Tolls, вы это уже знаете.

Нужно ли писать так много слов? Вовсе нет, можно вообще написать «Type “wiki test case” and press “Google Search” button» и «Verify that search result contains search phrase parts». Еще разок повторю, писать надо так, чтобы было понятно, что сделать, с чем сделать, и какой результат ожидать. А это значит, что использовать слова «corresponding, proper, respective» и прочие со смыслом «правильный» использовать нужно аккуратно. Например, фразы в «Expected Results»: «Respective blank appeared in the left frame» и «Check time» – ничего не значат, и писать надо, например, так «”Budviser Panel” loaded into left frame» и «Check that time format is “HH:MM:SS”, where HH – hours (24h или 12am/pm), MM – minutes, SS – seconds».
В общем и целом в прямом описании сценария нет ничего сложного или заумного, достаточно внимательно описать действия и объекты, при возможности строя новый шаг тест кейса на основе предыдущего, тогда простота описания «Expected result» получится сама собой.

Описание на основе определений

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

У определения есть имя и значения, описывается оно в комментариях тест кейса, например:

“Long Time” format is HH:MM:SS, where HH is hours from 0 to 23, MM are minutes 0-59, SS are seconds 0-59.

После чего «Long Time» можно использовать в тексте тест кейса вместо полного описания.

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

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

Группировка объектов по признаку

Это опять-таки имеет отношение к проверке однотипных объектов и упрощению тест кейсов. В данном случае в одном шаге тест кейса объединяется проверка сразу нескольких объектов. Классическое тестирование это развлечение не приветствует, но мне всё равно. При таком подходе пишется следущее:

Step 1: Check property ‘x’ of objects: a) ‘Object a’ b) Object ‘b’ c) Object ‘c’
Expected Result: property ‘x’ is in format of (has value of)

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

Зацикливание тест кейса

Это миф. Тест кейс зацикливать нельзя. То есть писать «Repeat steps 1-3» не стоит. А собственно почему? Только потому, что это прерывает последовательность шагов? Вот фигня то. Тест кейс – это обычный сценарий действий, и если действительно нужно повторить шаг с первого по третий, то почему бы не повторить? Но вот если шаг 1-3 говорит о том, что действие надо сделать с объектом «А», а нужно повторить эти шаги для объекта «Б», тогда придется писать эти шаги снова, но уже для объекта «Б». Так же придется делать, если количество шагов больше семи (магическая цифра, найденная психологами или психиатрами).

Ссылки на другие тест кейсы

Допускаются только в комментариях. Нельзя написать пройдите тест кейс «TC-1» ни в шагах, ни в начальных или пост- условиях. Потому что тест кейс – самостоятельный сценарий и для его выполнения не требуются другие тест кейсы.

Alias

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

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

Поэтому в тест кейсах в начальных условиях можно просто написать «User must be logged in», «User must be authorized», «User logged into [] under [] role». Понятно ли что нужно сделать перед тем, как начать работу с тесткейсом? Единственное «но», алиас всё равно должен быть описан где-либо в доступном месте (FAQ к проекту вполне подойдет).

Начальные и пост- условия

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

Хозяйке на заметку: http://blog.abakas.com/2009/02/look-even-when-you-know.html
Это только начало…

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *