Я не знаю, для чего уж там создавалась практика (Вы по-моему уже за процессами самой работы не видите), но само модульное тестирование - это тестирование - проверка: работает как надо/не работает. Если другого способа проверить этого нет, или он сложнее, то я буду использовать модульное тестирование. Подумайте сами, тестировались ли программы до того как появились пользовательские интерфейсы? :)Добавлю про unit-тестирование на этапе приёмки.
Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.
Что необходимо для внедрения автоматизации тестирования ПО
#41
Отправлено 25 января 2008 - 11:15
#42
Отправлено 25 января 2008 - 12:56
"Ну вы блин даёте!" (с) Особенности национальной рыбалки :)Про "дорогих консалтеров" отсюда: http://software-test...a...ost&p=39704 :)
Там даже дата стоит: 8.3.2007 - год назад дело было, название и направленность ресурса успела поменяться. Я сам сейчас не в тестировании работаю, а тестирование для меня по прежнему крайне интересная область в которой я могу оказывать консультационные услуги в частном порядке и ни более.
Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?Что я пытаюсь доказать, я ясным образом уже дал понять - я поддерживаю уже упомянутый тезис SALar-а.
Ахренеть как всё закопано :) Давайте в следующий раз с этого начнём? :)Говорите, что автоматизация тестирования не столько GUI и я немедленно отвалю.Что автоматизация тестирования не только GUI? Да, не только. И что?
Сам мой ответ ниже.
Вы уже как-то пробовали, когда проводили конкурс на тренинг по нагрузке. Конкурс я помнится выиграл - ощущение относительно моего опыта резко поменялось? :)Пока что из серьёзных аргументов от Вас слышно только аппеляции к личному опыту, о котором надо спрашивать отдельно. :)
Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.Послушайте, мы тут, кажется обсуждаем методику, которую можно тиражировать, или если Вы какую-то другую цель своей статьёй преследовали, то так и скажите, а то я слегка дезориентирован.К вопросу про то что я не могу оценить вклад - да не вклад, а выхлоп.
Получается что слишком сложные, сдаюсь! Вы слишком изощрённый критик раз я не могу понять где собственно критика. По-моему вы зацепились за мой тезис "что в первую очередь, я бы ещё поспорил", нет?Я пишу о том, что Ваше описание синтетического тестирования у меня возражений не вызывает и потом на этой основе перехожу к критике самой статьи с точки зрения, заданной замечанием SALar-а. Я не слишком сложные для Вас манёвры делаю? :)
Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.
Для внедрения автоматизации тестирования ПО необходимы всего три вещи:
Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».
- Мотивация руководства
- Зафиксированный и работающий процесс тестирования
- Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела
А, теперь дошло. Не закапывайте смысл, а? :)В контексте статьи об автоматизации тестирования, заявление о том что нельзя автоматизировать то, что не существует, я посчитал эквивалентным утверждению: "Нельзя автоматизировать тестирование, если не существует тестирования (требований, тест-кейсов)". Привёл контрпример. Что Вы в статье на самом деле имели в виду? Что нельзя автоматизировать бизнес, если нет бизнеса? Что нельзя автоматизировать IT-систему, если нет системы?
Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.
При этом unit-тестирование программисты могут и должны делать. Само Unit-тестирование я отношу к практикам создания и отладки кода, а не к процессу тестирования, как к проверке реализованной в коде функциональности на соответствие зафиксированным требованиям.
Редактор портала www.it4business.ru
#43
Отправлено 25 января 2008 - 14:23
Да, с уточнением. Это, конечно, зависит от специфики, но мне показалось, что раз Вы пожелали спорить на эту тему, то у Вас есть какие-то аргументы общего применения против этой позиции, кроме терминологических увёрток, или за противоположную и Вы хотите ими поделиться.Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?
Давайте в следующий раз с этого начнём? :)
Приведите пожалуйста, с чего мы в этот раз начали. Я как-то не улавливаю разницы.
Тут уже, ИМХО, софистика зарождается. Предлагаю оставить способ использования статьи и комментариев на усмотрение читателя. Если хотите, уберу хинт об использовании её как методики которую можно (по форме) тиражировать.Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.
Моё сообщение от 10:48.Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.
1. Мотивация руководства
2. Зафиксированный и работающий процесс тестирования
3. Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела
4. Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».
1. Задан уточняющий вопрос о мотивации руководства;
2. Про процессы - контрпример и уточняющий вопрос про процесс тестирования (его окружение).
4. Альтернативная гипотеза о причинах провала таких проектов (при соблюдении Ваших условий всё равно возможен провал, без некоторых из них возможен успех).
Мне уже пора. Я не уловил в Ваше статье перехода от обобщенных критериев успеха внедрения автоматизации тестирования к оправданности использования или неиспользования для этого САТ.А, теперь дошло. Не закапывайте смысл, а? :)
Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.
Процесс тестирования в Вашей терминологии возможно и нельзя будет автоматизировать, если его нет, но тестирование (активности) конечно можно автоматизировать сразу, без их предварительного существования, а статья ведь про автоматизацию тестирования (название даже соответствующее).
Вообще, я придерживаюсь мнения что автоматизация процесса тестирования - это workflow, в данном случае bugtracker, а автоматизация тестирования - это автоматическое выполнение проверок.
#44
Отправлено 25 января 2008 - 14:37
необходимы всего
Это "необходимо и достаточно"?
#45
Отправлено 25 января 2008 - 15:39
Редактор портала www.it4business.ru
#46
Отправлено 25 января 2008 - 15:46
Опять же, Test-driven development - неплохая практика. Да и к тому же все-таки немного другой набор скилов нужен.
Теперь по существу, если у кого-то есть желание поспорить. Unit тестирование выполняется девелопером как часть работ по обеспечению целосности кода и гарантий по её (целосности) сохранению при внесении изменений. Код - артефакт, за который отвечает девелопер, продукт его труда - его задача обеспечение его качества. Контроль на тестерах, меры по продавливанию этих практик на QA.
Немного оффтопика.
В результате исследований у меня получилось следующее:
* Практик юнит тестирования (оно же модульное) существует несколько
* Практика TDD (разработка ведомая тестированием) не подразумевает поиск ошибок. Она применяется для другогого. Более того, исходя из идеоологии этой практики программист не должен беспокоиться о полноценном тестовом покрытии. Следовательно, если все делать правильно, то в тестируемом классе могут встречаться, и часто действительно встречаются ошибки. TDD есть прием разработки, а не контроля качества. В TDD создание и кодирование тестов есть задача кодера, который разрабатывает именно этот класс.
* Практика Test First напротив предполагает контроль качества разрабатываемой функции или класса. Эта практика резко отличается от TDD. И здесь на стадии разработки тестовых сценариев желательно привлечение тест аналитика. Данная практика хорошо подходит для тестирования отдельных сложных функций. В своей статье "тривиальная задача" я описывал практику Test First.
Есть возражения по определениям? Или можно сразу в базу знаний?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#47
Отправлено 25 января 2008 - 16:21
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#48
Отправлено 25 января 2008 - 16:59
Может пока не контрстатью написать, а хотя бы как-то это дело обсудить и на основании результатов обсуждения (хотя бы той части, которая в холивар не перейдет) сформировать некоторые общие решения. В конце-концов, наши точки зрения со всей их конфликтностью так или иначе основаны на реальном опыте. Может получится на основе обсуждений сформировать некоторые единые концепции. Я думаю, так лучше. Знания надо накапливать.Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Набирайтесь сил. Ну их нафик эти болезниСтатью попробую опубликовать в ближайшее время. Были бы силы.
#49
Отправлено 25 января 2008 - 17:08
Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме, а то так реально можно запутаться или вызвать на ровном месте разногласия. Думаю, полезная вещь, если учесть, что сообщество, сформированное данным форумом достаточно "разношерстное", многочисленное и регионально достаточно пропорционально распределено. Это ж некий стандарт можно выработать, а то пока что, судя по моим наблюдениям, каждая компания клепает свои стандарты, от чего могут возникнуть различия в понимании друг друга.Процесс тестирования в Вашей терминологии возможно и нельзя будет автоматизировать, если его нет, но тестирование (активности) конечно можно автоматизировать сразу, без их предварительного существования, а статья ведь про автоматизацию тестирования (название даже соответствующее).
Вообще, я придерживаюсь мнения что автоматизация процесса тестирования - это workflow, в данном случае bugtracker, а автоматизация тестирования - это автоматическое выполнение проверок.
#50
Отправлено 25 января 2008 - 17:21
Я бы просто предложил пользоваться SWEBOK 2004 Eng. Там практически всегда можно найти опору, хотя бы косвенно.Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.
#51
Отправлено 25 января 2008 - 18:01
Желаю скорейшего выздоровления.Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.
Я не могу гарантировать, что мне найдётся много что сказать по этой теме, но если найдётся, то постараюсь придержать и накопить и систематизировать свою диалектику.
#52
Отправлено 26 января 2008 - 16:28
Я бы просто предложил пользоваться SWEBOK 2004 Eng. Там практически всегда можно найти опору, хотя бы косвенно.Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.
Собственно, я позволил себе развернуть небольшую рекламную кампанию по этому поводу, использовав топики с терминологическими дискуссиями:
Про стратегию тестирования
Про конфигурационное тестирование и тестирование на этапе сопровождения
Ну и, собственно, по этому топику:
----------------------------
5.2.1.1. Unit testing [Bei90:c1; Per95:c17; Pfl01:c8s7.3] (IEEE1008-87)
Unit testing verifies the functioning in isolation of software pieces which are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units. A test unit is defined more precisely in the IEEE Standard for Software Unit Testing (IEEE1008-87), which also describes an integrated approach to systematic and documented unit testing. Typically, unit testing occurs with access to the code being tested and with the support of debugging tools, and might involve the programmers who wrote the code.
----------------------------
Термин 'software testing process' всречается в книге только один раз, в этом контексте:
10.1.4. Software Testing Tools [Dor02, Pfl01, Rei96]
Test generators. These tools assist in the development of test cases.
Test execution frameworks. These tools enable the execution of test cases in a controlled environment where the behavior of the object under test is observed.
Test evaluation tools. These tools support the assessment of the results of test execution, helping to determine whether or not the observed behavior conforms to the expected behavior.
Test management tools. These tools provide support for all aspects of the software testing process.
Performance analysis tools. [Rei96] These tools are used for measuring and analyzing software performance, which is a specialized form of testing where the goal is to assess performance behavior rather than functional behavior (correctness).
----------------------------
Термин 'GUI testing' встречается один раз, в списке дополнительных методик тестирования.
#53
Отправлено 29 января 2008 - 07:50
Продолжим дискурсию?
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#54
Отправлено 29 января 2008 - 10:23
Думаю ,продолжим. В принципе, достаточно прагматично рассмотрено, с точки зрения тех, кто будет за это все удовольствие платить.Немного систематизировал свои мысли и выложил: http://blog.shumoos.com/archives/138
Продолжим дискурсию?
Чуть позднее напишу больше, но из таких первых соображений исходя из прочитанного материала: использование "Священной коровы" вызовет проблемы и потери в том случае, если она используется не там, не теми и не тогда, когда надо (любого из этих вариантов достаточно). И к вопросу
выбора стоит подходить, когда будут решены эти самые "где", "кем" и "когда". В противном случае это либо пустая трата денег, либо кто-то кого-то хочет попилить на деньги, о чем говорилось в статье.
#55
Отправлено 29 января 2008 - 15:42
Хорошее началоДисклаймер. Я не злой. И никого не хочу обидеть. И вообще это читать не обязательно. Ибо:
«Все истины, которые я вам хочу сообщить – гнусная ложь».
Логично. Каждая компания в первую очередь решает свои проблемы. Тем не менее, у вендоров должен быть интерес в том, чтобы их продукт все-таки принес какое-то хотя бы видимое улучшение, поскольку каждая success story потребителя увеличивает вероятность покупок данного продукта в дальнейшем. Опять же, продавец подобных продуктов не отвечает за то, как этот продукт будет внедряться. Так что шагов влево-вправо может быть полно.В этой статье я намеренно драматизировал ситуацию. Так в частности, представители компаний производителей средств автоматизированного тестирования не продают гербалайф, но они действительно заинтересованы не в том, чтобы решить ваши проблемы, а в том, чтобы сделать продажу.
Тааак, а вот это уже что-то нездоровое. Я понимаю, что точные данные человеку, который не принимает участие в управлении финансами, неизвестны. Уточните хотя бы "свое видение мира", чтоб было понятно, что цифры взяты не с потолка, а на что-то опираются. Потому как мы можем подставить свои цифры и получить свои пропорции, свои проценты, на основании которых мы можем прийти к совсем другим выводам. Соответственно, это делает ваши математические расчеты и выводы по ним бессмысленными.Кроме того, поскольку статистика по нашим фирмам оберегается лучше госсекретов (если вообще существует), то все цифры приведены на основании моего видения мира, а не фактов. Соответственно пользуйтесь методикой расчета, а цифры ставьте свои.
В чем же вы хотите убедить? В приведенных вами статьях рассказывается о том, что не стоит излишне раскатывать губу, будто легко и просто за вас все сделает машина. Естественно, надо попотеть немного, надо много чего выработать. А если бросаться на амбразуру, то это гарантированный провал. Причем это характерно не только для автоматизированного функционального тестирования через GUI. Такое и для разработки характерно, да и вообще для любого науко-трудоемкого вида деятельности.Я думал, что моей статьи об автоматизированном тестировании с самого нуля и замечательного доклада Дмитрия Ручко о мифах в тестировании будет достаточно для того, чтобы люди с высшим образованием могли не наступать по сотне раз на одни и те же грабли. Но видимо нет. Не достаточно. Ладно, попробуем убедить уважаемую аудиторию цифрами. Может получится. А может и нет.
Расчеты поскипал по вышеприведенным причинам. Данные могут быть разными, а эти мало катят даже на "среднюю температуру по палате". Хотя к ним можно потом вернуться и рассмотреть отдельно.
О! Вот тут наши мнения сходятся на все 100%. Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.Вот где-то в секторе синих пузырьков и находится «Внедрение Автоматизированного Тестирования»
Если же дополнительно воспользоваться диаграммой зависимостей, то, как справедливо отмечают коллеги, сначала обязательно нужно «Внедрить Тестирование». Пока мы не пройден «тест Гринкевича», будем считать, что процесса тестирования у нет и к автоматизации переходить бессмысленно.
+1Кроме того необходимо, чтобы к этому моменту был наведен порядок в проектировании интерфейса, структур данных и в аналитике. Иначе вместо сокращения расходов получим бесконечную переделку тестов и, как следствие, сужение тестового покрытия. Т.е. путь непрерывных улучшений будет долог.
Смотря какой продукт и как разные вещи внедрялись. Как-то наталкивался на продукт, который уже существует много лет и за это время более-менее основательного тестирования не проводилось ни разу. До автоматизации тестирования данное приложение просто не доросло. Есть другие примеры, когда автотесты писались параллельно с написанием програмных компонент системы. То есть, написали какую-то часть системы, ее же покрыли тестами, эти тесты автоматизировали. При таком подходе выше вероятность того, что время "Автоматизированного тестирования" наступит еще до юбилеев.IMHO время для «Автоматизированного Тестирования» может наступить тогда, когда пятилетние юбилеи пребывания на своем посту простых инженеров давно стали обыденностью, да и десятилетние юбилеи никого особенно не удивляют.
#56
Отправлено 29 января 2008 - 15:43
Если компания уже более-менее серьезная и автотестеры выделены в отдельное подразделение, то такие финты не прокатят, а если прокатят, то в фоновом режиме (зачастую компании содержат "лицензионные" копии нужного софта на всякий аварийный случай или просто на попробовать). Даже довелось столкнуться с ситуацией, когда небольшая компания согласилась рассмотреть автоматизацию тестирования, но решила использовать тул, который она сочла бы приемлемым купить (пока что автотестинг полностью на нашей стороне, хотя портирование тестов на их машины планируется). То есть народ уже задумывается над лицензионной чистотой. Это в принципе радует.Для наших фирм характерным сроком работы является 1.5-2 года. А уходя, инженер уносит с собой часть компетенции фирмы и процессы приходится ставить с нуля. Получается что до автоматизированного тестирования мы вообще никогда не доберемся? Нет, что вы, у наших самураев свой путь пожирания кактусов. Закончим расчет. Напомню, нам нужно укомплектовать 20 рабочих мест и обучить 20 специалистов. Для «сокращения стоимости лицензий» нормальный пацан пойдет на горбушку и купит TestComplete или RR за десять баксов. Это позволит очень сильно сэкономить деньги на внедрении.
О да, потом эти люди в лучшем случае придут на этот форум. А в худшем, начнут клепать на количество, используя то, что есть.Чтобы еще немного сэкономить, предоставим возможность тестировщикам самим разобраться с инструментарием. Книги естественно покупать тоже не будем.
Зависит от того, чего ожидать в будущем. Автоматизацию-то со временем можно расширять, а это уже не такой болезненный процесс, как внедрение. Иногда нужны инвестиции в будущее, в этом случае могут подойти к данному процессу обстоятельно. Хотя нечто подобное я наблюдал только в одной компании.Таким образом, мы получим всего-навсего отрыв от производства на три месяца, и убытки компании в $15 000 [5] на человека или $300 000 на всех. В общем, то не так и много. Вложить 300 и получать ежегодную прибыль в 100 тысяч может и не такая плохая перспектива. Я даже не буду учитывать необходимость увеличения зарплаты автоматизаторам для уменьшения текучки [6]. Но если учесть риски, то вкладываться в такой проект я бы не стал.
Стоп. Вы о каких прогонах вручную говорите? Если тесты автоматизируются, то со временем эти тесты вообще руками не трогаются, иначе непонятно, зачем их было автоматизировать. Касательно других тестов - то их можно гонять либо теми же темпами, либо нарастить даже число прогонов (за счет того, что часть тестов идет автоматом), но это бессмысленно. Лучше потратить выигранное время на что-то более полезное.Пусть есть маленький проект. Всего на нем 2 000 тестовых сценариев. Для достижения приемлемого уровня контроля качества с заданным доверительным интервалом (90% уровень бездефектности при доверительном интервале одна сигма [7]) необходимо выполнить 12 000 тестовых прогонов. Пусть есть 200 тестов, требующих более 15 прогонов с общей суммой прогонов 6 000. Их и решено автоматизировать. После автоматизации появляется желание запускать их часто. Пусть даже каждый день. В результате вместо 6 000 прогонов получаем 60 000. Это, в принципе неплохо. Это даже может улучшить доверительный интервал до одной целой и одной десятой сигма. Но только если при этом не произойдет уменьшения числа ручных прогонов. Если в результате бесконечной переделки автоматизированных тестов произойдет уменьшение тестовых прогонов выполняемых вручную «всего» на тысячу, то у нас резко падает уровень бездефектности.
Или что вы подразумеваете под "ручными прогонами"?
Очковтирательство. Бывает. Причем со временем народ оттуда начинает сбегать толпами, если сертификаты не соответствуют сертифицируемому.Можно, правда, придумать неплохой вариант отдачи от внедрения автоматизации даже в условиях абсолютного хаоса в разработке. Бывает так, что сертификаты ISO и CMMI иногда приносят прибыль сами по себе, вне зависимости внедрялись они или нет. Достаточно, да, честно говоря, и лучше, если о внедрении ISO, CMMI сотрудники узнают случайно, обнаружив на стене приемной соответствующий сертификат. А что? И клиентам нравится, и сотрудники не пострадали.
Выделенное - жесть.Так что если, вы получили контракт на распил стабфонда написание россейской операционной системы для МК-152 [8]. И вам срочно надо ( обеспечить хороший откат себе любимому ) увеличить эффективность работы команды. То вы находите продавца (гербалайфа) вендора средств автоматизированного тестирования и говорите ему: «А давай мы с тобой (немного денег попилим полюбовно) интенсифицируем ускорение развития прогресса улучшения эффективности труда!». И все, вы нашли друг друга! В конце концов, и вашим и его детям кушать надо. А фирма переживет, денег в стабфонде хватит.
Скажем так, это не панацея от всех бед, но проблема заключается в том, что зачастую приложение иначе чем через ГУИ не протестировать. Вот и приходится пользовать то, что представляется возможным.Я не считаю, что автоматизированное тестирование полностью неэффективно. Но я против создания и возвеличивания «Священной коровы».
У автоматизации структура выигрыша немного специфическая. Это начальные затраты, окупаемые за счет уменьшения времени и затрат на прогон автоматизированного набора тестов. То есть выигрыш накапливается.Автоматизация тестирования – это проект с небольшим ROI и дает малый выигрыш в процентном отношении от бюджета организации.
Средства, вложенные в тестирование, могут оказаться вложением в фундамент для автоматизации тестирования.Существуют (и их много) способы вложения денег, которые дают больший выигрыш, как в процентном, так и в количественном выражении. В том числе способы вложения денег как конкретно в тестирование, так и в разработку в целом.
Ээээ ... А что делать, если к этой "Священной корове" рано или поздно дело все равно придет? Например, в ходе консультации выясняется, что объем тестирования достаточно большой, а людей, целенаправленно занимающихся этим крайне мало (есть реальный пример). Вы сами привели ссылку на свою статью, в котором вы отмечаете место применения этой "Священной коровы". Может уточните этот вывод?И наконец. Если у вас есть проблема с качеством ПО и вы приходите консультанту, а он предлагает вам внедрить «Священную корову», то нужно стукнуть этого консультанта чем-нибудь тяжелым и начинать искать другого.
#57
Отправлено 29 января 2008 - 17:18
Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.
#58
Отправлено 29 января 2008 - 22:32
Естественно, можно все делать без некоторой основы, но переходя обратно к тестированию, не слудет забывать, что в тестировании важно не только выполнить, но и оценить выполненное и сопоставить с уже имеющимися результатами. Более конкретно, если автоматизация не имеет под собой некоторой выработанной основы, то такие вещи как оценка покрытия, доля автоматизированного тестирования в общем процессе тестирования становятся весьма затруднительными. А ведь эти процессы являются частью одного процесса, который надо контролировать унифицированными методами. Соответственно, реализовать-то это можно, но вот как прикрутить это к остальной системе (а ведь автоматизации может подлежать только определенная часть всего тестирования) - это уже вопрос несколько посложнее и этот момент надо предусматривать заранее, чтоб не нагрести проблем вдальнейшемНеужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.
#59
Отправлено 30 января 2008 - 07:05
Т.е. продолжая аналогию с полётами на Луну, процесс нужен:Естественно, можно все делать без некоторой основы, но переходя обратно к тестированию, не слудет забывать, что в тестировании важно не только выполнить, но и оценить выполненное и сопоставить с уже имеющимися результатами. Более конкретно, если автоматизация не имеет под собой некоторой выработанной основы, то такие вещи как оценка покрытия, доля автоматизированного тестирования в общем процессе тестирования становятся весьма затруднительными. А ведь эти процессы являются частью одного процесса, который надо контролировать унифицированными методами. Соответственно, реализовать-то это можно, но вот как прикрутить это к остальной системе (а ведь автоматизации может подлежать только определенная часть всего тестирования) - это уже вопрос несколько посложнее и этот момент надо предусматривать заранее, чтоб не нагрести проблем вдальнейшемНеужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).
#60
Отправлено 30 января 2008 - 09:53
Т.е. продолжая аналогию с полётами на Луну, процесс нужен:
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).
Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:
1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.
2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком
3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования
4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.
Все это сводится к тому, что процесс фактически один и для него определены метрики, характеристики. А вот уже конкретно активности имеют специфику реализации и если они не позволяют выявить характеристики, метрики, которыми оперируют на уровне процесса целиком, то они как-то выпадают из общего процесса. Вся беда в том, что ручное и автоматическое тестирование в силу объективных причин покрывает только часть того, что можно протестировать ( не все можно автоматизировать ,не все можно пройти вручную ), соответственно, этим активностям надо как-то кореллировать между собой, чтобы на основании результатов получать общую картину. Если этого нет, то будет раздрай, который приведет либо к провалу проекта, либо к выработке некоторых унифицированных характеристик, компонент, метрик, к которым придется прийти вынуждено ,набив немало шишек.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных