Сообщений в теме: 25

[TMging]

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

[JimR]

Сумбурный текст, в который замешано сразу несколько разных вопросов.

Лучший способ - это использование Context-Driven Testing, источник: Семь основных принципов. В этом случае уж точно не ошибётесь.

Моё же мнение относительно Ваших вопросов следующее:
1. Да, нужно.
2. Безотносительно к теме треда могу сказать, что обычно исследователькое тестирование проводят, если остается свободное после остальных работ, которые были запланированы. А если уж очень сильно хочется, то планируйте как и все остальные работы: заранее. Прикиньте, какую область функционала/ПО ваша каоманда будет таким образом тестировать и сколько времени примерно это займет. И отразите это в плане тестирования.

[Vitekua]

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

точно так же. Просто девелоперы сначала пигут юнит тесты, а потом код. В идеале код получается более качественный, что не освобождает его от несоответствия спецификации, не выполнения функционала и т.д.

[Nadya Kochetova]

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

вот вы зря, на мой взгляд, говорите, что разработка вас не интересует.
попробую сейчас объяснить почему.
TDD может использоваться в методологих Agile. суть любой методологии Agile (их несколько) сводится к разработке ПО интерациями. Выглядит это примерно так (например): проект разбит на итерации. скажем, каждые 2 недели. в конце каждой второй недели заказчик должен получить ощутимый результат - продукт, с неработающими фичами, как правило, на начальных итерациях.
в понедельник все собрались, поняли что будет в сделано в новой итерации. и тут же все сели работать. разработчики- код писать (некоторые составляют decision table matrix), тестеры - писать скрипты (даже если они явно провалятся вначале) и т.д.

к концу итерации тестеры пытаются оттестировать то, что готово. подкорректировать скрипты, которые были созданы для предыдущих итераций.

в каждой итерации идет component testing (unit testing), integration (который тестирование взаимодейтсвие компонентов - функций, процедур и тд) testing.
если UI тестируем, то можно проводить Exploratory testing. однако как правило в коротких итерациях не хватает времени для него и его откладывают до той итерации, когда Ui нормализуется. а на начальних занимаются boundary analysis например. тестируют функционал формальными методами.

и тут же с самого начала тестеры проводят volume testing, stress testing и другие виды нефунк. тестирования, посколько это позволяет быстро отловить проблемы в коде, связанные с этим. иначе в конце рефакторинг кода приводит к новым ошибкам

[Alfa]

TDD может использоваться в методологих Agile.

Точнее TDD это инженерная практика XP (тут). Может использоваться где угодно, как угодно, кем угодно.

суть любой методологии Agile (их несколько) сводится к разработке ПО интерациями.

Ересь, но сжигать не будем. Суть любой гибкой(agile) методологии сводиться к манфесту гибкой разработки.

разработчики- код писать (некоторые составляют decision table matrix), тестеры - писать скрипты (даже если они явно провалятся вначале) и т.д.

А в некоторых гибких методологиях(Scrum) нет выделенных ролей, есть навыки(skills).

в каждой итерации идет component testing (unit testing), integration (который тестирование взаимодейтсвие компонентов - функций, процедур и тд) testing.
если UI тестируем, то можно проводить Exploratory testing. однако как правило в коротких итерациях не хватает времени для него и его откладывают до той итерации, когда Ui нормализуется. а на начальних занимаются boundary analysis например. тестируют функционал формальными методами.

В каждой итерации проводится такое тестирование, чтобы в конце итерации получить продукт для демонстрации (возможно и для использования) с увеличенной ценностью для бизнеса (business value). А как это сделать не важно.

и тут же с самого начала тестеры проводят volume testing, stress testing и другие виды нефунк. тестирования, посколько это позволяет быстро отловить проблемы в коде, связанные с этим. иначе в конце рефакторинг кода приводит к новым ошибкам

Рефакторинг с дольшой долей вероятности не приводит к новым ошибкам т.к. во первых часто это простая операция выполняемая средой разработки, во вторых все покрыто модульными тестами (TDD). Так же рефакторингом нельзя исправить ошибку, т.к. функциональность при этом не меняется (тут).

Изменение архитектуры может привести и приведет к новым ошибкам.

[Alfa]

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

Как можно понять из написанного тут (пункт Code the unit test first.) Разработка через тестирование относится к разработке, т.е. TDD это метод разработки ПО. Сильно сомневаюсь, что код написанный таким образом настолько специфичен, что нужны какие-то особые методы его тестирования. Даже если такие методы нужны, они затрагивают малую часть тестирования.
Тестируйте как обычно, главное чтоб все тесты, написанные разработчиками, всегда проходили. Я вот так думаю.

[LeshaL]

и тут же с самого начала тестеры проводят volume testing, stress testing и другие виды нефунк. тестирования, посколько это позволяет быстро отловить проблемы в коде, связанные с этим. иначе в конце рефакторинг кода приводит к новым ошибкам

Рефакторинг с дольшой долей вероятности не приводит к новым ошибкам т.к. во первых часто это простая операция выполняемая средой разработки, во вторых все покрыто модульными тестами (TDD). Так же рефакторингом нельзя исправить ошибку, т.к. функциональность при этом не меняется (тут).

Мне кажется, вы не совсем верно понимаете, что такое рефакторинг. Это не просто переименование класса или метода или перенос метода из класса в класс. Такие операции и вправду делаются с помощью IDE. Обычно называются Refactor->Rename и Refactor->Move. Но почему-то еще никто не придумал Refactor->Delete....
Нет никакой возможности с помощью IDE оптимизировать код внутри метода, чтобы сделать его более универсальным, быстрым итд. Переход от одного алгоритма к другому (например сортировки данных) делает человек. В этом случае, задача юнит-тестов подтвердить, что все отлично отрефакторилось. Тот случай о котором написала Надя.
Если же рефакторинг состоит в том (сейчас речь о Java), что надо несколько излишних классов превратить в методы одного класса, или наоборот излишне громоздкий класс разбить на несколько - то тут и юнит тесты написанные заранее не помогут -> их надо будет переписывать, а это уже может породить ошибки. Да и в IDE такого не видел, чтобы взяли метод и из него класс сделали, да еще и походу прихватили все нужные аттрибуты(поля).
Это все к тому, что рефакторинг, даже местячковый, очень даже может породить ошибки. Более того, иногда такие ошибки можно очень долго искать.
Вот хорошая книжка про рефакторинг.

[LeshaL]

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

Как можно понять из написанного тут (пункт Code the unit test first.) Разработка через тестирование относится к разработке, т.е. TDD это метод разработки ПО. Сильно сомневаюсь, что код написанный таким образом настолько специфичен, что нужны какие-то особые методы его тестирования. Даже если такие методы нужны, они затрагивают малую часть тестирования.
Тестируйте как обычно, главное чтоб все тесты, написанные разработчиками, всегда проходили. Я вот так думаю.

Полность согласен с Alfa. Применение TDD в разработке, может и должно привести к тому, что команде тестирование достанется поменьше багов, чем в случае если TDD не применяется. Не следует думать, что багов вообще нет. Просто разработчики найдут часть из них сами, еще на этапе написания кода. Плюс к TDD можно и нужно применять code audit. Это вообще не имеет никакого отношения к тому как происходит разработка TDD, Agile, XP, Scrum - без разницы. Применение аудита кода поможет еще снизить кол-во багов в коде и обнаружить их на этапе разработки. Многие IDE имеют встроеные аудиты и надо только слегка поменять процесс, чтобы разработчики были обязаны запускать аудит кода перед его комитом в репозиторий.

[Alfa]

Мне кажется, вы не совсем верно понимаете, что такое рефакторинг. Это не просто переименование класса или метода или перенос метода из класса в класс. Такие операции и вправду делаются с помощью IDE. Обычно называются Refactor->Rename и Refactor->Move. Но почему-то еще никто не придумал Refactor->Delete....

Фаулер придумал, а JetBrains реализовал (вот тут), называется «safe delete». Или это не то?

Нет никакой возможности с помощью IDE оптимизировать код внутри метода, чтобы сделать его более универсальным, быстрым итд.

А вот это не рефакторинг (цитирую википедию):

Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results.

