Создавать высокоэффективные тестовые сценарии достаточно сложно. Неясные, медленные и неустойчивые тесты крайне бесполезны и от них всегда можно ожидать больше негативных результатов, чем позитивных.
Чтобы понять, подходят ли используемые вами тесты под категорию высокоэффективных, постарайтесь подогнать создаваемые вами проверки под 7 проверенных постулатов эффективности тестов.Далее мы поговорим о них более детально.
Правило №1: тесты должны быть внятными
По своей технической сути, тест — это определенный набор пошаговых процедур проверки того или иного программного обеспечения.
Тест изначально заточен на то, чтобы выполнять определенные действия и проверять полученный результат.
Это своего рода живая спецификация — проверка (тест) разбивает на детали свойство програмного обеспечения, показывая как оно должно функционировать «вживую».
Пользователь должен понимать на уровне интуиции, как работает тот или другой тест.
Если вы QA-инженер, постарайтесь взять на вооружение такие паттерны как: настрой-делай-тестируй, а также — if-when-else.
Ваши проверки должны быть краткими и нерасплывчатыми.
Правило №2: проверки должны быть уникальными
Каждый тест в тестовом наборе должен демонстрировать оригинальное поведение. Старайтесь не повторятся.
Тесты-дубли с минимальными различиями могут стать весьма дорогими в поддержке, а пользы приносить мало.
Если написанная проверка Х может покрыть пару вариаций ввода, постарайтесь сконцентрироваться на одной вариации тестов.
Правило №3: тесты должны быть технически индивидуальнымы
За один прием проверяйте только одну единицу ПО.
Когда на все части ПО создано аналогичное количество тестов, тогда тесты не только удобно формулировать, но и автоматизировать. Так они будут понятнымы и поддерживаемыми даже спустя некоторое время.
Всегда, когда у вас появляется желание добавить в один тест сразу несколько типов поведения, проанализируйте возможность разделить эти типы поведения на несколько проверок.
Возьмите на вооружение практику по созданию атомарных тестов.
Правило №4: независимые проверки
Тест не должен зависеть от выполнения другого теста. Другими словами, ваши проверки должны быть такими, чтобы их можно было прогонять даже по отдельности.
Каждый новый тест должен содержать свой собственный ресурс.
Все автоматизированные тесты должны содержать исключительно паттерны зависимости, но не глобальные переменные. Если один тест падает, все последующие должны проходить валидацию.
Создавайте тесты таким образом, чтобы каждый из них мог стартовать самостоятельно, а порядок запуска — постоянно меняться.
Правило №5: повторяемость
Процесс тестирования — это некая деятельность по выполнению постоянно повторяемых действий.
Каждый тестовый набор должен корректно прогоняться, а также предоставлять обратную связь в ходе создания и тестирования ПО.
К сожалению, ручные тесты сложно повторять без потери эффективности.
Они занимают существенное время для прогона, а пользователи не могут выполнять их в точности так же каждый раз, когда это необходимо.
Только автоматизация тестов делает их реально повторяемыми.
Их запросто можно автоматизировать один раз и до бесконечности и прогонять одним способом множество раз подряд.
Сценарии автоматизации также всегда работают по одинаковому сценарию.
Правило №6: надежность тестов
Тест должен успешно проходить от начала до конца. Если тест ненадежен — как можно «доверять» его результатам?
И почему тогда проектная группа тратит столько времени на прогонку, если их проблематично прогонять?
Чтобы получить хорошие итоги, пользователь не должен перепрогонять тестовые наборы.
Если они с точной периодичностью подвержены падению, стоит подумать с чем это сопряжено.
Постарайтесь разобраться со всеми ошибками автоматизации. Выстройте перерывы. Выполняйте масштабирование вашей тестовой инфраструктуры до достаточных размеров.
Отдавайте предпочтение стабильности тестов, нежели их скорости выполнения.
Правило №7: тесты должны быть эффективными
Базовая задача процесса тестирования — предоставление мгновенной обратной связи.
Обратная связь позволяет проектной группе быстро локализовать баги и продолжать безопасное тестирование.
Медленные проверки предоставляют медленную обратную связь и заставляют проектную команду, банально, сокращать тестовое покрытие.
Создавайте атомарные проверки, которые могут покрыть конкретное пользовательское и системное поведение.
Например, возьмите на вооружение API вместо UI для целей подготовки информации.
Пробуйте выполнять тесты для параллельного запуска.
Выполняйте прогон в тестовых рамках непрерывной интеграции, чтобы мгновенно получить желаемые результаты.
Итоги
Все вышеописанные признаки могут сделать ваши тесты более эффективными, но естественно, данный список имеет право на дополнение.
Оставить комментарий