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

[Case]

Пособие для консалтеров, внедряющих автоматизацию тестирования ПО.

Для внедрения автоматизации тестирования ПО необходимы всего три вещи:

• Мотивация руководства
• Зафиксированный и работающий процесс тестирования
• Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Почему? Остальное под ссылкой »

[SALar]

Пособие для консалтеров, внедряющих автоматизацию тестирования ПО.

Для внедрения автоматизации тестирования ПО необходимы всего три вещи:

• Мотивация руководства
• Зафиксированный и работающий процесс тестирования
• Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Почему? Остальное под ссылкой »

Слав, уже вроде много раз говорилось, что автоматизированное тестирование это не только и столько тестирование через GUI, но в первую очередь модульное и компонентное тестирование. Для их внедрения условия будут другими.

Что же касается внедрения конкретно WR, RR, TestComplete и иже с ними, то первое, с чего надо начать это выяснить экономическую целесообразность.
И получается, что для внедрения автоматизации тестирования ПО (через GUI) необходимы всего три вещи:
1) Полные затраты на тестирование в фирме в год больше нескольких сотен тысяч долларов. Я полагаю, что задумываться имееет смысл при бюджете в год на тестинг от $100 000, а внедрять начинать при бюджетах от $500 000. Может быть конечно и меньше, но это очень специфическая ситуация.
2) Подобное внедрение ведет к изменению процесса создания софта. Сумма этих изменений должна иметь положительное сальдо. Так, например, в нашем текущем проекте мы вполне можем применять "автоматизированное тестирование". Для этого "всего лишь" нужно написать собственную ГИС. Но мы вот немного посчитали и решили, что это нецелесообразно.
3) Фирма должна "созреть". Дело в том, что управление портфелем проектов (а это точно проект) отнимает время топменеджмента. И если есть более эффективные способы увеличения прибыли (а они точно есть), то использовать нужно в первую очередь их. По моему скромному мнению этот период настает, когда инженеры, отработавшие в фирме 10-15 лет перестают быть экзотикой.

[KaNoN]

Слав, уже вроде много раз говорилось, что автоматизированное тестирование это не только и столько тестирование через GUI, но в первую очередь модульное и компонентное тестирование. Для их внедрения условия будут другими.

Автоматизированное тестирование - это тестирование, проводимое автоматически. Это если уж совсем абстрагироваться. И под автоматизированным тестированием по умолчанию подразумевают не сколько непосредственно тестирование через ГУИ, сколько просто функциональное тестирование, а зачастую ту его часть, которая принимает участие в регрессионном тестировании. Все потому, что модульное и компонентное тестирование проверит соответствие работы кода спецификациям. Но бизнес-логику, причем в том виде, в котором это будет видеть потенциальный потребитель, никакое модульное или компонентное тестирование не проверит. Не тот уровень абстракции.

Что же касается внедрения конкретно WR, RR, TestComplete и иже с ними, то первое, с чего надо начать это выяснить экономическую целесообразность.
И получается, что для внедрения автоматизации тестирования ПО (через GUI) необходимы всего три вещи:
1) Полные затраты на тестирование в фирме в год больше нескольких сотен тысяч долларов. Я полагаю, что задумываться имееет смысл при бюджете в год на тестинг от $100 000, а внедрять начинать при бюджетах от $500 000. Может быть конечно и меньше, но это очень специфическая ситуация.

Что-то слишком много специфических ситуаций мне попадается. Вы в указании цифр делайте поправку на регион, на приложение, которое надо тестировать и т.п. Есть приложения, для которых автоматизация внедряется годами. Но наряду с этим есть и мельче проекты, где автоматизация занимает пару месяцев. Опять же, конфигурационноле тестирование - один из ярких примеров задач, которые много времени на внедрение не занимают, но ускоряют процесс значительно. Просто в качестве примера - есть набор тестов (штук 50), которые надо прогнать примерно на 300 конфигурациях (различные сочетания вида "браузер - ОС - СУБД - Веб Сервер"). Ставится такое тестирование пару месяцев + пара недель на обкатку, чтоб удостовериться, что все работает нормально. При этом такие тесты можно запускать параллельно. Правильный подбор средств тестирования может
резко снизить затраты на те же лицензии. А теперь посчитайте, сколько будет длиться такое конфигурационное тестирование, если его проводить вручную?

2) Подобное внедрение ведет к изменению процесса создания софта. Сумма этих изменений должна иметь положительное сальдо. Так, например, в нашем текущем проекте мы вполне можем применять "автоматизированное тестирование". Для этого "всего лишь" нужно написать собственную ГИС. Но мы вот немного посчитали и решили, что это нецелесообразно.

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

3) Фирма должна "созреть". Дело в том, что управление портфелем проектов (а это точно проект) отнимает время топменеджмента. И если есть более эффективные способы увеличения прибыли (а они точно есть), то использовать нужно в первую очередь их. По моему скромному мнению этот период настает, когда инженеры, отработавшие в фирме 10-15 лет перестают быть экзотикой.

Когда объем задач начинает превышать "пропускную способность" людей, которые эти задачи выполняют, то пожалуй стоит задуматься над тем, как с них снять нагрузку. Вся эта возня с автоматизацией как раз и происходит из-за того, что людей на все задачи может нехватать, а зачастую и нехватает. И это не специфические случаи. Вот поэтому как-то и тестирование через ГУИ вспоминается и все прочее. Более низкоуровневые виды тестирования просто позволят уменьшить количество ошибок програмной реализации, но не логики приложения, а вот это проверяется на более высоком уровне.

[SALar]

Все потому, что модульное и компонентное тестирование проверит соответствие работы кода спецификациям. Но бизнес-логику, причем в том виде, в котором это будет видеть потенциальный потребитель, никакое модульное или компонентное тестирование не проверит. Не тот уровень абстракции.

Собственно, именно компонентное тестирование применяется именно для тестирования бизнес логики. В SOA на этом вообще можно построить значительную часть тестинга. И VS2005 очень неплохой инструмент для компонентного тестирования. Конечно имеет свои недостатки по сравнению с тем же nUnit. Но имеет и свои плюсы. Это примерно равные инструменты. Человек работающий на такой автоматизации должен быть очень много "немного" кодером.
Кстати, неплохая тема для статьи: "Преимущества скрамовской кроcсфункциональности по сравнению с жестким делением программист-тестер при внедрении компонентного тестирования". На порядок более полезная, чем "проблемы внедрения Rational Robot". Сам бы с удовольствием почитал.

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

Согласен. Действительно для тонких клиентов попроще, и уровень зарплаты важен.
Давайте так перепишу. Приведенные мной усредненные цифры верны для:
а) толстого клиента
б) уровень цен - Москва 2007
в) среднемосковского уровня зрелости софтверных компаний на 2007 год
г) малой доли конфигурационных тестов

Просто в качестве примера - есть набор тестов (штук 50), которые надо прогнать примерно на 300 конфигурациях (различные сочетания вида "браузер - ОС - СУБД - Веб Сервер"). Ставится такое тестирование пару месяцев + пара недель на обкатку, чтоб удостовериться, что все работает нормально. При этом такие тесты можно запускать параллельно. Правильный подбор средств тестирования может
резко снизить затраты на те же лицензии. А теперь посчитайте, сколько будет длиться такое конфигурационное тестирование, если его проводить вручную?

Хороший пример. Ортогональную матрицу пробовали применять?
Вручную такой тестинг действительно займет очень много времени. Дня два. Может даже неделю. Естественно только прогон, без подготовки стендов. Это если на тестинге занят только один человек. Если же на тестинге сидит несколько человек, то разумно с самого начала давать разным инженерам разные стенды, что очень серьезно сокращает затраты на конфигурационное тестирование.

Немного лирики. На прошлом проекте, я сделал именно так. Как результат - дополнительные накладные расходы мы имели только на установку стендов (этих расходов по любому не избежать). Конечно конфигураций у нас немного было. Но тем не менее. Я до сих пор горжусь качеством выпущенного продукта. Это был без всяких дураков продукт редкого качества.

Но в целом вы правы. Для Яндекса имеет смысл задумываться об автоматизации конфигурационного системного тестирования. Не обязательно внедрять, но задуматься можно. Правда у них и затраты на тестинг в год довольно приличные. И компания у них по среднероссийским меркам зрелая.

Когда объем задач начинает превышать "пропускную способность" людей, которые эти задачи выполняют, то пожалуй стоит задуматься над тем, как с них снять нагрузку. Вся эта возня с автоматизацией как раз и происходит из-за того, что людей на все задачи может нехватать, а зачастую и нехватает. И это не специфические случаи. Вот поэтому как-то и тестирование через ГУИ вспоминается и все прочее. Более низкоуровневые виды тестирования просто позволят уменьшить количество ошибок программной реализации, но не логики приложения, а вот это проверяется на более высоком уровне.

Это точно. Стоит. Задуматься. Только начинать нужно не с автоматизации. Ликвидация хаоса в управлении требованиями позволяет очень сильно разгрузить тестировщиков. Гораздо сильнее чем автоматизация. Это просто несопоставимые цифры. А уж постановка практики целеполагания приносит просто таки неприличные дивиденты.
В конце концов просто пошлите тестировщиков на курсы русского языка. Пользы в разы больше, А то будет как Александр написал http://software-test...showtopic=10807. Четверть ошибок отклонена! Четверть! А пропущено сколько! А вы еще WR этим людям доверите. От это будет нумер. Примерно как оленевод в цехе машиностроительного завода [1].

----------------------------
[1] История не выдумана. Действительно оленевод. Без переобучения. Машиностроительный завод выпускает формы для отливки строительных блоков. Так что покупая квартиру в новостройке вспомните этого скромного труженика по разведению оленей. Может быть и в вашей квартире есть часть его труда. Счастливого новоселья!

[KaNoN]

Все потому, что модульное и компонентное тестирование проверит соответствие работы кода спецификациям. Но бизнес-логику, причем в том виде, в котором это будет видеть потенциальный потребитель, никакое модульное или компонентное тестирование не проверит. Не тот уровень абстракции.

Собственно, именно компонентное тестирование применяется именно для тестирования бизнес логики. В SOA на этом вообще можно построить значительную часть тестинга. И VS2005 очень неплохой инструмент для компонентного тестирования. Конечно имеет свои недостатки по сравнению с тем же nUnit. Но имеет и свои плюсы. Это примерно равные инструменты. Человек работающий на такой автоматизации должен быть очень много "немного" кодером.
Кстати, неплохая тема для статьи: "Преимущества скрамовской кроcсфункциональности по сравнению с жестким делением программист-тестер при внедрении компонентного тестирования". На порядок более полезная, чем "проблемы внедрения Rational Robot". Сам бы с удовольствием почитал.

Ну-ну, а как это компонентное тестирование покроет функционал для тех же CAD приложений (а такие системы тоже неслабыми бывают)?
Зачастую сама отрисовка очень хорошо зарыта. Опять же, если не затрагивать интерфейс, то как мы узнаем, что пользователь увидит результаты своей работы? Пусть на уровне ядра оно и работает, но если это ядро не связано с интерфейсом - зачем оно нужно.

Другой пример. Веб-страницы. Некоторые модули отвечают тупо за отрисовку. Как вы проверите корректность их работы, не затрагивая ГУИ? А что делать с различными визуальными эффектами, которые присутствуют на веб-странице? А как проверить, что при том же выборе элемента из выпадающего списка, подгрузится какой-то фрагмент страницы? Причем визуально будут определенные реквизиты?

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

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

Согласен. Действительно для тонких клиентов попроще, и уровень зарплаты важен.

Давайте так перепишу. Приведенные мной усредненные цифры верны для:
а) толстого клиента

Толщина клиента - тоже вещь субъективная.

б) уровень цен - Москва 2007

О! Считайте, что уже коефициент 2 по зп как минимум.

в) среднемосковского уровня зрелости софтверных компаний на 2007 год

Что-то "среднюю температуру по палате". Ну да ладно.

г) малой доли конфигурационных тестов

Ну так есть и другие виды тестов. Та же регрессионка. Напомню, заказчик работает с приложением через ГУИ или другой внешний интерфейс, а не на уровне кода. И если он и найдет ошибки, то именно через пользовательский интерфейс.

[KaNoN]

Просто в качестве примера - есть набор тестов (штук 50), которые надо прогнать примерно на 300 конфигурациях (различные сочетания вида "браузер - ОС - СУБД - Веб Сервер"). Ставится такое тестирование пару месяцев + пара недель на обкатку, чтоб удостовериться, что все работает нормально. При этом такие тесты можно запускать параллельно. Правильный подбор средств тестирования может
резко снизить затраты на те же лицензии. А теперь посчитайте, сколько будет длиться такое конфигурационное тестирование, если его проводить вручную?

Хороший пример. Ортогональную матрицу пробовали применять?

Ну вообще-то она там уже заряжена.

Вручную такой тестинг действительно займет очень много времени. Дня два. Может даже неделю. Естественно только прогон, без подготовки стендов.

На всех 300 конфигурациях? Это если каждая конфигурация проверяется за 5 минут. Но вот прикол в том, что каждый тест выполняется примерно за 5-10 минут, а их всего 50 (я выше писал). То есть 250 - 500 минут, а это уже 1-2 рабочих дня на одну конфигурацию. А конфигураций 300.
Так что будем считать ваши расчеты времени на подобную задачу шуткой.

Когда объем задач начинает превышать "пропускную способность" людей, которые эти задачи выполняют, то пожалуй стоит задуматься над тем, как с них снять нагрузку. Вся эта возня с автоматизацией как раз и происходит из-за того, что людей на все задачи может нехватать, а зачастую и нехватает. И это не специфические случаи. Вот поэтому как-то и тестирование через ГУИ вспоминается и все прочее. Более низкоуровневые виды тестирования просто позволят уменьшить количество ошибок программной реализации, но не логики приложения, а вот это проверяется на более высоком уровне.

Это точно. Стоит. Задуматься. Только начинать нужно не с автоматизации. Ликвидация хаоса в управлении требованиями позволяет очень сильно разгрузить тестировщиков. Гораздо сильнее чем автоматизация. Это просто несопоставимые цифры.

Ну и как это разгрузит, если просто работы по прогону тестов валом? А автотесты можно пускать на специальном сервере и тесты могут работать круглые сутки, причем на их поддержку уже не нужно искать высококвалифицированного специалиста. И самое главное - один человек, а не толпа народу.

А уж постановка практики целеполагания приносит просто таки неприличные дивиденты.
В конце концов просто пошлите тестировщиков на курсы русского языка.

А это тут причем? Я говорил о том случае, когда просто не получится держать ту толпу народу, которая могла бы выполнить нужный объем работ в нужный срок. Не забывайте, что та же Россия по численности несколько уступает Индии и Китаю.

Пользы в разы больше, А то будет как Александр написал http://software-test...showtopic=10807. Четверть ошибок отклонена! Четверть! А пропущено сколько! А вы еще WR этим людям доверите.

Конкретно мануальщикам автомат я бы в руки не давал сразу, это верный способ загубить автоматизацию на корню. Я уже об этом высказывался и судя по всему вы именно с подобной ошибкой столкнулись, что вы так фанатично придерживаетесь мнения, что автоматизировать тестирование на уровне ГУИ бессмысленно. Естественно, есть задачи, когда лучше "ну его нафик". Пример, как-то дали приложение, написанное на Флеше. Тестов было слишком много, чтоб это все руками проходить. Поэтому решили подумать, как бы это всё дело автоматизировать. Так получилось, что из опробованных средств с флешем подружился только ТестКомплит. Но я потом глянул, как объекты распознаются, как с ними работает ТестКомплит и кого потом посадят тесты автоматизировать (ручника ), и решил что это дохлый номер. Это реально случай, когда автоматизация не прокатит.

[Boltick]

Доброго времени суток, Господа.

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

На счет экономической целесообразности я согласен на 100% - это бесспорно.
думаю, что если компания согласилась нанять 10 тестеров для тестирования продукта, то немного "экономически обосновав" можно убедить ее нанять 5 или 6 тестеров, из которых половина будет заниматься автоматизированным тестированием, а вторая - ручным. Думаю, что в итоге все выйдет не хуже, и при тех же затратах. (конечно при условии достаточной квалификации тестеров и их манагера)

Недавно Слава выкладывал статью "Менеджер проектов по тестированию" Там говорилось о разнице между менеджерами и в итоге о вере в людей. Так вот, здесь таже картина. Иногда чтобы начать что-то делать, надо просто сесть и начать, и результат не заставит себя ждать.

[KaNoN]

Доброго времени суток, Господа.

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

Ну, не совсем. Я на реальных примерах показывал задачи, которые так или иначе придется автоматизировать, иначе люди этот объем работ в приемлемые сроки не сделают или нужно будет нагнать много народу.

На счет экономической целесообразности я согласен на 100% - это бесспорно.
думаю, что если компания согласилась нанять 10 тестеров для тестирования продукта, то немного "экономически обосновав" можно убедить ее нанять 5 или 6 тестеров, из которых половина будет заниматься автоматизированным тестированием, а вторая - ручным. Думаю, что в итоге все выйдет не хуже, и при тех же затратах. (конечно при условии достаточной квалификации тестеров и их манагера)

Во, вот тут вот вопрос квалификации. И мы его выше немного затронули.

Недавно Слава выкладывал статью "Менеджер проектов по тестированию" Там говорилось о разнице между менеджерами и в итоге о вере в людей. Так вот, здесь таже картина. Иногда чтобы начать что-то делать, надо просто сесть и начать, и результат не заставит себя ждать.

Есть случаи, когда реально видно, что и начинать не стоит. Если неминуемый провал задачи можно предвидеть, то можно заблаговременно за эту задачу не браться. Буквально в предыдущем моем посте в этой теме я приводил подобный пример, только в другом контексте (последний абзац).

[Case]

Слав, уже вроде много раз говорилось, что автоматизированное тестирование это не только и столько тестирование через GUI, но в первую очередь модульное и компонентное тестирование. Для их внедрения условия будут другими.

1. Про то что в первую очередь, а что во вторую я бы поспорил. Unit это вообще не к тестерам, это к девелоперам - вот пусть и внедряют.
2. Модульное и компонентное - это что? Unit это модульное - а компонентное в оригинале?

Теперь по сути: что из мной перечисленного не нужно для внедрения "модульного и компонентного" тестирования и какие там будут другие условия?

[Green]

Коллеги!

хочу перевести ваш диалог к простым и понятным условиям реальной жизни.

У меня существует только один критерий, на основании которого можно внедрять автоматизацию, а именно:

- если у вас есть возможность выделить на full time хотя бы одного инженера для разработки, отладки, запуска, обновления и актуализации тестовых скриптов, то "семь футов под килем"; если нет, то с автоматизацией у вас ничего не выйдет.

Только после этого можно рассуждать, что именно и в каком объеме, в каком порядке, по какой методике, каким средством нужно автоматизировать.

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

[a66at]

Про то что в первую очередь, а что во вторую я бы поспорил.

Ну давайте, спорьте. SALar, видимо имел в виду, что в современных системах дефекты GUI самые дешёвые в исправлении, поэтому не стоит на них концентрироваться слишком сильно. Не говоря уже о централизованных системах со всякими интеллектуальными терминалами (банкоматами там, мобильными телефонами), в которых, может статься бизнес логику не получится вообще через GUI протестировать. SOA он тоже, кажется, упоминал.

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

[KaNoN]

Про то что в первую очередь, а что во вторую я бы поспорил.

Ну давайте, спорьте. SALar, видимо имел в виду, что в современных системах дефекты GUI самые дешёвые в исправлении, поэтому не стоит на них концентрироваться слишком сильно. Не говоря уже о централизованных системах со всякими интеллектуальными терминалами (банкоматами там, мобильными телефонами), в которых, может статься бизнес логику не получится вообще через GUI протестировать. SOA он тоже, кажется, упоминал.

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

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

Скорее меньшей компетентности в данном вопросе. Все-таки разработчику лучше знать, какие средства использовать, чтобы проверить тот или иной функционал, особенно если четких спецификаций на руки не дают. Опять же, Test-driven development - неплохая практика. Да и к тому же все-таки немного другой набор скилов нужен.

[KaNoN]

Коллеги!

хочу перевести ваш диалог к простым и понятным условиям реальной жизни.

У меня существует только один критерий, на основании которого можно внедрять автоматизацию, а именно:

- если у вас есть возможность выделить на full time хотя бы одного инженера для разработки, отладки, запуска, обновления и актуализации тестовых скриптов, то "семь футов под килем"; если нет, то с автоматизацией у вас ничего не выйдет.

Только после этого можно рассуждать, что именно и в каком объеме, в каком порядке, по какой методике, каким средством нужно автоматизировать.

В принципе да. Без людей тут никак.

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

Я бы скорее делал вывод из соотношения времени, требуемого на автоматизацию тестирования, к времени существования проекта. Если, допустим, тот же проект на три месяца можно автоматизировать за неделю (а такое возможно, если структура приложения хорошо вписывается в организацию фреймворка), то почему бы нет? Опять же, там нужно оценить затраты. На этапе постановки автоматизации идут сплошные затраты, а со временем эти затраты компенсируются за счет выигрыша по времени при использовании автоматических тестов. И если эти затраты окупаются не к концу проекта, а несколько ранее, то это уже наводит на мысль, что можно что-то делать, но тут уже на усмотрение менеджмента. Ради тех же 20% выигрыша не все готовы бросить достаточно большие усилия. Эффект должен быть несколько повыше, чтоб затраты на автоматизацию были действительно оправданными.

[Case]

Второй критерий - размер (сроки) проекта. Если проект на три месяца и на полтора разработчика, то в автоматизации смысла нет.

Серёг, а если проект по какой-то там классификации идёт как 4D? Ну банально выводить картинку движения самолётов с терминала А на терминал В - делов на полтора месяца - но требования по надёжности 99,999% uptime. Так что я бы ещё как минимум убытки от простоя добавил - кстати так и считают зачастую в случае внедрения средств нагрузочного тестирования.

[Case]

Ну давайте, спорьте

С удовольствием, только не с вами - ибо безыдейно :) У вас на меня аллергия, видимо.

Про внедрение автоматизации функциорнального тестирования (GUI / record-playback) бесполезно говорить без простых и понятных входных данных (количество автоматизируемых сценариев, кол-во окружений, кол-во версий*тестовых окружений - прогонов и т.д.), которые можно легко всунуть в калькулятор ROI и получить ответ "окупится или нет". С нагрузочным сложнее - хотя тоже считается, хотя и опосредственно через потери.

А вот если кто-то посчитает и покажет как он это сделал, что от внедрения unit-тестирования сэкономили n% ресурсов на тестирование я готов внимательно посмотреть и поговорить крайне вдумчиво.

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

Ой, давайте не будем меня так дешево подкалывать? :) Я вас лично звал в проект по нагрузочному тестированию в котором вы заявляете компетенцию экспертного уровня и что? Вы как обычно надули губы и стали в позу "видали мы таких бизнесменов" - и кто после этого может кого подкалывать про "неспособность"? :) Кто может - тот пошёл и сделал.

Теперь по существу, если у кого-то есть желание поспорить. Unit тестирование выполняется девелопером как часть работ по обеспечению целосности кода и гарантий по её (целосности) сохранению при внесении изменений. Код - артефакт, за который отвечает девелопер, продукт его труда - его задача обеспечение его качества. Контроль на тестерах, меры по продавливанию этих практик на QA.

Сообщение отредактировал Case: 24 января 2008 - 08:16
"upper intermediate" -> эксперт

[Case]

Скорее меньшей компетентности в данном вопросе. Все-таки разработчику лучше знать, какие средства использовать, чтобы проверить тот или иной функционал, особенно если четких спецификаций на руки не дают. Опять же, Test-driven development - неплохая практика. Да и к тому же все-таки немного другой набор скилов нужен.

Не только, толковых тестеров с большей отдачей я на ревью ставил, а не на утирание соплей нерадивым девелоперам.

[LeshaL]

Теперь по существу, если у кого-то есть желание поспорить. Unit тестирование выполняется девелопером как часть работ по обеспечению целосности кода и гарантий по её (целосности) сохранению при внесении изменений. Код - артефакт, за который отвечает девелопер, продукт его труда - его задача обеспечение его качества. Контроль на тестерах, меры по продавливанию этих практик на QA.

Есть желание, но не то чобы поспорить, а подискутировать. Вот о чем. Раз девелоперы пишут юнит-тесты, значит они задумываются о качестве производимого кода. Значит им на это отводится время. Значит это часть процесса. Значит QA должен это контролировать, чтобы работа и время на нее потраченое не были бессмыслены.
Вот то, что девелоперы делать не будут:
- прогонять эти юнит-тесты, измеряя насколько они покрывают код. Из этого можно сделать какие-то выводы.
- посчитать цикломатическую сложность или другие метрики, коих много. Посмотреть, какие же методы покрыты юнит-тестами.

А вот если кто-то посчитает и покажет как он это сделал, что от внедрения unit-тестирования сэкономили n% ресурсов на тестирование я готов внимательно посмотреть и поговорить крайне вдумчиво.

Скорее всего - это невозможно. Если на тестирвание есть N ресурсов, то они все будут потрачены, внезависимости от того пишутся юнит-тесты или нет. А вот увеличить качество кода и обнаружить дефекты, которые тяжело или невозможно найти проводя "ручное" тестирование - возможно. Так же, вероятно, если код лучше и изначально содержит меньше ошибок, то тестеры потратят меньше времени на тестирование. Т.к. меньше времени уйдет на исследование, написание и верификацию багов. Больше будет времени на какие-то другие тесты, которые, в противном случае, попросту не будут проведенены.

[a66at]

С удовольствием, только не с вами - ибо безыдейно :) У вас на меня аллергия, видимо.

Ой, да ради бога.

А вот если кто-то посчитает и покажет как он это сделал, что от внедрения unit-тестирования сэкономили n% ресурсов на тестирование я готов внимательно посмотреть и поговорить крайне вдумчиво.

Простой пример. Вспомните, как Вы сами возились со своим rss фидом. Там надо было конечно не файлы сравнивать, а дебаггером несколько раз пробежать. :) То же самое с unit-тестированием. Впрочем, это действительно вопрос экспов, я полным полно инцидентов видел (и функциональных), которые через GUI невозможно отловить, и очень дорогостоящих. И типичный тестировщик даже не стал бы никаких усилий предпринимать для их предотвращения, потому что у него своя методология и инструментарий, которые для этого по его мнению не предназначены. Так и получается, что тестирование есть, а качества нет.

[Case]

Есть желание, но не то чтобы поспорить, а подискутировать. Вот о чем. Раз девелоперы пишут юнит-тесты, значит они задумываются о качестве производимого кода. Значит им на это отводится время. Значит это часть процесса. Значит QA должен это контролировать, чтобы работа и время на нее потраченое не были бессмыслены.
Вот то, что девелоперы делать не будут:
- прогонять эти юнит-тесты, измеряя насколько они покрывают код. Из этого можно сделать какие-то выводы.
- посчитать цикломатическую сложность или другие метрики, коих много. Посмотреть, какие же методы покрыты юнит-тестами.

Согласен. Вопрос применимости практики - вопрос качества и зрелости процесса разработки, вопрос QA, если он есть, тест лида если у него хватает убедительности, а по большому счёту дев лида, если у него хватает опыта в понимании, что это есть правильно.

[Case]

Простой пример. Вспомните, как Вы сами возились со своим rss фидом. Там надо было конечно не файлы сравнивать, а дебаггером несколько раз пробежать. :)

Как раз пример неудачный, я ламер, который вынужденно занимается прикручиванием чего-то к сайту и форуму, просто потому что у него шило в одном месте - тут вообще речь не идёт о разработке, чистейшая кустарщина и "наколенчина". Трабл был не в файлах, а в том, как я их заливал-перезаливал (что-то в файл менеджере с режимами передачи сбилось, вот и добавлялись непонятные символы в начало 2 файлов): девелопер, которого я привлёк починил минут за 5.

То же самое с unit-тестированием. Впрочем, это действительно вопрос экспов, я полным полно инцидентов видел (и функциональных), которые через GUI невозможно отловить, и очень дорогостоящих. И типичный тестировщик даже не стал бы никаких усилий предпринимать для их предотвращения, потому что у него своя методология и инструментарий, которые для этого по его мнению не предназначены. Так и получается, что тестирование есть, а качества нет.

Виктор, я в целом понял (наверное) что вы сказали и думаю, что согласен, только не совсем понял как это к теме "когда и при каких условиях надо внедрять автоматизацию". Я без наезда, просто или я не до конца понял вашу мысль, либо это уже просто ветка ушла в сторону.