Это все к тому, что рефакторинг, даже местячковый, очень даже может породить ошибки. Более того, иногда такие ошибки можно очень долго искать.
Вот хорошая книжка про рефакторинг.

Я написал:

Рефакторинг с большой долей вероятности не приводит к новым ошибкам

Где написано, что он не приводит к ошибкам нигде и никогда? Правильный рефакторинг к ошибкам вообще не приводит, но естественно можно провести и неправильный рефакторинг, который приведет в ошибкам. Вообщем как и везде.

[Alfa]

Это вообще не имеет никакого отношения к тому как происходит разработка TDD, Agile, XP, Scrum - без разницы.

:
Не ставьте в один ряд теплое и мягкое, TDD — практика; XP, Scrum — методологии; Agile — семейство методологий.

Применение аудита кода поможет еще снизить кол-во багов в коде и обнаружить их на этапе разработки. Многие IDE имеют встроеные аудиты и надо только слегка поменять процесс, чтобы разработчики были обязаны запускать аудит кода перед его комитом в репозиторий.

Ох уже эти обязательства. Поставьте сервер непрерывной интеграции и пусть он аудиты проводит (и модульные тесты тоже). После кучи сборок, сломанных из-за аудитов, разработчики сами все будут проверять и писать станут лучше. Т.е. изменения в процессе сами появятся, а не будут навязаны «сверху».

[LeshaL]

Фаулер придумал, а JetBrains реализовал (вот тут), называется «safe delete». Или это не то?

Не знал, что в Идее такое сделали. Молодцы. Я, по определенным причинам, Идеей никогда не пользовался, да уж наверное и не буду. Хотя, я думаю, для того, чтобы Safe Delete отработал, данный класс\метод не должен нигде использоваться. А этот вид рефакторинга должен сделать человек. А фича Find for usage - отнюдь не нова.

Нет никакой возможности с помощью IDE оптимизировать код внутри метода, чтобы сделать его более универсальным, быстрым итд.

А вот это не рефакторинг (цитирую википедию):

Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results.

С данным определением я совсем не согласен. Это один из аспектов рефакторинга, что код становится более удобочитаемым. Но это отнюдь не основной аспект. Согласитесь, что Refactor->Move и Safe Delete не для того, чтобы код стал читаться лучше.
Википедия не очень достоверный источник. Смотрим статью про TDD из википедии:
http://en.wikipedia....ven_development
Шаг 5. "Refactor code". Это еще один аспект рефакторинга кода. Сначала создали стаб метода, потом что-нибудь захардкоженое, потом полностью работоспособное. Я поэтому и написал, что вы не совсем верно понимаете, что такое рефакторинг. Спросите любого разработчика - он на пальцах объяснит, что он понимает под рефакторингом.
По мне, так рефакторинг - это изменения в работающем коде; в отличие от баг-фикса - изменения в коде вызваны багом. Так же рефакторингом нельзя назвать и добавление новой функциональности - т.к. рефакторинг ("переработка" по-русски наверное) не может быть применен к тому, чего еще нет. Это мое имхо, но почему-то мне кажется, что именно это и понимают под рефакторингом.

Я написал:

Рефакторинг с большой долей вероятности не приводит к новым ошибкам

Где написано, что он не приводит к ошибкам нигде и никогда? Правильный рефакторинг к ошибкам вообще не приводит, но естественно можно провести и неправильный рефакторинг, который приведет в ошибкам. Вообщем как и везде.

В том-то и дело, что "с большой долей вероятности" рефакторинг ничего не нарушит, если это переименование класса (но про classForName не стоит забывать). А другие аспекты рефакторинга, такие как очередная итерация в ХР при работе над классом\методом "с большой долей вероятности" не приведут к ошибке в случае если у вас есть unit-тесты для этого класса\метода. А рефакторинг с изменением архитектуры самый сложный, т.к. и юнит-тесты менять придется. Про архитектурные изменения вы написали примерно тоже самое, но почему-то вы не причисляете это к рефакторингу. Для меня это странно - ведь переезд метода из класса в класс уже есть изменение архитектуры.

[LeshaL]

