Комментарии 11
0_O политичеCукий вопрос? намеренно?
Тестирование и изучение кода это перед оценкой — это правильный подход. Все-таки, кажется, если знаешь приложение то оцениваешь на глаз в story points, но даже один point включает тесты.
Дальше на первых 2-3 спринтах это все может отличаться, но со временем оценки команды становятся точнее.
Представь ситуацию ты готовишь с командой backlog к планирования и делаешь оценки user story. Если полностью проходить по твоей процедуре, будет довольно долго.
Лучший вариант, когда оценки дают 2-3 человека. Дальше либо усредняешь, в случае небольшой разницы, либо обсуждаешь очень серьезные расхождения.
Тестирование и изучение кода это перед оценкой — это правильный подход. Все-таки, кажется, если знаешь приложение то оцениваешь на глаз в story points, но даже один point включает тесты.
Дальше на первых 2-3 спринтах это все может отличаться, но со временем оценки команды становятся точнее.
Представь ситуацию ты готовишь с командой backlog к планирования и делаешь оценки user story. Если полностью проходить по твоей процедуре, будет довольно долго.
Лучший вариант, когда оценки дают 2-3 человека. Дальше либо усредняешь, в случае небольшой разницы, либо обсуждаешь очень серьезные расхождения.
политичеCукий — исправил. Ненамеренно, хотя по Фрейду.
Оценки user story мы делаем совместно с заказчиком, и потом усредняем либо спорим если были большие расхождения. Я говорю про более детальную разбивку user story по tasks. Что то типа «добавить валюту для матчинга трейдов с конфирмейшенами». Понять, что тебе нужно добавить поле валюты на этапе оценки user story в story point не всегда представляется возможным.
Оценка User Story (US) в Story Points (SP) более поверхностна, и не должна занимать много времени, и как правило может быть проведена после PBR.
Оценки user story мы делаем совместно с заказчиком, и потом усредняем либо спорим если были большие расхождения. Я говорю про более детальную разбивку user story по tasks. Что то типа «добавить валюту для матчинга трейдов с конфирмейшенами». Понять, что тебе нужно добавить поле валюты на этапе оценки user story в story point не всегда представляется возможным.
Оценка User Story (US) в Story Points (SP) более поверхностна, и не должна занимать много времени, и как правило может быть проведена после PBR.
Попытался применять нечто подобное, получалось как-то так:
1. формулируем цель «патча»
2. покрываем тестами всё, что он может затронуть. Результаты нужные получаем ручками, то есть запускаем приложение, производим действие (набор действий), снимаем ввод/вывод. Чтобы покрыть тестами много рефакторим, чтоб можно было подсунуть мокостабы для эмуляции ввода/вывода
3. пишем (изменяем нужные) тесты на ожидаемое после «патча» поведение, то есть планируем реализацию
4. реализуем
И как-то получается, что первые три пункта занимают кучу времени по сравнению с последним. То есть к моменту окончания планирования сделано до 90% работы.
1. формулируем цель «патча»
2. покрываем тестами всё, что он может затронуть. Результаты нужные получаем ручками, то есть запускаем приложение, производим действие (набор действий), снимаем ввод/вывод. Чтобы покрыть тестами много рефакторим, чтоб можно было подсунуть мокостабы для эмуляции ввода/вывода
3. пишем (изменяем нужные) тесты на ожидаемое после «патча» поведение, то есть планируем реализацию
4. реализуем
И как-то получается, что первые три пункта занимают кучу времени по сравнению с последним. То есть к моменту окончания планирования сделано до 90% работы.
По поводу второго пункта, подумалось вот что: если много рефакторите, чтобы можно было подсунуть моки или стабы то скорее всего проектирование и дизайн и потом разработка не соответвовала SOLID правилам, нужно подумать над technical dept. Может TDD, ибо при этом подходе ты всегда уверен что любой код был написан благодаря упавшим тестам.
Кроме того функциональное тестирование, как праило подразумевает мокание сторонних систем с которыми вы взаимодействуете или UI.
Кроме того функциональное тестирование, как праило подразумевает мокание сторонних систем с которыми вы взаимодействуете или UI.
Унаследованный код. Ну я и мокаю, например, СУБД или ФС.
Это уже интеграционные тесты или даже Unit. В функциональных тестах вы запускаете систему на реальное базе, по крайней мере должны к этому стремиться, единственное, что в функциональных тестах может быть недоступно, это сторонние системы с которыми вы взаимодействуете. Что такое ФС?
С унаследованным кодом часто бывают такие проблемы, как невозможность нормально замокать/стабить какую-то абстракцию. Отсюда необходимость рефакторинга в таком объеме.
Если вы обратитесь к Continiuos Delivery (не путайте с Continious Integration), то вы увидите паттерн Branch By Abstraction. Так вот применить этот подход особенно сложно когда код лапшеобразный, то есть, изменив, что то в одном месте проблемы вылазят совершенно в непредсказуемых местах. Все это немного из другой оперы но, тем не менее упирается в построение тестов.
С унаследованным кодом часто бывают такие проблемы, как невозможность нормально замокать/стабить какую-то абстракцию. Отсюда необходимость рефакторинга в таком объеме.
Если вы обратитесь к Continiuos Delivery (не путайте с Continious Integration), то вы увидите паттерн Branch By Abstraction. Так вот применить этот подход особенно сложно когда код лапшеобразный, то есть, изменив, что то в одном месте проблемы вылазят совершенно в непредсказуемых местах. Все это немного из другой оперы но, тем не менее упирается в построение тестов.
Может у меня своя терминология, но тесты на реальной базе я называю приемочными, с замоканными внешними серверами и сервисами (веб, субд, фс — файловая система) — функциональными, проверяющие взаимодействие юнитов — интеграционными. Грубо говоря, в функциональных проверятся приложение от момента прихода запроса от веб-сервера до отдачи ему ответа и вызова библиотек взаимодействия с субд, фс и т. п., то есть собственно приложение целиком, но в чистом вакууме, без взаимодействия с внешней средой. Библиотекам взаимодействия я доверяю, ос, субд, веб-серверу тоже. Только перед самым релизом запускаю приемочные тесты в окружении максимально приближенном к боевому (на виртуалке с той же осью и с +- теми же пакетами и настройками). В принципе мои функциональные тесты отвечают вашему определению, причём буквально ему отвечают — никаких сторонних систем (кроме тестирующего фреймворка): в файл писать? нет, внешняя, значит мок! в базу писать? нет! ответ на запрос серверу отдать? нет! А вот приемочные уже дают запрос серверу и проверяют появился ли файлик или запись в БД.
P.S. Почитал про Continiuos Delivery сейчас — правильная вроде штука. Спасибо за наводку. Надо будет к ней стремиться потихоньку…
P.S. Почитал про Continiuos Delivery сейчас — правильная вроде штука. Спасибо за наводку. Надо будет к ней стремиться потихоньку…
semenodm, кроме книги Гойко Аджича «Specification by Example», вы могли бы посоветовать еще что-то по этой теме?
Дело в том, что я интересуюсь Спецификацией через пример, и постепенно пополняю свою подборку по этой теме.
Так что если занимались внедрением SBE на своем проекте, прошу вас посоветовать несколько источников информации.
Дело в том, что я интересуюсь Спецификацией через пример, и постепенно пополняю свою подборку по этой теме.
Так что если занимались внедрением SBE на своем проекте, прошу вас посоветовать несколько источников информации.
Я честно сознаюсь что не читал эту книгу. Дело в том, что Гойко Аджич приезжал к нашему заказчику и консультировал его, кроме того к нам в Киев приезжал Craig Larman, и в течении спринта присутствовал на всех PBR и других Scrum Events.
Вот несколько моментов которые мне запомнились
1. Во время PBR заказчику советовали тестировать нас, то есть через каждые 5 минут заказчик задавал нам вопросы по SBE и мы на них отвечали, иными словами мы сами участвовали в их построении.
2. Старайтесь использовать tools и environment для совместного построения SBE — в нашем случае это был SmartBoard и… Google Docs. Звучит забавно, но вы можете совместно писать SBE именно там.
3. Используйте общий язык, который понятен, как заказчику так и вам, это было еще в DDD Эрика Еванса
4. От себя. SBE можно положить на исполняемые тестовые сценарии. Что я и пытаюсь продвинуть у себя в проекте
ЗЫ. подборка внушительная, нужно будет ознакомиться подробнее.
Вот несколько моментов которые мне запомнились
1. Во время PBR заказчику советовали тестировать нас, то есть через каждые 5 минут заказчик задавал нам вопросы по SBE и мы на них отвечали, иными словами мы сами участвовали в их построении.
2. Старайтесь использовать tools и environment для совместного построения SBE — в нашем случае это был SmartBoard и… Google Docs. Звучит забавно, но вы можете совместно писать SBE именно там.
3. Используйте общий язык, который понятен, как заказчику так и вам, это было еще в DDD Эрика Еванса
4. От себя. SBE можно положить на исполняемые тестовые сценарии. Что я и пытаюсь продвинуть у себя в проекте
ЗЫ. подборка внушительная, нужно будет ознакомиться подробнее.
Я очень рекомендую прочитать ту книгу Specification By Example, перед тем как начинать автоматизировать спецификацию. Дело в том, что там очень много чего раскладывается по полочкам.
Вот, например, Гойко пишет, что то Спецификация через пример (Specification By Example) – это больше процесс, цель которого создать наилучшее взаимодействие внутри команды и с заказчиками. А вот тот документ, который пишется всей командой и заказчиками вместе, на самом деле называется «спецификацией с примерами» (specification with examples), или живой документацией (living documentation). Автоматизация спецификации делает из нее запускаемую спецификацию (Executable specification).
Выходит, что венец сего творения стоит на трех Слонах. Спецификация с примерами – это спецификация для разработчика, тесты для тестировщика и этот документ как-бы можно легко автоматизировать. Только вот есть большая проблема. Все три слона тянут одеяло на себя.
Тестировщик не должен расширять спецификацию, детализируя ее дополнительными тестами.
Вместо этого, Гойко предлагает создать документ с той же структурой, где будут хранится дополнительные тесты.
А автоматизация не должна усложнять спецификацию лишними техническими деталями, как ID кнопок, например.
Если количество информации выйдет из достаточного в избыточное – это фейл.
Хорошие примеры спецификации можно посмотреть тут:
Concordion Hints and Tips
Вот, например, Гойко пишет, что то Спецификация через пример (Specification By Example) – это больше процесс, цель которого создать наилучшее взаимодействие внутри команды и с заказчиками. А вот тот документ, который пишется всей командой и заказчиками вместе, на самом деле называется «спецификацией с примерами» (specification with examples), или живой документацией (living documentation). Автоматизация спецификации делает из нее запускаемую спецификацию (Executable specification).
Выходит, что венец сего творения стоит на трех Слонах. Спецификация с примерами – это спецификация для разработчика, тесты для тестировщика и этот документ как-бы можно легко автоматизировать. Только вот есть большая проблема. Все три слона тянут одеяло на себя.
Тестировщик не должен расширять спецификацию, детализируя ее дополнительными тестами.
Вместо этого, Гойко предлагает создать документ с той же структурой, где будут хранится дополнительные тесты.
А автоматизация не должна усложнять спецификацию лишними техническими деталями, как ID кнопок, например.
Если количество информации выйдет из достаточного в избыточное – это фейл.
Хорошие примеры спецификации можно посмотреть тут:
Concordion Hints and Tips
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исследование через функциональное тестирование