Перейти к содержимому

Автоматизатор мобильных приложений
онлайн, начало 19 мая
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 18 мая
SQL для тестировщиков
онлайн, начало 17 мая
Английский для тестировщиков
онлайн, начало 17 мая
Фотография

Тестирование программного обеспечения. Базовый курс


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 20

#21 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 10 декабря 2015 - 14:46

Артём,
 

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


Пусть и не совсем такая конкретная ситуация, но предпосылки к подобному и пути решения даже описаны в книге (см. "Подробная классификация наборов тест-кейсов", начиная со 139-й страницы). Это можно сделать через т.н. "обобщённый свободный набор", указав для всех тестов в наборе некий эталонный/базовый перечень входных параметров, а уже в каждом тесте разместить "патч" этого набора, приводящий к нужному итоговому результату.
Что до пункта "б" вашего вопроса, то это вечный вопрос и вечная боль. Но тоже решаемо, если знать количественные и качественные изменения -- от подготовки избыточных наборов входных данных (покрывающих все варианты), до элементов исследовательского тестирования в рамках сценариев (как завещал Виттакер).
 

Как я рекомендую поступать:
В одном тесте полностью расписать проверку блока (значения всех полей, редактируемость, обязательность, форматы и т.д.) а в остальных просто ссылаться на этот тест для проверки данного блока, при этом указывая отличия при необходимости.
Этим мы существенно экономим время на обновление всех X тестов при изменении требований к блоку.


А зачем нам в остальных тестах проверка этого блока, если мы его уже проверили одним тестом?
Тут ведь одно из трёх:
а) Если нам надо В ТОЧНОСТИ выполнить некие действия для нескольких тестов -- делаем набор, выносим эти действия в его пригтовления.
б) Если нам надо "примерно" выполнить некие действия (не важно, как именно, но в стиле "указать верные ФИО") -- снова делаем набор, выносим это в общие приготовления и подчёркиваем, что тут нужна вариативность.
в) Если нам надо выполнить некие специфичные для каждого теста действия, от которых зависят дальнейшее развитие теста и его результат -- тут я бы не ленился и писал в каждом тесте заново (да, даже богомерзким копи-пейстом и правками). Если подавляющий набор шагов/данных одинаков, а дьявол кроется в деталях -- см. выше про единые набор + "патчи".

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

2. В блоке 'Исходные данные' (стр. 122) вы настоятельно не рекомендуете описывать действия по подготовке, которые выполняются в  самом тестируемом приложении.
a) Пример 1: Как тогда вы будете проверять таблицу на отображение только 10 первых строк (если её наполнение происходит средствами приложения): первые шаги теста будут заключаться в наполнении таблицы данными, а не в непосредственном тестировании требования ?


Персонально я вообще бы напрямую через СУБД накидал в БД то, что мне нужно :). Особенно, если строк не 10, а 10 миллионов.
Но если это невозможно или нежелательно, то:
а) Набор из последовательных тестов.
б) Формулировка приготовления в виде предусловия: "В БД в таблице такой-то должно быть столько-то строк". Тесту ставить "невозможно выполнить", если добавить строки не удалось. Но сам тест, если он направлен на отображение, фейлить из-за невозможности вставки... как-то... не по фен-шую.
в) Если цель теста -- "запихнуть N >> 10 и убедиться, что отображается только 10", да, в шагах теста указал бы добавление. Если бы не добавлялось, зафейлил бы тест с чистой совестью.
 

б) Пример 2: Есть некоторый длинный бизнес процесс и у нас в конце есть форма, которую нам надо проверить. И есть сквозной смоук тест, проходящий по данному процессу.


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

Как я рекомендую поступать: в Preconditons делать ссылку на Smoke (т.к. не факт что каждый из тестировщиков, а тем более новичков понимает как дойти до нужного шага) и указывать шаг процесса, который нам нужен для проверки.


И вот однажды тёмной-тёмной ночью кто-то что-то меняет/добавляет/удаляет в "объекте, на который мы сослались" так, что у него всё логично и работает, а у нас получается бред. Что делать тогда?

P.S. Ещё раз суть: если у нас есть гарантия, что без ведома и позволения "ссылающейся части" никто не поменяет ничего в "части, на которую ссылаются" -- в путь и с песней. Но если такой гарантии нет, я бы предпочёл не создавать хитросплетение из перекрёстных ссылок. Т.е. запретить ссылки вообще. Ниче они начинают плодиться как кролики, и через какое-то время получаем "спагетти-тесты", если можно так сказать по аналогии со спагетти-кодом.
  • 0


Первый Онлайн ИНститут Тестировщиков
онлайн
Школа для начинающих тестировщиков
онлайн
Логи как инструмент тестировщика
онлайн
Selenium 2.0: стартовый уровень
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале