Додо сказал:
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.
Л.Кэрролл, «Приключения Алисы в стране чудес»
Развивая автоматизацию тестирования, можно найти много мест, куда приложить силы. Распыляя усилия и преследуя ложные цели мы не только потратим время и ресурсы впустую, но и нанесем разработке вред.
Если знать, на каком уровне развития находится автоматизация тестирования проекта сейчас и куда в такой ситуации инвестировать, можно не просто добиться большей отдачи, но и улучшить разработку в целом. Основные принципы инвестирования ресурсов можно попробовать сформулировать в виде короткого манифеста.
Пожалуй самый распространенный и общепризнанный манифест в области автоматизации тестирования был создан в 2003 году Джерардом Месарошем и его коллегами из ClearStream Consulting.
В своем заявлении они декларируют 12 требований, которым обязан удовлетворять каждый отдельный тест. Для примера, одно из таких требований — краткость. Тест должен быть настолько простым насколько это возможно, но не проще.
В дальнейшем описанные идеи получили развитие в книге «Шаблоны тестирования xUnit. Рефакторинг кода тестов xUnit Test Patterns». Это ценное руководство для разработчиков, где Месарош подробно разбирает множество проблем, связанных с unit-тестами и предлагает шаблоны программирования для их решения.
Однако, понимания как разрабатывать отдельные тесты недостаточно для успешного развития автоматизации. Ресурсы всегда ограничены. Поэтому ключевым фактором успеха будет еще и понимание того, какие качества нужно развивать в первую очередь.
Базовые качества тестов — это доверие и поддерживаемость. Их и необходимо обеспечить в первую очередь.
Доверие — полная уверенность всех работающих с автоматизированными тестами в результатах их запуска. Если зеленые тесты не гарантируют, что проверка отработала — им не будут доверять ручные тестировщики. Если красный тест не означает наличия проблемы — не будут верить программисты. Если тесты случайным образом будут то красные, то зеленые — их станут игнорировать все в равной мере.
Поддерживаемость — возможность разработчиков работать с кодом приложения, не вкладывая неприемлемый объем усилий в поддержку существующих тестов в рабочем состоянии.
Несбалансированность объема работ по поддержке тестов и объема изменений в коде приведет к коллапсу разработки. Представьте, что внесение изменений в код в одном случае требует изменений одного тестового класса, а в другом случае — сотни тестовых классов, или просто на каждую измененную строку кода нужно исправить сто строк в тестах. Тогда стоимость разработки взлетит до небес, а разработчики будут стремиться вносить в код минимум изменений. В итоге код продукта уйдет в заморозку и его развитие прекратится.
Упавший тест, который не выявил сути выявленной проблемы, “expected true was false”, потребует глубокого разбирательства в коде теста для ее решения. Такие усилия будут постоянно тратиться впустую, отнимая время у действительно важных задач.
Обеспечение доверия к тестам и их поддерживаемости — технически сложная и трудоемкая задача, но ее решение дает небольшой видимый эффект. Многие воспринимают наличие этих качеств как должное. Однако, если тесты неподдерживаемые или к ним нет доверия, любые другие инициативы по автоматизации обречены на провал.
Добившись успеха в соблюдении санитарных норм можно перейти к максимизации пользы, которую тесты могут принести для разработки. Для этого нужно максимально, но без ущерба стабильности, повысить скорость прогона тестов и обеспечить их расширяемость — возможность создавать новые тесты.
Скорость — полное время, необходимое для прогона тестов, которое определяет их применимость на качественном уровне.
Обнаружение ошибок на максимально ранней стадии — принцип, позволяющий существенно повысить продуктивность разработки, поскольку всегда проще исправить проблемы в момент их возникновения. И именно быстрые тесты позволяют это обеспечить.
Быстрые тесты обращают внимание разработчика на ошибку, пока он еще в игре. Если тесты выполняются долго, то разработчик узнает об ошибке уже после переключения на другие задачи. Это слишком поздно, так как потребуются дополнительные усилия, чтобы вернуться к проблеме. Пустая трата времени. Раздражает. Демотивирует.
Расширяемость — возможность разработчиков создавать новые тесты быстро и качественно.
Если создание каждого теста превращается в изобретение велосипедов в духе «как подменить поведение метода», «как создать тестового пользователя», «как сделать скриншот страницы» и т.д., вряд ли можно ожидать, что покрытие кода тестами будет расти. Скорее оно будет ползти.
Покрытие тестами всего нового кода — основной способ получить максимальную отдачу от написания тестов, поскольку именно новый код наиболее подвержен ошибкам и доработкам. Однако, воплотить этот принцип, не решив проблемы расширяемости тестов, будет очень трудно.
Обеспечение скорости выполнения тестов и их расширяемости — способ получить от автоматизации ощутимую пользу и сделать написание тестов осознанно привлекательным для разработчиков.
С точки зрения ручного тестирования, на данном этапе работа сокращается опосредованно. Проблема, найденная автотестами, будет исправлена разработчиком сразу, и не потребует участия ручного тестирования. Это хорошо, но это далеко не все, что могут дать тесты.
Работая с автотестами и сохраняя одновременно ручное тестирование, хочется объединить эти процессы естественно, чтобы каждый из них получал максимальную выгоду от другого. А для этого нужно интегрировать процессы автоматизации и ручного тестирования и обеспечить покрытие продукта тестами.
Покрытие — автоматическая проверка, как минимум, всех ручных кейсов по всему продукту, либо по его отдельным модулям.
Реализация полного покрытия тестами естественным образом, требует написания новых тестов. Если проблема расширяемости тестов не решена, такой процесс окажется неоправданно дорог, а тесты полученные в результате будет трудно поддерживать. Расширение множества тестов неизменно приведет к увеличению времени на их исполнение. Тут важна скорость, медленные тесты существенно теряют в цене, даже если их очень много.
Интеграция с ручным тестированием — замена части работ ручного тестирования прогоном автоматизированных тестов.
В идеале нужно стремиться, чтобы «то, что не менялось» никогда не тестировалось вручную повторно. Конечно, добиться этого сложнее всего.
Идея интеграции тестов в процесс ручного тестирования также не имеет смысла, если не обеспечена расширяемость тестов, поскольку автоматизация ручных сценариев будет невозможна в должной степени. Скорость тестов так же важна. Слишком медленный прогон автоматических тестов приведет к тому, что тестировщику будет проще проверить все руками, нежели ждать выполнения автоматики.
Обеспечение покрытия и интеграция с ручными тестированием — то, что придает концепции автоматизированного тестирования целостный и законченный вид.
В долгосрочной перспективе автоматизация тестирования необходима, и затраты ресурсов на ее обеспечение неизбежны. Однако, если добиться результата на качественном уровне, можно хотя бы начать сокращение издержек на ручное тестирование. Это само собой приведет к сокращению цикла разработки.
Раз уж мы вынуждены писать тесты, нужно добиться того чтобы эти усилия приносили максимум пользы для всех, а работа двигалась быстрее.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Ведущий оператор баш консоли 2 разряда
— Правильность формы несущественна! А потом расставил всех без всякого порядка по кругу. Никто не подавал команды — все побежали, когда захотели.
Л.Кэрролл, «Приключения Алисы в стране чудес»
Развивая автоматизацию тестирования, можно найти много мест, куда приложить силы. Распыляя усилия и преследуя ложные цели мы не только потратим время и ресурсы впустую, но и нанесем разработке вред.
Если знать, на каком уровне развития находится автоматизация тестирования проекта сейчас и куда в такой ситуации инвестировать, можно не просто добиться большей отдачи, но и улучшить разработку в целом. Основные принципы инвестирования ресурсов можно попробовать сформулировать в виде короткого манифеста.
Манифест автоматизации тестирования
Доверие к тестам и их поддерживаемость — важнее всего.
Скорость и расширяемость тестов важны только при наличии доверия и поддерживаемости.
Покрытие всего продукта тестами и интеграция автоматизации с ручным тестированием имеют смысл только при достижении доверия, поддерживаемости, скорости и расширяемости тестов.
Критика
Пожалуй самый распространенный и общепризнанный манифест в области автоматизации тестирования был создан в 2003 году Джерардом Месарошем и его коллегами из ClearStream Consulting.
В своем заявлении они декларируют 12 требований, которым обязан удовлетворять каждый отдельный тест. Для примера, одно из таких требований — краткость. Тест должен быть настолько простым насколько это возможно, но не проще.
В дальнейшем описанные идеи получили развитие в книге «Шаблоны тестирования xUnit. Рефакторинг кода тестов xUnit Test Patterns». Это ценное руководство для разработчиков, где Месарош подробно разбирает множество проблем, связанных с unit-тестами и предлагает шаблоны программирования для их решения.
Однако, понимания как разрабатывать отдельные тесты недостаточно для успешного развития автоматизации. Ресурсы всегда ограничены. Поэтому ключевым фактором успеха будет еще и понимание того, какие качества нужно развивать в первую очередь.
Соблюдение санитарных норм
Базовые качества тестов — это доверие и поддерживаемость. Их и необходимо обеспечить в первую очередь.
Доверие — полная уверенность всех работающих с автоматизированными тестами в результатах их запуска. Если зеленые тесты не гарантируют, что проверка отработала — им не будут доверять ручные тестировщики. Если красный тест не означает наличия проблемы — не будут верить программисты. Если тесты случайным образом будут то красные, то зеленые — их станут игнорировать все в равной мере.
Поддерживаемость — возможность разработчиков работать с кодом приложения, не вкладывая неприемлемый объем усилий в поддержку существующих тестов в рабочем состоянии.
Несбалансированность объема работ по поддержке тестов и объема изменений в коде приведет к коллапсу разработки. Представьте, что внесение изменений в код в одном случае требует изменений одного тестового класса, а в другом случае — сотни тестовых классов, или просто на каждую измененную строку кода нужно исправить сто строк в тестах. Тогда стоимость разработки взлетит до небес, а разработчики будут стремиться вносить в код минимум изменений. В итоге код продукта уйдет в заморозку и его развитие прекратится.
Упавший тест, который не выявил сути выявленной проблемы, “expected true was false”, потребует глубокого разбирательства в коде теста для ее решения. Такие усилия будут постоянно тратиться впустую, отнимая время у действительно важных задач.
Обеспечение доверия к тестам и их поддерживаемости — технически сложная и трудоемкая задача, но ее решение дает небольшой видимый эффект. Многие воспринимают наличие этих качеств как должное. Однако, если тесты неподдерживаемые или к ним нет доверия, любые другие инициативы по автоматизации обречены на провал.
Максимизация пользы для разработчиков
Добившись успеха в соблюдении санитарных норм можно перейти к максимизации пользы, которую тесты могут принести для разработки. Для этого нужно максимально, но без ущерба стабильности, повысить скорость прогона тестов и обеспечить их расширяемость — возможность создавать новые тесты.
Скорость — полное время, необходимое для прогона тестов, которое определяет их применимость на качественном уровне.
Обнаружение ошибок на максимально ранней стадии — принцип, позволяющий существенно повысить продуктивность разработки, поскольку всегда проще исправить проблемы в момент их возникновения. И именно быстрые тесты позволяют это обеспечить.
Быстрые тесты обращают внимание разработчика на ошибку, пока он еще в игре. Если тесты выполняются долго, то разработчик узнает об ошибке уже после переключения на другие задачи. Это слишком поздно, так как потребуются дополнительные усилия, чтобы вернуться к проблеме. Пустая трата времени. Раздражает. Демотивирует.
Расширяемость — возможность разработчиков создавать новые тесты быстро и качественно.
Если создание каждого теста превращается в изобретение велосипедов в духе «как подменить поведение метода», «как создать тестового пользователя», «как сделать скриншот страницы» и т.д., вряд ли можно ожидать, что покрытие кода тестами будет расти. Скорее оно будет ползти.
Покрытие тестами всего нового кода — основной способ получить максимальную отдачу от написания тестов, поскольку именно новый код наиболее подвержен ошибкам и доработкам. Однако, воплотить этот принцип, не решив проблемы расширяемости тестов, будет очень трудно.
Обеспечение скорости выполнения тестов и их расширяемости — способ получить от автоматизации ощутимую пользу и сделать написание тестов осознанно привлекательным для разработчиков.
С точки зрения ручного тестирования, на данном этапе работа сокращается опосредованно. Проблема, найденная автотестами, будет исправлена разработчиком сразу, и не потребует участия ручного тестирования. Это хорошо, но это далеко не все, что могут дать тесты.
Сокращение цикла разработки и ручного тестирования
Работая с автотестами и сохраняя одновременно ручное тестирование, хочется объединить эти процессы естественно, чтобы каждый из них получал максимальную выгоду от другого. А для этого нужно интегрировать процессы автоматизации и ручного тестирования и обеспечить покрытие продукта тестами.
Покрытие — автоматическая проверка, как минимум, всех ручных кейсов по всему продукту, либо по его отдельным модулям.
Реализация полного покрытия тестами естественным образом, требует написания новых тестов. Если проблема расширяемости тестов не решена, такой процесс окажется неоправданно дорог, а тесты полученные в результате будет трудно поддерживать. Расширение множества тестов неизменно приведет к увеличению времени на их исполнение. Тут важна скорость, медленные тесты существенно теряют в цене, даже если их очень много.
Интеграция с ручным тестированием — замена части работ ручного тестирования прогоном автоматизированных тестов.
В идеале нужно стремиться, чтобы «то, что не менялось» никогда не тестировалось вручную повторно. Конечно, добиться этого сложнее всего.
Идея интеграции тестов в процесс ручного тестирования также не имеет смысла, если не обеспечена расширяемость тестов, поскольку автоматизация ручных сценариев будет невозможна в должной степени. Скорость тестов так же важна. Слишком медленный прогон автоматических тестов приведет к тому, что тестировщику будет проще проверить все руками, нежели ждать выполнения автоматики.
Обеспечение покрытия и интеграция с ручными тестированием — то, что придает концепции автоматизированного тестирования целостный и законченный вид.
В долгосрочной перспективе автоматизация тестирования необходима, и затраты ресурсов на ее обеспечение неизбежны. Однако, если добиться результата на качественном уровне, можно хотя бы начать сокращение издержек на ручное тестирование. Это само собой приведет к сокращению цикла разработки.
Раз уж мы вынуждены писать тесты, нужно добиться того чтобы эти усилия приносили максимум пользы для всех, а работа двигалась быстрее.
Дмитрий Мамонов
Департамент разработки,
Подразделение мержа в мастер,
Отдел работы с гит,
Ведущий оператор баш консоли 2 разряда