Атомарные проверки
Привет, народ! В эфире #радиоСаня и сегодня мы поговорим с вами про атомарные проверки.
Но для начала давайте вспомним про цели тест-дизайна, их всего две:
1. Надизайнить (написать) тесты, которые обнаружат самые серьезные (критичные) ошибки продукта.
2. Уменьшить число тестов, необходимых для нахождения большинства серьезных ошибок.
Вы думаете, что тестов много не бывает? Еще как бывает. Бывает столько, что вы не успеваете их пройти.
То есть, наша с вами задача — написать как можно меньше лучших тестов, которые бы ловили как можно больше серьезных ошибок. Ага, а причем тут “атомарки”?
“Атомарки” или атомарные проверки — это одна из техник тест-дизайна. Она (техника) позволяет делать тесты умными, уменьшая их количество. Атомарное условие — такое условие, над которым невозможно провести дальнейшую декомпозицию (кстати про декомпозицию прикольно рассказывает Нина в своем третьем вебинаре на курсе ПОИНТ. Например, условие, которое не содержит два или более одинарных условия, соединенных логическим оператором (И, ИЛИ, Исключающее ИЛИ).
Как это работает?
— выписываем действия, их параметры и значения (со значениями очень хорошо помогают техники классов эквивалентности и граничных значений);
— не забывайте, что для каждого действия будет свой отдельный “тестовый набор” с параметрами и значениями;
— собираем все выписанное в табличку для наглядности.
Давайте возьмем чего-нибудь для примера. Ну, скажем, какой-нибудь загрузчик фотографий.
Что нам важно выписать? Действия продукта, параметры их действий и значения параметров.
И давайте работать с действием “загружает фотографии” и его параметрами и значениями. Получается, у нас три параметра и восемь значений, отменно.
Собираем таблицу, сначала выписывая самый рабочий, самый стандартный или часто используемый набор значений, приближенный к нашей жизни, посмотрите на нулевую строку в табличке.
И если эта проверка с этим тестовым набором не работает, то, котаны, алес, надизайнились, у нас какая-то очень серьезная ошибка и дальнейшее тестирование этого функционала даже проводить бессмысленно. А если работает, то продолжаем создавать следующий набор, меняя ОДНО значение одного параметра! Посмотрите на первую строку в таблице, затем — на вторую и третью, чувствуете нашу любовь разницу?
Если “нулевой” и первые два теста прошли успешно, а третий зафейлился, вы сразу поймете, в чем ошибка, потому что третий тест относительно четвертого изменился ровно на одно значение. Элементарнейшая локализация, котаны.
Кстати, общее количество атомарных тестов считается по формуле: сумма значений минус количество параметров. Значений — восемь, параметров — три, в итоге — пять проверок. Особняком стоит наш “нулевой” тест, которым мы проверяем работоспособность тестируемой функциональности.
“Атомарки” — весьма удобная техника, чтобы тестировать нестабильные “сырые” продукты, потому что все причины ошибок мы видим сразу же.
Если ваш тестируемый продукт более зрелый, используйте деревья решений, S&T — based testing (тестирование на основании состояний и переходов) или pairwise. Но это уже совсем другая история, а пока хочу поделиться с вами одним лайфхаком…))
Лайфхак, котаны! В нашем разобранном примере все очень просто: и параметров мало, и их значений не много, но что делать, если у вас 15, 20 или 30 значений? Не паникуйте, также формируйте табличку, также выписывайте “нулевой тест”, а потом составляйте наборы, сначала перебирая все значения первого параметра, затем — все значения второго параметра и так далее. Таким образом, вам не придется “скакать” глазами по лесенкам таблицы и бояться, что вы что-то да пропустили.
Статья написана в соавторстве с Агеевой Ниной.
Легких вам релизов!