Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов.
У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
Можете расписать на пальцах, основываясь на своём опыте?
* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
* Когда? В начале/середине/конце итерации, по мере готовности историй?
* Кто и когда исполняет эти тесты?
* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
На практике я думаю никто этим не занимается. Agile придумали теоретики для теоретиков, на практике все эти методологии надо допиливать напильником. Главное, чтобы было что допиливать, то есть была процедура и она выполнялась, иначе будет хаос и управление проектом будет затруднительно.
В реальности, я бы описал "ручные" тесты в общих чертах, неформально.
Здравствуйте, pagrus, Вы писали:
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Приемочный тест — это не обязательно автоматический тест.
L>Приемочный тест — это не обязательно автоматический тест.
Это правда. Хотя меня в первую очередь интересуют именно автоматизированные приёмочные тесты, ответ на вопросы в контексте ручных тестов тоже приветствуется.
Здравствуйте, pagrus, Вы писали:
L>>Приемочный тест — это не обязательно автоматический тест.
P>Это правда. Хотя меня в первую очередь интересуют именно автоматизированные приёмочные тесты, ответ на вопросы в контексте ручных тестов тоже приветствуется.
Я понимаю. Но авторы, которых вы упомянули, скорее всего имели в виду ручные тесты.
В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так?
Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
P>Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner? P>* Когда? В начале/середине/конце итерации, по мере готовности историй? P>* Кто и когда исполняет эти тесты? P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
P>спасибо
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность, которую к тому-же будет разрабатывать кто-то другой.
Пока какой-то функционал еще не реализован, есть возможность разработать тестовый сценарий, так как уже по идее должны быть озвучены какие-то требования/спецификации (разработчики-то на основе чего-то должны реализовывать функционал). А вот уже когда функционал реализован, то можно работать и над реализацией автотеста.
P>Нашёл в гугле и посмотрел пару презентаций по Acceptance TDD — так они обо всём кроме деталей.
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
Могут и те и другие и третьи. Зависит от того, в какой форме эти приемочные тесты представлены. Если это unit-like тесты (реализованы в стиле xUnit движков), то тут скорее работа для разработчиков или же для автоматизаторов (для автоматизации ГУИ как правило задействуется отдельная команда). Но также есть подходы, основная задача которых сводится к предоставлению удобного интерфейса для создания тестов, который понятен и нетехническим специалистам. Примером таких подходов являются keyword-driven, behavior-driven. В этом случае можно привлечь и product-owner-a. Если интересно узнать что-то по этой части, то дополнительно рекомендую погуглить по словам "executable requirements".
P>* Когда? В начале/середине/конце итерации, по мере готовности историй?
Как только есть возможность. То есть, если у вас уже есть требования, спецификации, то можно приступать к созданию тестовых сценариев. Как только готов интерфейс, то уже можно начать реализацию автотестов. Как только функционал достиг хоть какой-то готовности (хотя бы базовый сценарий выполняется), то уже можно и тестировать.
P>* Кто и когда исполняет эти тесты?
Это могут быть тестеры, которым просто нужно дать отмашку, что такой-то функционал готов и его надо бы проверить. Но в том же Agile любят задействовать Continuous Integration, чтобы тесты заводились сами по расписанию (например каждую ночь) или по какому-то триггеру. Даже есть подход, при котором тесты бегают всегда, просто их набор увеличивается по мере добавления новых тестов.
P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
Достигается. Как я указывал выше, как только есть хоть какая-то порция входных артефактов для создания теста, уже можно работать над какой-то частью реализации теста.
Здравствуйте, ulu, Вы писали:
ulu>В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так?
Да, но ведь в TDD разработчик и пишет тест, и задаёт сигнатуры тестируемого объекта.
Здесь же тестер пишет приёмочные тесты, в то время как разработчик занимается реализацией функциональности. Как поддерживается ожидаемый с обоих сторон интерфейс между тестом и реализацией?
ulu>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
Или идея в том, что именно тестер _специфицирует_ эти технические детали, тогда как разрабочик должен извлечь их из кода приёмочного теста, и потом уложиться в них?
Или разработка приёмочного теста проходит в два этапа
1. Написали каркас
2. Допилили под специфику реализации
?
Во-первых, возможно, как раз такие приемочные тесты (которые пишутся до кода) стоит писать самим разработчикам? Во-вторых, по поводу таких деталей, как названия полей, можно ведь наладить коммуникацию между разработчиками и тестировщиками?
Здравствуйте, pagrus, Вы писали:
P>Здравствуйте, ulu, Вы писали:
ulu>>В TDD все тесты пишутся до реализации, а что в этом такого? Ведь смысл тестов в том, чтобы помочь реализации, так? P>Да, но ведь в TDD разработчик и пишет тест, и задаёт сигнатуры тестируемого объекта. P>Здесь же тестер пишет приёмочные тесты, в то время как разработчик занимается реализацией функциональности. Как поддерживается ожидаемый с обоих сторон интерфейс между тестом и реализацией?
ulu>>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
P>Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
P>Или идея в том, что именно тестер _специфицирует_ эти технические детали, тогда как разрабочик должен извлечь их из кода приёмочного теста, и потом уложиться в них?
P>Или разработка приёмочного теста проходит в два этапа P>1. Написали каркас P>2. Допилили под специфику реализации P>?
ulu>Во-первых, возможно, как раз такие приемочные тесты (которые пишутся до кода) стоит писать самим разработчикам? Во-вторых, по поводу таких деталей, как названия полей, можно ведь наладить коммуникацию между разработчиками и тестировщиками?
ulu>>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
P>Вот. Как тестер знает, что поле будет называться "Name", а не "LastName"? Что будет кнопка, а не линк? Что текст будет "OK", а не "Next"? Как он в условиях неопределённости сделает извлечение результата для последующей проверки?
Приемочные тесты не имеют отношения к дизайну и не должны быть детализированы до кнопок и полей. Их смысл — иметь общее направление и четкий критерий окончания реализации функциональности — конечную точку, куда нужно двигаться. А вот как достичь этой точки, покажут юнит-тесты, они сформируют дизайн. Вот хороший пост по теме.
Здравствуйте, pagrus, Вы писали:
P>Можете расписать на пальцах, основываясь на своём опыте? P>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner?
Тесты могут писать тестировщики/аналитик/менеджер проекта, думаю, сильно зависит от команды
Реализацию тестов могут писать разработчики или тестировщики (если хватает квалификации)
P>* Когда? В начале/середине/конце итерации, по мере готовности историй?
Думаю, чем раньше, тем лучше. Разработчики могут использовать тесты при реализации истории.
P>* Кто и когда исполняет эти тесты?
Тестировщики, разработчики, CI
P>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение.
При планировании итерации или обсуждении историй тестировщики придумывают приемочные тесты, потом создают описание этих тестов с помощью соответствующих инструментов(например Cucumber или Fitnesse).
Разработчики при реализации истории пишут дополнительный код что-бы тесты могли запускаться(в Fitnesse, например, так называемые fixtures). Разработку кода для тестов можно включить в definition of done, при желании.
Если интересно, посмотрите блог Лизы Криспин, ее команда уже три-четыре года использует ATDD.
VS>Приемочные тесты не имеют отношения к дизайну и не должны быть детализированы до кнопок и полей. Их смысл — иметь общее направление и четкий критерий окончания реализации функциональности — конечную точку, куда нужно двигаться.
Ок, а вы говорите про автоматизированные, исполняемые тесты? Или полуформализованное описание, направленное на человека?
Со вторым никаких вопросов нет; мой вопрос был о том, действительно ли можно написать исполняемый acceptance test до кода.
VS>А вот как достичь этой точки, покажут юнит-тесты, они сформируют дизайн. Вот хороший пост по теме.
Пардон, статью по ссылке не понял. Он вероятно предполагает хорошее понимание фреймворка, у меня этого нет.
P>>* Кто в команде пишет приёмочные тесты? Разработчики, тестеры, product owner? N>Тесты могут писать тестировщики/аналитик/менеджер проекта, думаю, сильно зависит от команды N>Реализацию тестов могут писать разработчики или тестировщики (если хватает квалификации)
Т.е. вы говорите о "тестах" как простом человеческом описании шагов, проверяющих историю.
И о "реализации тестов" как автоматизированной проверке этих шагов.
P>>* Когда? В начале/середине/конце итерации, по мере готовности историй? N>Думаю, чем раньше, тем лучше. Разработчики могут использовать тесты при реализации истории.
Как я понимаю, здесь вы снова говорите о текстовом описании шагов? Иначе снова возникает вопрос написания исполняемого теста до релизации.
P>>* Кто и когда исполняет эти тесты? N>Тестировщики, разработчики, CI
А тут речь уже про автоматический тест. Не вполне стыкуется — по крайней мере у меня в голове.
P>>* Достигается ли — и каким образом — разработка приёмочных тестов до реализации историй? Давайте предполагать, что команда делает web-приложение. N>При планировании итерации или обсуждении историй тестировщики придумывают приемочные тесты, потом создают описание этих тестов с помощью соответствующих инструментов(например Cucumber или Fitnesse). N>Разработчики при реализации истории пишут дополнительный код что-бы тесты могли запускаться(в Fitnesse, например, так называемые fixtures). Разработку кода для тестов можно включить в definition of done, при желании.
Иными словами, тестировщик пишет "каркас" теста, а разработчик добавляет детали, чтобы тест стал исполняемым? Это я могу представить.
N>Если интересно, посмотрите блог Лизы Криспин, ее команда уже три-четыре года использует ATDD.
Интересно. Я как раз читаю "Agile Testing", где она соавтор. Спасибо.
Так вышло, что уже после начала этого топика я прошёл certified scrummaster у хорошего тренера, и теперь думаю что в самом вопросе заложены некорректные предпосылки.
— что в agile-команде выделяются разработчики и тестеры
— что вторые должны обеспечивать тестирование работы первых и никак иначе
— что приёмочный тест обязательно автоматизирован
— что автоматизированный приёмочный тест разрабатывается в полном объёме одним человеком, а затем в готовом виде "перебрасывается через забор" разработчику
Здравствуйте, pagrus, Вы писали:
P>Коллеги,
P>Я читал в книках по agile о том, как тестеры в самом начале итерации могут заняться написанием приёмочных тестов. P>У меня в голове не очень укладывается, как на практике пишется валидный автоматический тест на несуществующую функциональность,
Почитайте про behavior driven development. Это частный, но яркий случай такого подхода. Если какая-то функциональность оговорена изначальной постановкой задачи, и она пригодна к автоматической проверке, то на неё можно написать тест ещё до реализации. Возможно, какие-то детали этого теста могут быть изменены позже (например, несущественное изменение порядка действий или даже аргументов в вызове функции), но основная интеллектуальная работа к этому моменту уже проделана и доработать можно относительно легко.
P> которую к тому-же будет разрабатывать кто-то другой.
А это как раз важный приём: написание тестов не автором кода позволяет применить мышление, которое не шло по известному проторенному пути и может создавать неожиданные проверки. Хотя это более полезно для особо хитрых внутренностей.
Здравствуйте, ulu, Вы писали:
ulu>В TDD все тесты пишутся до реализации, а что в этом такого?
То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации). В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден. А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!") Второй — это хоть какая-то надёжность работы самого теста. Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности. С минимальным тестовым фреймворком замаскировать такую облегчённую проверку тривиально, и требуется явный code review кем-то заинтересованным в качестве реализации, чтобы проверки были реальными. Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.
ulu> Ведь смысл тестов в том, чтобы помочь реализации, так?
ulu>Web-приложения -- не исключение. Вы даете браузеру задание ввести текст в поле "Name" и нажать кнопку "OK", а потом проверяете результат. Понятно, что тест упадет -- ведь такого поля и кнопки нет. Как раз непонятно, как в этой ситуации делать ручные тесты.
Проверить, что кнопки нет. По-моему, это очевидно. Точно так же как нелепость такого теста по отдельности в случае ручного запуска.
N>Почитайте про behavior driven development. Это частный, но яркий случай такого подхода. Если какая-то функциональность оговорена изначальной постановкой задачи, и она пригодна к автоматической проверке, то на неё можно написать тест ещё до реализации. Возможно, какие-то детали этого теста могут быть изменены позже (например, несущественное изменение порядка действий или даже аргументов в вызове функции), но основная интеллектуальная работа к этому моменту уже проделана и доработать можно относительно легко.
P>> которую к тому-же будет разрабатывать кто-то другой.
N>А это как раз важный приём: написание тестов не автором кода позволяет применить мышление, которое не шло по известному проторенному пути и может создавать неожиданные проверки. Хотя это более полезно для особо хитрых внутренностей.
Спасибо, про BDD я читал и даже слегка использую при юнит-тестировании. Нормально работает, когда я по ходу написания тестов могу добавлять сигнатуры основного кода.
Непонятно, как это работает в случае написания приёмочных тестов другим человеком, до кода. Для того, чтобы они были исполняемыми, нужно знать реализацию, по крайней мере на уровне интерфейса. А его пока нет.
Интересная мысль про инверсию тестов. Я похожее делаю вручную при реализации тестов/кода, особенно если вдруг неожиданно много новых тестов прошли с первого раза.
Я правильно понимаю, что такие инверсии вы оформляете как отдельные тест-кейсы и включаете в общий test suite?
Здравствуйте, pagrus, Вы писали:
P>Интересная мысль про инверсию тестов. Я похожее делаю вручную при реализации тестов/кода, особенно если вдруг неожиданно много новых тестов прошли с первого раза.
P>Я правильно понимаю, что такие инверсии вы оформляете как отдельные тест-кейсы и включаете в общий test suite?
Да.
Технологически это выглядит как включение каталога в список тех, у которых есть инверсии, и задание списка опций в параметре FUNCTESTS_INVERSE в Makefile. Включаемый в это Makefile файл умеет итерировать этот список и запускать тест с установкой параметра в окружении.
Единственное специфическое ограничение метода — сама проверка параметра и действия в его случае не должны сами приводить к слёту теста; отличить эту ситуацию в многомегабайтной простыне тяжело. Но такое условие достаточно легко обеспечить и мы с ним смирились.
N>То, что это слишком часто не работает. TDD в классическом виде — это сферический конь в вакууме, применимый только с идеальной задачей, идеальным заказчиком (который никогда не меняет постановку задачу) и идеальными исполнителями (которые всё грамотно спроектировали с самого начала, не махлюют в тестах и не ошибаются в реализации).
Это не так, а как раз наоборот. Юнит тесты особенно хорошо показывают свою ценность именно в условиях постоянных доработок проекта и изменения требований, потому что дают уверенность в качестве кода и делают рефакторинг простой и быстрой задачей.
N>В более типичном случае всегда есть места, которые переделываются по 2-3 раза, включая внутренние интерфейсы, код пишется раньше тестов для того, чтобы проверить, что он в принципе работает, и уже после получения работающего результата возникает понимание, что надо было делать и почему именно так. В этом случае TDD в принципе непригоден.
Вы путаете TDD с бардаком, когда нет планирования и постоянного feedback от заказчика, либо когда из всего процесса TDD берут одни только юнит-тесты и пытаются прикрутить их к legacy проекту.
N>А если вмешивается заказчик, заставляя всё перепахать, то от его обоснований вообще ничего не остаётся.
На практике вариант "все переделать с нуля" как правило не встречается, а если встречается, то с заказчиком заключается новый договор на разработку новой программы. Что происходит в реальности, это "что-то писали в течение года, потом показали заказчику и оказалось, что за год бизнес-задачи поменялись, на момент составления ТЗ заказчик сам не до конца понимал чего ему нужно, а программисты это еще и не так интерпретировали". TDD не поможет при неправильном применении.
N>Правило "сначала тест, потом код" в TDD имеет два смысла. Первый — административный — выполнение такого рода процедуры проще обеспечить и соблюсти общий порядок, чем, если код уже написан, тянуть со временем и с деньгами, чтобы выдать релиз ("чего вы тянете, оно же всё написано и у тестера Маши даже показало результат! немедленно начинать продавать!")
Какое отношение имеют юнит тесты с "показало результат"? Ладно бы функциональные или приемочные, но юнит тесты?
N>Второй — это хоть какая-то надёжность работы самого теста.
Да, одно из преимуществ написания теста до кода — это возможность убедиться в том, что тест способен валиться. Иначе легко получить тесты, которые проходят вообще всегда, независимо от качества реализации тестируемой функции.
N>Первое я ещё могу принять как обоснование, второе — нет, потому что неизвестно качество самого теста: например, он может проверять, что функция вообще реализована, но соглашаться на любое возвращённое значение, независимо от его корректности.
Если тест стал настолько сложным, что в нем легко допустить такую ошибку, значит либо это не юнит-тест, а функциональный тест, либо пора думать о тестах для тестов, т.е. о создании упрощенной модели тестируемого продукта, на которой можно отлаживать тесты.
N>Но, заметьте, TDD этого (ревью кода тестов) в общем случае не требует, а косвенно, наоборот, обещает (для стандартной психологии менеджера), что code review при TDD нужен меньше — потому что всё покрыто тестами.
TDD ничего подобного не обещает. На самом деле разработка с TDD сложнее, чем без TDD. Это та цена, которую мы платим за предсказуемость результат и уменьшение времени отладки. Те, кто считает, что с TDD можно будет ничего не делать и писать код тяп-ляп, а оно как-нибудь само, сильно заблуждаются.
N>Мы для обеспечения корректности тестов используем инверсии тестов. Инверсия — это запуск при специальном входном условии (параметре) самого теста, которое требует выполнить изменение входных данных проверяемого кода с тем, чтобы результат не соответствовал ожидаемому без инверсии. Например, если проверяется сложение строк, на входе 2 строки по 40 символов, а на выходе 80, то инверсией может быть задание пустой строки вместо второй. (В реальности примеры сильно сложнее: например, один из тестов — порвать связь с объектом и проверить, что первая тревога уровня warning прошла в интервале от 9 до 15 секунд; тогда инверсия — не рвать связь.) Тест корректен, если он выполняется положительно без инверсий со всеми вариациями и отрицательно — при любой из инверсий. Проверки, список вариаций и инверсий входят в спецификацию теста и соответствие им проверяется через явное ревью кода теста.
Точно так же как нелепость такого теста по отдельности в случае ручного запуска.