Это вообще не имеет никакого отношения к тому как происходит разработка TDD, Agile, XP, Scrum - без разницы.

Не ставьте в один ряд теплое и мягкое, TDD — практика; XP, Scrum — методологии; Agile — семейство методологий.

Лень было писать много, так бы еще в ряд с "теплым" и "мягким" поставил бы и "громкое" и "зеленое" и "пушистое". Об этом и речь - применение аудитов кода совершенно не зависит от практик, методологий, подходов, распределенности команды разработчиков, скорости\сроков выполнения работ или опытности девелоперов. Их желательно применять всегда. Просто дополнительная уверенность в том, что разработчиком какие-то виды ошибок, допущены не будут. Причем можно применять и к коду юнит-тестов также.

Применение аудита кода поможет еще снизить кол-во багов в коде и обнаружить их на этапе разработки. Многие IDE имеют встроеные аудиты и надо только слегка поменять процесс, чтобы разработчики были обязаны запускать аудит кода перед его комитом в репозиторий.

Ох уже эти обязательства. Поставьте сервер непрерывной интеграции и пусть он аудиты проводит (и модульные тесты тоже). После кучи сборок, сломанных из-за аудитов, разработчики сами все будут проверять и писать станут лучше. Т.е. изменения в процессе сами появятся, а не будут навязаны «сверху».

Совершенно верно. Первыми в применении аудитов кода должны быть заинтересованы сами девелоперы. Самое простой способ заинтересовать - обязать. Например, можно так как вы советуете - код не прошел аудит - билд не построился. Разработчик будет вынужден в следующий раз запустить аудит кода локально, чтобы убедиться, что из-за него билд не поломается. При постоянном применении аудитов все заметят, что код прошедший аудит содержит меньше "дурацких" ошибок.
Вообще это из-за недостатка образования. Такие вещи при обущении разработчиков должны просто вбиваться в голову - наверное любое IDE имеет поддержку аудита кода + куча самостоятельных реализаций. Хочешь создавать более качественый код - используй аудиты! Еще более качественный - пиши юнит-тесты! Даже если это никто не обязывает делать.

[Alfa]

Code refactoring is any change to a computer program's code that improves its readability or simplifies its structure without changing its results.

С данным определением я совсем не согласен. Это один из аспектов рефакторинга, что код становится более удобочитаемым. Но это отнюдь не основной аспект. Согласитесь, что Refactor->Move и Safe Delete не для того, чтобы код стал читаться лучше. Википедия не очень достоверный источник.

Для того чтобы код стал проще :). Теперь буду цитировать Фаулера. Он для Вас авторитетный источник, я надеюсь. Цитирую http://refactoring.com/:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Since each refactoring is small, it's less likely to go wrong.

Вот именно это я и писал.

А рефакторинг с изменением архитектуры самый сложный, т.к. и юнит-тесты менять придется.

Изменение модульных тестов == изменение внешнего поведения. Вам так не кажется? Если произошло изменение внешнего поведения, то это не рефакторинг (по определению).

PS Есть подозрения, что мы ушли от темы первоначального поста.

[SALar]

TDD может использоваться в методологих Agile.

Точнее TDD это инженерная практика XP (тут). Может использоваться где угодно, как угодно, кем угодно.
* * *
И т. д.

Согласен с Alfa почти во всем.
Примечание. Если не ошибаюсь Agile это одновременно и отдельная методология и группа методологий. Так уж получилось исторически.

Кто сталкивался с Разработкой через тестирование? Собственно сам процесс разработки меня не интересует, а интересует как потом это тестировать. Т.е. нужно ли Integration и System тестирование в такой же мере как и при любой другой модели разработки? Я читала, что рекоммендуют Exploratory testing, а как это вообще планировать?
В общем, если у вас был опыт, делитесь

Стратегия тестирования строится во первых в зависимости от метрик качества продукта. Во вторых от текущей команды. Некое влияние оказывает платформа и выбранные инженерные практики.
TDD - одна из инженерных практик разработки. Так что не парьтесь. Эта практика конечно же окажет влияние на качество и, соответственно на план тестирования, но это влияние настолько мизерно по сравнению с остальными факторами, что им можно пренебречь.
Это способ разработки! А будет писать код брюнет или блондин, англичанин или немец, будет использоваться TDD или парное программирование - это примерно та же сказывается на плане тестирования как изменение рецепта супа в зависимости от марки электроплиты.

