Agile-тестирование, Джанет Грегори, Лайза Криспин
Джанет Грегори,Лайза Криспин

Agile-тестирование

Сообщить о появлении
Загрузите файл EPUB или FB2 на Букмейт — и начинайте читать книгу бесплатно. Как загрузить книгу?
Книга ведущих мировых специалистов подробно рассказывает о процессе тестирования с позиции Agile.
Эта книга сейчас недоступна
548 бумажных страниц

Впечатления

Rimma Ibatullina
Rimma Ibatullinaделится впечатлениемв прошлом месяце
👎Не советую
💤Скучно

Цитаты

Maria Shastak
Maria Shastakцитирует3 месяца назад
Планировать ровно столько, сколько необходимо
Иван Николаевич
Иван Николаевичцитирует5 месяцев назад
ГЛАВА 14
ТЕХНИЧЕСКИЙ ДОЛГ В ТЕСТИРОВАНИИ
Уорд Каннингем ввел термин технический долг (Cunningham, 2009), обозначающий быструю разработку свойства или пользовательской истории без возвращения назад для внесения в код корректировок. Мы можем столкнуться с невероятным техническим долгом как в кодах автоматизированных тестов, так и в готовом коде продукта. Многие совершают ошибки в изначальных попытках автоматизировать функциональные тесты. Частично это связано с тем, что современные фреймворки и драйверы позволяют произвести быструю автоматизацию. Однако если мы не будем уделять шаблонам и критериям написания кода автоматизированных тестов такое же пристальное внимание, какое в идеале уделяем коду готового продукта, поддержка скриптов может стать серьезной проблемой. Перестройка готового кода — хитрое дело. Как определить, например, связан сбой теста с ошибкой в перестройке кода или это регрессионный баг софта? Одно из первых упоминаний о техническом долге в тестировании мы нашли в статье «Технический долг, относящийся к тестированию» в блоге Маркуса Гэртнера (Gärtner, 2009).
Если автоматизация проведена ненадлежащим образом или на обслуживание автоматизированных тестов требуется слишком много времени, мы можем не успеть с другими важными проверками. Если мы стеснены в сроках, команда поддается искушению и пропускает тесты из квадратов 3 и 4 (глава 8). Если времени мало, а автоматизированные тесты провалились, может быть принято решение внести правки в готовый код продукта и отложить исправление ошибок в кодах тестов. Если тестировщики вынуждены постоянно гнаться за тестируемым кодом, который прошел проверку на прошлом этапе, у них не будет времени разговаривать с клиентами, выявлять примеры и определять бизнес-ориентированные тесты для разработки текущих историй. Все это превращается в замкнутый круг: нет времени, поэтому пропустим важное тестирование, что приведет к еще большим регрессионным багам, следовательно, мы вряд ли сможем обеспечить продукту надлежащее качество. Этого можно избежать, если относиться и к тес­тированию, и к программированию одинаково внимательно.
Можно отлично автоматизировать тесты на разных уровнях (глава 15) и потом все же понять, что этого было недостаточно. По мере того как меняется сам продукт, бывает сложно обновлять автоматизированные регрессионные тесты, чтобы они соответствовали изменениям. Код тестов, как и продукта, прочесть и понять бывает трудно, в нем могут содержаться ненужные дублирующие участки. К коду тестов следует относиться так же бережно, как и к коду готового продукта.
Давайте посмотрим, как можно бороться с техническим долгом тес­тирования.
ПРОЗРАЧНОСТЬ
Как и в случае с другими сложностями, с которыми сталкиваются Agile-команды, можно начать с разбивки технического долга на уровни, визуализировав их и сделав полностью прозрачными. Подумайте, на какие существующие автоматизированные тесты может повлиять каждая история из списка требований, который включает изменение кода. При необходимости быстро пройдитесь по всем автоматизированным тестам, чтобы оценить масштабы. Не забывайте учитывать время на обновление, создавайте карточки задач. Пишите истории для каждого случая рефакторинга крупного кода автоматизации тестов так же, как для кода продукта.
Отслеживайте, сколько времени требуется на поддержку тестов, визуализируйте их. Вы должны понимать, на что уходит время: на исправление ошибок провалившихся тестов, обновление тестов, которые дают неверные результаты, или на плохо написанные тесты. Возможно, для большей наглядности понадобится написать карточки задач или историй для каждого сценария, нуждающегося в изучении, для технического обслуживания и перестройки скриптов.
Удостоверьтесь, что оценки и задачи соразмерны усилиям, требующимся для проведения ручного регрессионного тестирования каждого выпуска. Помните: ваша команда несет ответственность за все тесты. Для программистов и других членов коллектива в порядке вещей помогать с ручными регрессионными тестами. Мы называем это «разделить тяготы». Такое действие позволяет принимать более обдуманные и эффективные решения, чтобы двигаться вперед.
Устранение дефектов — жесткий подход
Августо Евангелисти рассказывает, как в его команде сократили количество дефектов и научились получать удовольствие.
Предупреждение. Это подходит не для всех. Все, что я хочу донести, в нашей ситуации сработало, и вы можете попробовать то же самое на свой страх и риск.
Несколько лет назад у меня случился разговор с весьма интересным человеком. Тогда он был моим директором по развитию и говорил о жестком подходе к устранению ошибок, о том, как было бы хорошо совсем исключить их из разработки софта. Я слушал, но не понимал в полной мере, к чему он ведет. Я никогда даже не слышал, чтобы какой-то команде разработчиков удалось свести ошибки к нулю или хотя бы приблизиться к таким показателям. С тех пор прошло несколько лет, я усердно трудился, чтобы претворить его слова в жизнь. Сегодня могу сказать, что директор был прав. Можно разрабатывать продукт без известных ошибок. Я даже выяснил, что команде, работающей над проектом, вовсе необязательно тратить половину времени на отслеживание, записывание и исправление ошибок.
Давайте расскажу немного о своем проекте и текущей работе. У нас есть две команды с пересекающимся функционалом, работающие в одном помещении. В каждой — четыре разработчика, один тестировщик, один бизнес-аналитик, один руководитель продукта, один специалист DevOps и руководитель команды, выполняющий функции координатора Kanban для всех восемнадцати человек.
Мы используем Kanban для визуализации процессов, что позволяет при необходимости сообщать о каждой завершенной пользовательской истории. Доска Kanban отлично отражает все, что мы делаем. Сверху в центре — сектор ATDD (разработка на основе приемочного тестирования) с колонками, озаглавленными, как у Элизабет Хендриксон: «Обсуждай», «Фильтруй», «Разрабатывай», «Демонстрируй».
Мы стараемся, чтобы пользовательские истории оставались небольшими, чтобы можно было завершить их в течение трех дней. Они записаны в вертикальных колонках. Это значит, что командам не нужна интеграция. Все работают над базой кода, которая охватывает множество приложений.
Мы используем смесь ATDD и спецификации на основе примеров (SBE) (для получения более подробной информации см. главу 11. — Прим. автора), которые я специально разработал для нашего сценария. Программисты проверяют каждую строку кода перед определенным циклом, а также практикуют работу в парах и разработку через тестирование (Hendrickson, 2008).
Мы автоматизировали почти 100% приемочных тестов с помощью jBehave и Thucydides. Наш цикл ATDD основан на модели Джеймса Шора с изменениями, предложенными Григори Мелником, Брайаном Мариком и Элизабет Хендриксон, а также с применением концепции SBE Гойко Аджича. В нем также присутствует часть с отметками «красный», «зеленый», «переделать» из «Agile для Flash» (Ottinger and Langr, 2009c).
У нас функционирует полноценный конвейер типа «платформа по требованию», где проходят все функциональные, нагрузочные тес­ты и проверки производительности, диагностирующие различные варианты относительно основной версии. После каждого запус­ка конвейера включается автоматизированный тест.
Пользовательское тестирование истории осуществляется, когда все автоматизированные приемочные тесты завершены. После этого мы показываем продукт руководителю, который перед тем как принять историю, проводит UAT.
Если во время пользовательского или приемочного тестирования обнаруживается ошибка, программисты, которые занимались этой историей, бросают все дела и исправляют ее немедленно. Карта не пойдет дальше, пока не будет исправлена ошибка. Текущий вариант программы всегда должен обозначаться зеленым. Если появляется красный, разработчик, по чьей вине возник сбой, бросает все дела и устраняет недоработку.
Когда программист исправляет ошибку, он пишет автоматизированные тесты, касающиеся данного сценария. Вы заметили, я упоминаю об ошибках. Конечно, все мы люди, и всем свойственно ошибаться. Но это не значит, что нам нужно радоваться ошибкам, документировать их или возиться с ними, убивать на них время, ведь век их недолог.
Когда я обнаруживаю ошибку во время исследовательского тестирования, вежливо говорю разработчику: «Кажется, у нас проб­лемка. Подойди, чтобы я показал». Если программист уже уходит и не может исправить ошибку прямо сейчас, я приклеиваю красный стикер на карту пользовательской истории, где в двух словах объясняю суть. Это служит напоминанием. Карточка никуда не денется, пока ошибка не будет устранена. Только после этого красный стикер отправится в мусорное ведро.
Такой метод обеспечивает отличное понимание бизнес-ценности, над которой работает команда, потому что примеры для каждой пользовательской истории постоянно обсуждаются. Добавьте к этому отличных разработчиков, использующих превосходные инженерные практики, и вы обнаружите, что ошибок при пользовательском тестировании станет крайне мало. Если разбираться с ними сразу, как только обнаружили, ошибки перестают быть проблемой.
В нашем случае записи и ведение журнала ошибок были бы напрасной тратой времени. Мы прекрасно работаем, не перебрасывая баги, словно мяч, от программиста к тестировщику. Никакой иерархии и постоянных планерок. Никакой статистики. Никаких прогнозов относительно багов, чтобы определить дату выпуска продукта. И знаете что? Мы выпускаем софт, в котором нет ни одной известной ошибки, и наши клиенты счастливы.
В команде Августо научились создавать продукт, который полностью удовлетворяет клиентов, не допускать того, чтобы покупатели обнаруживали ошибки. Частью их стратегии является прикрепление красного стикера на карту истории при обнаружении проблемы, что обеспечивает наглядность и прозрачность. Каждый, лишь мельком взглянув на доску, видит, есть ли что-то, что блокирует историю. Практикуйте такие тесты и визуализацию дефектов в системе мониторинга проекта, на офисных досках с карточками или в цифровом формате. Это позволяет иметь четкое представление о том, не слишком ли много времени уходит на тес­тирование в рамках одного этапа. Перенос задач на следующий этап иногда неизбежен, но это может быть сигналом, что вы слишком увлеклись тестированием технического долга, если не ушли в него с головой.
История Джанет
В одной компании, где я работала, был большой набор регрессионных тестов, но они начали давать сбои и требовали все больше времени. Мы изучили проблему и обнаружили невероятный технический долг. Тесты не просто были нестабильными и сложными. Часто они дублировали задачи друг друга. С этим можно было разобраться в условиях потоковой разработки, а при использовании методов Agile это была катастрофа. Никто не обращал внимания на структуру. Мы отследили, сколько времени требовалось на поддержку тестов, и решили поручить одному сотруднику посвящать полдня в течение месяца устранению дублирующих проверок и упрощению остальных. Это снизило расходы на обслуживание: стало проще находить и исправлять ошибки. Время на тестирование сократилось, что повысило качество и охват. Когда проблемы стали наглядными, команде (включая руководителя продукта) было проще принимать решения по их устранению.
КОМАНДНАЯ РАБОТА НАД САМОЙ СЕРЬЕЗНОЙ ПРОБЛЕМОЙ
К
orlovm
orlovmцитирует8 месяцев назад
Для успешного перехода на Agile необходимо, чтобы между разработчиками и работниками коммерческих отделов существовало взаимопонимание и имелось представление о работе друг друга.

На полках

SCRUM, Elena Shalnova
Elena Shalnova
SCRUM
  • 9
  • 70
Agile and DevOps, Andrey Funtov
Andrey Funtov
Agile and DevOps
  • 12
  • 4
Выход на рынки, romanovkirill
QA, Ринат Туякбаев
Ринат Туякбаев
QA
  • 1
Работа. Тестирование, bga70887
fb2epub
Перетащите файлы сюда, не более 5 за один раз