Атомарные проверки

Привет, народ! В эфире #радиоСаня и сегодня мы поговорим с вами про атомарные проверки.

Но для начала давайте вспомним про цели тест-дизайна, их всего две:

1. Надизайнить (написать) тесты, которые обнаружат самые серьезные (критичные) ошибки продукта.
2. Уменьшить число тестов, необходимых для нахождения большинства серьезных ошибок.

Вы думаете, что тестов много не бывает? Еще как бывает. Бывает столько, что вы не успеваете их пройти.

То есть, наша с вами задача — написать как можно меньше лучших тестов, которые бы ловили как можно больше серьезных ошибок.  Ага, а причем тут “атомарки”?

“Атомарки” или атомарные проверки — это одна из техник тест-дизайна.  Она (техника)  позволяет делать тесты умными, уменьшая их количество. Атомарное условие — такое условие, над которым невозможно провести дальнейшую декомпозицию (кстати про декомпозицию прикольно рассказывает Нина в своем третьем вебинаре на курсе ПОИНТ. Например, условие, которое не содержит два или более одинарных условия, соединенных логическим оператором (И, ИЛИ, Исключающее ИЛИ).

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

Давайте возьмем чего-нибудь  для примера. Ну, скажем, какой-нибудь загрузчик фотографий.

Что нам важно выписать? Действия продукта, параметры их действий и значения параметров.

И давайте работать с действием “загружает фотографии” и его параметрами и значениями.  Получается, у нас три параметра и восемь значений, отменно.

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

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

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

Кстати, общее количество атомарных тестов считается по формуле: сумма значений минус количество параметров. Значений — восемь, параметров — три, в итоге — пять проверок. Особняком стоит наш “нулевой” тест, которым мы проверяем работоспособность тестируемой функциональности.

“Атомарки” — весьма удобная техника, чтобы тестировать нестабильные “сырые” продукты, потому что все причины ошибок мы видим сразу же.

Если ваш тестируемый продукт более зрелый, используйте деревья решений, S&T — based testing (тестирование на основании состояний и переходов)  или pairwise. Но это уже совсем другая история, а пока хочу поделиться с вами одним лайфхаком…))

Лайфхак, котаны! В нашем разобранном примере все очень просто: и параметров мало, и их значений не много, но что делать, если у вас 15, 20 или 30 значений? Не паникуйте, также формируйте табличку, также выписывайте “нулевой тест”, а потом составляйте наборы, сначала перебирая все значения первого параметра, затем — все значения второго параметра и так далее. Таким образом, вам не придется “скакать” глазами по лесенкам таблицы и бояться, что вы что-то да пропустили.

Статья написана в соавторстве с Агеевой Ниной.

Легких вам релизов!


Метки
#Тестирование ПО (3)Android (1)Cache (1)Cookie (1)courses (1)css (1)HR (1)iOS (2)istqb (1)ISTQB FL (1)IT (2)java (1)Jedi Point (12)JSON (1)kaizen (2)pairwise (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAPUI (1)SOAP UI (1)softskills (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)web (1)XML (1)xpath (1)Анна Палей (1)БАГИ (1)Исследовательское тестирование (2)Истории поинт (10)История успеха (1)Команда разработки (1)Курс тестирования для начинающих (1)Кэш (1)Лаборатория Качества (1)Мнемоники (1)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)ПОИНТ (44)ПРомо-вебинар (1)Подготовка к istqb (1)Роман Буданов (3)Сессионное тестирование (1)Скриншот (3)ТЗ (1)Таблица решений (1)Тестирование (27)Тестирование ПО (4)Тест менеджмент (2)Тренер (12)Туры (1)автоматизация (2)автотесты (1)алгоритмы (1)баг (1)багнапродакшене (1)безопасность (1)бесплатный вебинар (1)введение в тестирование (1)граничные значения (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (10)как надо тестировать (2)комбинаторика (1)конференция (2)котик (1)курс для начинающих тестировщиков онлайн (1)лайфхак (1)минутка юмора (1)мобилки (3)мобильное тестирование (4)настройка мозгов (1)начать карьеру (1)начать карьеру в IT (1)начинающий тестировщик (8)негативное тестирование (2)обучение (1)обучение тестированию (11)ограничения (1)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)разработчик (1)режим разработчика (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)смена работы (1)сопроводительное письмо (1)стать тестировщиком (1)стратегия (1)с чего начать (1)тайм-менеджмент (1)тест-анализ (1)тест-кейс (1)тест дизайн (3)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование веб (2)тестирование игр (3)тестирование мобильных приложений (1)тестировщик (5)тесткейс (1)удаленная работа (1)улучшайзинг (1)ученик (2)фреймворки (1)чеклист (4)чит-листы (1)чит лист (2)что должен делать тестировщик (1)ятренерпоинт (1)
С 24.08 по 10.11, ОНЛАЙН Зарегистрироваться