Exploratory testing - это один из видов деятельностей (как сейчас модно говорить, "активностей" ) тестировщиков. Идет перед собственно тестировнием. Часто идет перед написанием тест кейсов. По сути это знакомство с программой, которое приходится делать ввиду отсутствия документации хоть сколько нибудь приемлемого качества.

PS. Никто не мешает использовать TDD при разработке ПО по RUP или по ГОСТ.

[LeshaL]

PS Есть подозрения, что мы ушли от темы первоначального поста.

Да согласен, получился офтоп.

[Nadya Kochetova]

Exploratory testing - это один из видов деятельностей (как сейчас модно говорить, "активностей" ) тестировщиков. Идет перед собственно тестировнием. Часто идет перед написанием тест кейсов. По сути это знакомство с программой, которое приходится делать ввиду отсутствия документации хоть сколько нибудь приемлемого качества.

PS. Никто не мешает использовать TDD при разработке ПО по RUP или по ГОСТ.

если UI готов перед написанием тетс кейсов.
но насколько я могу судить по своему небольшому опыту, UI разрабатывается при любой методологии класса Agile параллельно с тем, когда пишутся тест кейсы.

[Nadya Kochetova]

итак, пытаюсь подытожить то, что было сказано по теме


TDD - это это метод разработки ПО.

TDD часто используется в Agile методологиях. Под Agile мы здесь понимали класс методологий разработки (куда входят Scrum, XP, Agile etc.)

Суть любой гибкой (agile) методологии сводиться к манфесту гибкой разработки и понятию итераций, где результатом каждой итерации является работающий (хоть и не полностью) продукт. В каждой итерации проводится такое тестирование, чтобы в конце итерации получить продукт для демонстрации (возможно и для использования) с увеличенной ценностью для бизнеса (business value).

Основное преимущество TDD значительно улучшенное качество кода.

сказали, что TDD можно использовать при RUP (но надо поискать больше информации)

методы: в зависимости от рисков и требований к качеству ПО.


я выбрала неправильно слово "рефакторинг" и дискуссии ушли в другом направлении. прошу за это прощение.

[SALar]

TDD - это это метод разработки ПО.

Был недостаточно точен.
Скорее не "метод разработки ПО", но "метод написания кода".

Суть любой гибкой (agile) методологии сводиться к манфесту гибкой разработки

Скорее, да.

... и понятию итераций, где результатом каждой итерации является работающий (хоть и не полностью) продукт. В каждой итерации проводится такое тестирование, чтобы в конце итерации получить продукт для демонстрации (возможно и для использования) с увеличенной ценностью для бизнеса (business value).

Однозначно, нет. Никто не мешает вести адаптивный (agile) проект чистым водопадом, без всяких итераций. Но это оффтопик.

Основное преимущество TDD значительно улучшенное качество кода.

Не думаю.

[Nadya Kochetova]

Однозначно, нет. Никто не мешает вести адаптивный (agile) проект чистым водопадом, без всяких итераций. Но это оффтопик.

а можно пример? или вы имеете в виду , что внутри каждой итерации тестирование проходит по каскадной модели?

Основное преимущество TDD значительно улучшенное качество кода.Не думаю.

что по вашему есть преимущество TDD тогда?

[Nadya Kochetova]

ну вот не верю, что Agile обходится без итераций
вот смотрите: из Петтихорда:

What is Agile Development?
Incremental, Iterative, Adaptive

Incremental

•Build a system gradually
•See the system grow
•Demonstrating progress

Iterative
•Multiple releases or check points during a project, each closer to the target
•Iterations include requirements development and testing
•Typical iterations are two weeks long
•Plan as you go

Adaptive
•Goals change based on lessons from prior iterations, feedback and business opportunities

в прикрепленном документе рекомендуемые виды тестирования при Agile

Прикрепленные файлы

•  agile.JPG   78,1К   39 Количество загрузок: