Атомарность в тестировании для новичков

(Время чтения — 6 минут)

Привет всем читателям этой статьи! Меня зовут Кирилл. Я помогаю в обучении студентов тестированию, а так же веду свой телеграм-канал @aboutqa (можете подписаться, если интересно). Через меня проходит много новичков в IT, желающих познать тайны этой профессии — профессии QA специалиста. И я заметил, что они часто путаются в понимании принципа тест-дизайна — атомарности тестов. Того, что матёрые тестировщики называют: "Один тест — одна проверка".

Опытным тестировщикам эта статья может не зайти, поэтому не удивляйтесь, что для вас тут кругом будут капитаны Очевидность. Поверьте моему педагогическому опыту — новичкам это вообще не очевидно!

Итак. Откуда вообще ноги растут?

Давайте ответим на следующие вопросы:

Ради чего вообще придумали тест-дизайн? Какие цели мы преследуем? И почему многие называют тест-дизайн важнейшим навыком тестировщика?

Задачи тест-дизайна:

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

При написании тест-кейсов надо учитывать цель написания этих самых кейсов (спасибо кэп). Ответьте для себя на следующие вопросы.

Почему именно кейсы, а не чек-лист? Потому что заказчик требует, чтобы на проекте были кейсы; потому что кейсы будут выполнять роль отсутствующей/неполной документации; потому что проходить кейсы будут неопытные студенты и т.п.

Что вам в итоге этими кейсами надо проверить? Функциональность, логику, "формочки", интеграционные проверки или все вместе.

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

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

Какая область деятельности компании и цена ошибки? Если вы делаете приложение для общения, обмена фоточек с котиками и монетизируетесь за счет рекламы — это одно; а если вы работаете в медицине, банковской сфере или тяжелой промышленности — это совершенно другое.

Как я уже говорил в превью, обывательским языком атомарность, это принцип "Один тест - одна проверка". Но зачем вообще придумали атомарность тестов? Можно же просто всё проверить разом, одним тестом, и никаких проблем.

Как это ни парадоксально, но атомарные проверки (одна из техник тест-дизайна) позволяет уменьшить кол-во тестов.

Атомарное условие — это такое условие, которое нельзя более декомпозировать на более мелкие условия. И хотя умение декомпозировать функциональность и условия работы ПО — это практически предмет целого небольшого семинара, тем не менее основная суть вот в чем. Попробую объяснить на примере.

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

Первым делом мы проверим положительный и самый близкий к жизни вариант.

Иван Иванов 12.10.1988 +79123456789, который покажет нам принципиальную работоспособность программы. Дальше мы будем менять одно поле, оставляя другие принципиально правильными.

Зачем это сделано? Всё просто — это элементарная локализация. Похоже на то, как мы исследуем потенциальный дефект, только превентивно. В примере выше мы получили 5 проверок (1 супер-позитивная и 4 вариации по числу параметров).

Мы могли бы сделать два теста:

Но тогда, в случае если второй тест упадёт — мы так и не поймем какое именно поле вызвало ошибку. На самом деле кол-во тестов значительно больше за счет вариативности самих параметров. Например "имя" и "фамилия" надо протестировать на пустое значение, спецсимволы, чувствительность к регистру и прочему. Телефон и дата рождения имеют свой специфичный набор классических негативных проверок. Так что тестов получается очень дофига (для нашего примера ~720).

Зачем нужна атомарность проверок, думаю понятно. Отсюда же и понятно, почему каждый уважающий себя наставник, тренер и просто руководитель тестирования «кричит» о том, что тесты должны быть атомарны. Но проблема вот в чем. Я начал с того, что многие начинающие тестировщики (кандидаты в джуны) путают смысл атомарности с... (не знаю с чем) с желанием сделать как можно больше тестов. Давайте снова вернемся к нашему примеру.

Мы обсудили только входные данные. Но как правило тестирование подразумевает сравнение фактического результата (ФР) с ожидаемым результатом (ОР). Вот ввели мы в нашу форму тестовые данные. А дальше что? Дальше, допустим, нам нужно зайти в систему, проверить, что создался новый клиент. Затем зайти в карточку клиента и посмотреть там в пяти местах. Потом мы идём в смежную систему и проверяем, как данные осели в базе данных. Может еще дёргаем какую-нибудь API между делом. И вот многие (я сейчас на полном серьезе, не кидайте в меня помидорами) создают 6+ тестов, которые делают одно и то же (то есть сценарий тестирования-то один), но "проверки", то есть валидация результатов разная. И вот у нас и так было ~720 тестов из-за комбинаторики и атомарности, теперь их стало в 6 раз больше.

Какой вывод можно вывести из этого? Атомарность тестов — это про проверку условий. Про декомпозицию и перебор входных воздействий. Но ни в коем случае не про результат.

Ну…

В жизни многие на это забивают.

Начну с того, что, конечно, 720 ручных тестов одной формочки редко кто делает. Решают проблему методикой Pairwise (алгоритм all pairs) и вместо 720 тестов вот у нас уже всего 36 (да, эта черная магия работает именно так). В интернете много интересных видео про pairwise, не буду останавливаться на этом.

Даже имея 36 тестов просто на форму, жизнь вносит немного коррективов. Вот, например, надо вам проверить функционал покупки в онлайн-магазине. Он состоит из нескольких крупных шагов: добавлении в корзину товара, логина в систему, оформления покупки.

По идее, если тест не пройдет — нам будет трудно понять в чем причина: у нас добавление товара не работает, логин или оформление покупки (собственно то, что мы проверяем). Логично создать отдельный тест на логин. Убедиться, что логин работает. Потом на работу с корзиной (добавление, удаление), а потом оформление покупки.

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

Как-то уж очень жестоко получается, да? 100500 проверок для какого-то кусочка функционала.Только представьте: 36 тестов на логин, 15 тестов на корзину и еще 50 на оформление товара. Может ну их атомарные проверки?

И да, иногда "ну их" — это рабочая стратегия.

Если скорость важнее качества, то многие проверки объединяют. Обычно так делают, когда проект уже устоявшийся, всё проверено было раз 100 и вероятно 101й прогон атомарных тестов не выявит проблем. Тогда негативные проверки объединяют. И вот если уже какая-то комбо-проверка вызовет ошибку — начнут разворачивать этот "тест" в последовательность атомарных тестов.

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

Более того, генерация тестовых данных скриптом - это простая задача для автоматизатора, а 720 тестов, хоть и проходятся дольше 36ти тестов в 20 раз, но скорее всего мы говорим о 1,5 минутах вместо 4,5 секунд. Разница заметная, но согласитесь, можно и подождать полторы минуты ради 100% покрытия.

Затронув тему автоматизации мы подходим к еще одному боевому рубежу. Он называется "Один тест — один assert". То есть переводя на язык ручного тестировщика — "Один тест — один ожидаемый результат".

Но я же выше говорил, что плохо повторять одни и те же тесты, если можно выполнить один сценарий и в рамках его проверить в 5 местах данные. А тут получается, что нужно работать не так? Не совсем. Смотрите, многие раздвигают понятие атомарности ручного тестирования в автоматизации до трёх условий:

1. один тест — одна логическая проверка

2. работа тестов не зависит от порядка их запуска

3. до начала и после завершения теста система находиться в одинаковом состоянии

Это правило связано с особенностями прохождения тестов программой. Если программа выявляет ошибку на первом из 5 ассертов (то есть сравнений ОР и ФР), то 4 других проверены не будут и возможные баги будут скрыты. Это основная проблема автоматизации. Однако я всё равно придерживаюсь мнения о том, что лучше в один сценарий (тест-кейс) добавить несколько проверок-сравнений, чем гонять однотипные тесты для разных проверок.

Тест-дизайн, крайне сложный в использовании инструмент тестировщика. И чем больше "степеней свободы" в проекте - тем хитрее и опытнее надо быть тестировщику, чтобы его использовать.

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

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

Как обычно. Хотел вбросить немножко про то, что атомарность, это не дробление тестов по принципу «чем больше, тем лучше», а в итоге написал целый трактат.

Ну что поделать.

Спасибо за уделенное мне время.