Небольшие и частые релизы
Agile пытается порвать шаблоны исторической инерции, предлагая как можно сильнее сократить циклы релизов. Если у вас релиз происходит раз в полгода, постарайтесь выпускать раз в три месяца, раз в месяц, раз в неделю, в конце концов. Продолжайте уменьшать циклы релизов, асимптотически стремясь к нулю.
Чтобы достичь этого, организации требуется разорвать связь между релизом и развертыванием. Понятие «релиз» означает, что программа технически готова к развертыванию. Решение о развертывании полностью ложится на плечи клиентов.
Возможно, вы заметили, что теми же самыми понятиями мы описывали итерации. Итерации с технической точки зрения можно развертывать. Если продолжительность итерации составляет две недели, но мы хотим выпускать релизы чаще, придется итерации сократить.
Можно ли сокращать итерации асимптотически, стремясь к нулю? Да, можно. Но это уже тема отдельного разговора.
Приемочное тестирование
Приемочное тестирование — один из самых непонятных и запутанных методов Agile, который используется реже всего. Это любопытно, потому что основной посыл удивительно прост: требования указывает клиент.
Проблема, несомненно, в понимании слова «указывает». Многие клиенты считают, что могут, поводив руками в воздухе, расплывчато и туманно описать функционал, а потом произойдет чудо — разработчики сами догадаются обо всех мельчайших нюансах. А многие программисты хотят, чтобы клиенты точно объяснили, как должна работать программа, вплоть до координат и цвета каждого пикселя на экране.
Из этих двух крайностей нужно вывести золотую середину.
Что же такое спецификация? Спецификация по своей сути — это функция, которую можно протестировать. Например:
Когда пользователь вводит правильное имя учетной записи и пароль, а потом нажимает «войти», на экране появится страница приветствия.
Вот это и есть указание, то есть спецификация. Очевидно, что это можно протестировать.
Очевидно, что тест для этой функции можно автоматизировать. Нет причин на то, чтобы компьютер не мог удостовериться в выполнении указанного требования.
Вот так работает приемочное тестирование. Опыт подсказывает, что насколько это вообще осуществимо, требования к системе должны представлять собой автоматизированные тесты.
Погодите! А кто же пишет эти тесты? Первый абзац этого раздела отвечает на наш вопрос: требования указывает клиент. Тогда получается, что клиенты должны писать автоматизированные тесты, ведь так?
Погодите! Автоматизированные тесты должны быть написаны на каком-то формальном исполняемом языке. И это работа для программистов, не иначе! Получается, что программистам придется писать эти тесты?
Погодите! Если программисты будут писать тесты, то это будет не то, чего хочет клиент. Это будут технические тесты с множеством нюансов, понятных только программистам. Они не отражают ценность тестируемого элемента для клиента. Тогда автоматизированные тесты будет писать клиент? Ведь так?
Погодите! Если автоматизированные тесты будет писать клиент, то они не будут соответствовать технологии, которую мы используем. И программистам тогда придется их переписывать, не так ли?
Вот тут-то и становится понятно, почему этот метод вводит многих людей в заблуждение.
Инструменты и методологии
А еще хуже то, что наш метод погряз в инструментах и методологиях.
Пытаясь облегчить клиентам написание автоматизированных тестов, программисты написали целое изобилие инструментов, оказывающих медвежью услугу. Имеются в виду поделки вроде FitNesse, JBehave, SpecFlow и Cucumber. Каждый из этих инструментов предоставляет формы, призванные отделять техническую сторону автоматизированного теста от пользовательской. Гипотеза состоит в том, что клиент может написать пользовательскую часть автоматизированного теста, в то время как программисты могут написать код, связывающий эти тесты с тестируемой программой.
Звучит круто, и инструменты вроде как неплохо способствуют разделению труда. Тем не менее клиенты неохотно берутся за подобное. Представители компаний, ответственные за указание требований в спецификациях, побаиваются формальных языков. Они в своем большинстве предпочитают человеческие языки вроде русского или английского для написания спецификаций с требованиями.
Увидев, что клиенты ни в какую не хотят писать приемочные тесты, программисты решили исправить положение, и в надежде на то, что клиенты хотя бы прочитают документы, написанные формальным языком, уже сами написали для них тесты. Но и это не сработало, ведь клиенты терпеть не могут формальные языки.
Они предпочтут посмотреть на работающую программу или в лучшем случае доверят тестирование QA-специалистам.
Разработка через поведение
С наступлением нового тысячелетия Дэн Норт начал работу по пересмотру разработки через тестирование. Получившуюся методологию он назвал разработкой через поведение. Он поставил себе цель избавиться от жаргона технарей в тестах, чтобы тесты больше напоминали спецификации с требованиями, которые так любят клиенты.
Сначала это было еще одной попыткой формализации языка тестирования, в этом случае применялось три ключевых слова: «дано», «когда» и «тогда». Было создано или модифицировано несколько инструментов для поддержки этого языка. В их числе JBehave, Cucumber и FitNesse. Но с течением времени упор стал делаться не на инструменты и тесты, а на требования и спецификации.
Сторонники разработки через поведение предполагают, что клиенты могут извлечь большую пользу, указывая требования к своим программам на формальном, основанном на сценариях языке вроде того, который использует ключевые слова «дано», «когда» и «тогда», независимо от того, автоматизированы ли в действительности такие требования в виде тестов.
Это избавляет клиентов от соответствия техническим требованиям, которые налагает написание действительно исполняемых тестов, в то же время позволяя быть тестам формальными и точными.
Как показывает практика…
Несмотря на всю противоречивость и запутанность, которые мы увидели выше, в приемочном тестировании нет ничего сложного. Клиенты пишут формальные тесты, которые содержат описание каждой пользовательской истории, а разработчики эти тесты автоматизируют.
Эти тесты пишутся бизнес-аналитиками и QA-специалистами до завершения первой половины итерации, когда должны разрабатываться истории, которые впоследствии будут проходить эти тесты. Разработчики объединяют эти тесты в непрерывную сборку. Такие тесты соответствуют критериям готовности для историй, разработанных во время итерации. Требования к истории не считаются указанными, пока для нее не написан приемочный тест. История не считается завершенной, пока не пройдено приемочное тестирование.
Бизнес-анализ и контроль качества
Приемочные тесты — результат совместной работы бизнес-аналитиков, QA-специалистов и разработчиков. Бизнес-аналитики указывают, что должно происходить в лучшем случае. Они являются связующим звеном между заинтересованными сторонами и программистами и выражают их желание получить хороший продукт.
Специалисты по контролю качества, напротив, обрисовывают наихудший исход. Сейчас способов получить такой исход намного больше, чем раньше. QA-специалисты зарабатывают на хлеб тем, что вычисляют уязвимости программы. Технари до мозга костей, они способны предвидеть все финты и фокусы, которые может выкинуть программа. Они также знают, как мыслят программисты и как определить халтуру.
И, конечно, не обойтись без самих разработчиков. Они, работая со специалистами по качеству и бизнес-аналитиками, обеспечивают гарантии того, что тесты будут иметь смысл с технической точки зрения.
Контроль качества
Здесь, конечно, QA-специалисты играют уже более важную роль. Если сначала они выполняют тыловую работу тестировщиков, то теперь выходят на первый план, находясь на передовой линии проекта. В начале работ они дают обратную связь после написания кода, указывая на ошибки и упущения, а потом занимаются предотвращением этих ошибок, заблаговременно предоставляя необходимые данные разработчикам.
Нагрузка на специалистов по качеству многократно возрастает. Контроль качества теперь должен проходить в начале каждой итерации, а не выявлять недостатки и несоответствие на финальной стадии. Однако в любом случае важность контроля качества не преуменьшается — именно инженеры по качеству определяют, можно ли развернуть систему.
Тесты в конце бесполезны
Проведение контроля качества и автоматизация тестирования решают еще одну важную задачу. Когда специалист по контролю качества проводит тестирование в конце, да еще и вручную, он попадает в щекотливое положение.
Работа должны быть выполнена до развертывания программного обеспечения. Но менеджерам и заинтересованным сторонам просто не терпится скорее начать развертывание, и они наседают на QA-инженеров.
Когда контроль качества переносится на финал проекта, весь удар берут на себя специалисты по качеству. А если разработчики отдадут продукт на проверку с опозданием, будет тогда перенос сроков? Часто сроки определяются очень важными деловыми причинами, поэтому перенос будет дорого стоить или даже в корне расстроит планы клиента. В итоге козлом отпущения остаются QA-специалисты.
Как специалистам по качеству тестировать программу, если на это не остается времени в графике работ? Как им выполнить работу быстрее? Очень просто: пропустить некоторые тесты. Протестировать только то, что изменилось. Провести анализ воздействия на функции, которые появились недавно или претерпели изменения, а потом протестировать уязвимости. Не тратить время на тестирование того, что не изменилось.
Так пропускаются необходимые тесты. Под давлением сроков QA-специалисты пропускают все регрессионные тесты, надеясь, что проведут их в следующий раз. Но чаще всего «следующий раз» не наступает.