Перейти к содержимому

Фотография

Что необходимо для внедрения автоматизации тестирования ПО


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 87

#41 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 11:15

Добавлю про unit-тестирование на этапе приёмки.

Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.

Я не знаю, для чего уж там создавалась практика (Вы по-моему уже за процессами самой работы не видите), но само модульное тестирование - это тестирование - проверка: работает как надо/не работает. Если другого способа проверить этого нет, или он сложнее, то я буду использовать модульное тестирование. Подумайте сами, тестировались ли программы до того как появились пользовательские интерфейсы? :)
  • 0

#42 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 января 2008 - 12:56

Про "дорогих консалтеров" отсюда: http://software-test...a...ost&p=39704 :)

"Ну вы блин даёте!" (с) Особенности национальной рыбалки :)
Там даже дата стоит: 8.3.2007 - год назад дело было, название и направленность ресурса успела поменяться. Я сам сейчас не в тестировании работаю, а тестирование для меня по прежнему крайне интересная область в которой я могу оказывать консультационные услуги в частном порядке и ни более.

Что я пытаюсь доказать, я ясным образом уже дал понять - я поддерживаю уже упомянутый тезис SALar-а.

Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?

Что автоматизация тестирования не только GUI? Да, не только. И что?

Говорите, что автоматизация тестирования не столько GUI и я немедленно отвалю.

Ахренеть как всё закопано :) Давайте в следующий раз с этого начнём? :)

Сам мой ответ ниже.

Пока что из серьёзных аргументов от Вас слышно только аппеляции к личному опыту, о котором надо спрашивать отдельно. :)

Вы уже как-то пробовали, когда проводили конкурс на тренинг по нагрузке. Конкурс я помнится выиграл - ощущение относительно моего опыта резко поменялось? :)

К вопросу про то что я не могу оценить вклад - да не вклад, а выхлоп.

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

Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.

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

Получается что слишком сложные, сдаюсь! Вы слишком изощрённый критик :crazy: раз я не могу понять где собственно критика. По-моему вы зацепились за мой тезис "что в первую очередь, я бы ещё поспорил", нет?

Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.

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

  • Мотивация руководства
  • Зафиксированный и работающий процесс тестирования
  • Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела
Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».


В контексте статьи об автоматизации тестирования, заявление о том что нельзя автоматизировать то, что не существует, я посчитал эквивалентным утверждению: "Нельзя автоматизировать тестирование, если не существует тестирования (требований, тест-кейсов)". Привёл контрпример. Что Вы в статье на самом деле имели в виду? Что нельзя автоматизировать бизнес, если нет бизнеса? Что нельзя автоматизировать IT-систему, если нет системы?

А, теперь дошло. Не закапывайте смысл, а? :)

Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.

При этом unit-тестирование программисты могут и должны делать. Само Unit-тестирование я отношу к практикам создания и отладки кода, а не к процессу тестирования, как к проверке реализованной в коде функциональности на соответствие зафиксированным требованиям.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#43 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 14:23

Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?
Давайте в следующий раз с этого начнём? :)

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

Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.

Тут уже, ИМХО, софистика зарождается. Предлагаю оставить способ использования статьи и комментариев на усмотрение читателя. Если хотите, уберу хинт об использовании её как методики которую можно (по форме) тиражировать.

Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.

1. Мотивация руководства

2. Зафиксированный и работающий процесс тестирования

3. Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

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

Моё сообщение от 10:48.
1. Задан уточняющий вопрос о мотивации руководства;
2. Про процессы - контрпример и уточняющий вопрос про процесс тестирования (его окружение).
4. Альтернативная гипотеза о причинах провала таких проектов (при соблюдении Ваших условий всё равно возможен провал, без некоторых из них возможен успех).

А, теперь дошло. Не закапывайте смысл, а? :)

Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.

Мне уже пора. Я не уловил в Ваше статье перехода от обобщенных критериев успеха внедрения автоматизации тестирования к оправданности использования или неиспользования для этого САТ.
Процесс тестирования в Вашей терминологии возможно и нельзя будет автоматизировать, если его нет, но тестирование (активности) конечно можно автоматизировать сразу, без их предварительного существования, а статья ведь про автоматизацию тестирования (название даже соответствующее).
Вообще, я придерживаюсь мнения что автоматизация процесса тестирования - это workflow, в данном случае bugtracker, а автоматизация тестирования - это автоматическое выполнение проверок.
  • 0

#44 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 14:37

Я всё-таки ещё раз повнимательнее почитал статью.

необходимы всего


Это "необходимо и достаточно"?
  • 0

#45 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 января 2008 - 15:39

Нет, это "как минимум".
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#46 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 25 января 2008 - 15:46

Опять же, Test-driven development - неплохая практика. Да и к тому же все-таки немного другой набор скилов нужен.



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


Немного оффтопика.
В результате исследований у меня получилось следующее:
* Практик юнит тестирования (оно же модульное) существует несколько
* Практика TDD (разработка ведомая тестированием) не подразумевает поиск ошибок. Она применяется для другогого. Более того, исходя из идеоологии этой практики программист не должен беспокоиться о полноценном тестовом покрытии. Следовательно, если все делать правильно, то в тестируемом классе могут встречаться, и часто действительно встречаются ошибки. TDD есть прием разработки, а не контроля качества. В TDD создание и кодирование тестов есть задача кодера, который разрабатывает именно этот класс.
* Практика Test First напротив предполагает контроль качества разрабатываемой функции или класса. Эта практика резко отличается от TDD. И здесь на стадии разработки тестовых сценариев желательно привлечение тест аналитика. Данная практика хорошо подходит для тестирования отдельных сложных функций. В своей статье "тривиальная задача" я описывал практику Test First.
Есть возражения по определениям? Или можно сразу в базу знаний?
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#47 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 25 января 2008 - 16:21

Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#48 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 25 января 2008 - 16:59

Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.

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

Статью попробую опубликовать в ближайшее время. Были бы силы.

Набирайтесь сил. Ну их нафик эти болезни
  • 0

#49 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 25 января 2008 - 17:08

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

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме, а то так реально можно запутаться или вызвать на ровном месте разногласия. Думаю, полезная вещь, если учесть, что сообщество, сформированное данным форумом достаточно "разношерстное", многочисленное и регионально достаточно пропорционально распределено. Это ж некий стандарт можно выработать, а то пока что, судя по моим наблюдениям, каждая компания клепает свои стандарты, от чего могут возникнуть различия в понимании друг друга.
  • 0

#50 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 17:21

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.

Я бы просто предложил пользоваться SWEBOK 2004 Eng. Там практически всегда можно найти опору, хотя бы косвенно.
  • 0

#51 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 25 января 2008 - 18:01

Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.

Желаю скорейшего выздоровления.
Я не могу гарантировать, что мне найдётся много что сказать по этой теме, но если найдётся, то постараюсь придержать и накопить и систематизировать свою диалектику.
  • 0

#52 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 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' встречается один раз, в списке дополнительных методик тестирования.
  • 0

#53 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 29 января 2008 - 07:50

Немного систематизировал свои мысли и выложил: http://blog.shumoos.com/archives/138

Продолжим дискурсию?
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#54 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 29 января 2008 - 10:23

Немного систематизировал свои мысли и выложил: http://blog.shumoos.com/archives/138

Продолжим дискурсию?

Думаю ,продолжим. В принципе, достаточно прагматично рассмотрено, с точки зрения тех, кто будет за это все удовольствие платить.
Чуть позднее напишу больше, но из таких первых соображений исходя из прочитанного материала: использование "Священной коровы" вызовет проблемы и потери в том случае, если она используется не там, не теми и не тогда, когда надо (любого из этих вариантов достаточно). И к вопросу
выбора стоит подходить, когда будут решены эти самые "где", "кем" и "когда". В противном случае это либо пустая трата денег, либо кто-то кого-то хочет попилить на деньги, о чем говорилось в статье.
  • 0

#55 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 29 января 2008 - 15:42

Итак, поутюжим вашу статью.

Дисклаймер. Я не злой. И никого не хочу обидеть. И вообще это читать не обязательно. Ибо:
«Все истины, которые я вам хочу сообщить – гнусная ложь».

Хорошее начало :diablo:

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

Логично. Каждая компания в первую очередь решает свои проблемы. Тем не менее, у вендоров должен быть интерес в том, чтобы их продукт все-таки принес какое-то хотя бы видимое улучшение, поскольку каждая success story потребителя увеличивает вероятность покупок данного продукта в дальнейшем. Опять же, продавец подобных продуктов не отвечает за то, как этот продукт будет внедряться. Так что шагов влево-вправо может быть полно.

Кроме того, поскольку статистика по нашим фирмам оберегается лучше госсекретов (если вообще существует), то все цифры приведены на основании моего видения мира, а не фактов. Соответственно пользуйтесь методикой расчета, а цифры ставьте свои.

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

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

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

Расчеты поскипал по вышеприведенным причинам. Данные могут быть разными, а эти мало катят даже на "среднюю температуру по палате". Хотя к ним можно потом вернуться и рассмотреть отдельно.

Вот где-то в секторе синих пузырьков и находится «Внедрение Автоматизированного Тестирования»
Если же дополнительно воспользоваться диаграммой зависимостей, то, как справедливо отмечают коллеги, сначала обязательно нужно «Внедрить Тестирование». Пока мы не пройден «тест Гринкевича», будем считать, что процесса тестирования у нет и к автоматизации переходить бессмысленно.

О! Вот тут наши мнения сходятся на все 100%. Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

Кроме того необходимо, чтобы к этому моменту был наведен порядок в проектировании интерфейса, структур данных и в аналитике. Иначе вместо сокращения расходов получим бесконечную переделку тестов и, как следствие, сужение тестового покрытия. Т.е. путь непрерывных улучшений будет долог.

+1

IMHO время для «Автоматизированного Тестирования» может наступить тогда, когда пятилетние юбилеи пребывания на своем посту простых инженеров давно стали обыденностью, да и десятилетние юбилеи никого особенно не удивляют.

Смотря какой продукт и как разные вещи внедрялись. Как-то наталкивался на продукт, который уже существует много лет и за это время более-менее основательного тестирования не проводилось ни разу. До автоматизации тестирования данное приложение просто не доросло. Есть другие примеры, когда автотесты писались параллельно с написанием програмных компонент системы. То есть, написали какую-то часть системы, ее же покрыли тестами, эти тесты автоматизировали. При таком подходе выше вероятность того, что время "Автоматизированного тестирования" наступит еще до юбилеев.
  • 0

#56 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 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]. И вам срочно надо ( :diablo:обеспечить хороший откат себе любимому ) увеличить эффективность работы команды. То вы находите продавца (гербалайфа) вендора средств автоматизированного тестирования и говорите ему: «А давай мы с тобой (немного денег попилим полюбовно) интенсифицируем ускорение развития прогресса улучшения эффективности труда!». И все, вы нашли друг друга! В конце концов, и вашим и его детям кушать надо. А фирма переживет, денег в стабфонде хватит.

Выделенное - жесть. :smile:

Я не считаю, что автоматизированное тестирование полностью неэффективно. Но я против создания и возвеличивания «Священной коровы».

Скажем так, это не панацея от всех бед, но проблема заключается в том, что зачастую приложение иначе чем через ГУИ не протестировать. Вот и приходится пользовать то, что представляется возможным.

Автоматизация тестирования – это проект с небольшим ROI и дает малый выигрыш в процентном отношении от бюджета организации.

У автоматизации структура выигрыша немного специфическая. Это начальные затраты, окупаемые за счет уменьшения времени и затрат на прогон автоматизированного набора тестов. То есть выигрыш накапливается.

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

Средства, вложенные в тестирование, могут оказаться вложением в фундамент для автоматизации тестирования.

И наконец. Если у вас есть проблема с качеством ПО и вы приходите консультанту, а он предлагает вам внедрить «Священную корову», то нужно стукнуть этого консультанта чем-нибудь тяжелым и начинать искать другого.

Ээээ ... А что делать, если к этой "Священной корове" рано или поздно дело все равно придет? Например, в ходе консультации выясняется, что объем тестирования достаточно большой, а людей, целенаправленно занимающихся этим крайне мало (есть реальный пример). Вы сами привели ссылку на свою статью, в котором вы отмечаете место применения этой "Священной коровы". Может уточните этот вывод?
  • 0

#57 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 29 января 2008 - 17:18

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

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".
  • 0

#58 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 29 января 2008 - 22:32

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

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

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

#59 a66at

a66at

    Постоянный участник

  • Members
  • PipPipPip
  • 184 сообщений
  • ФИО:Victor Ichalov

Отправлено 30 января 2008 - 07:05

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

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

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

Т.е. продолжая аналогию с полётами на Луну, процесс нужен:
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).
  • 0

#60 KaNoN

KaNoN

    АЦЦКИЙ СОТОНА

  • Members
  • PipPipPipPipPipPip
  • 1 260 сообщений
  • ФИО:Колесник Николай
  • Город:Днепропетровск > Киев > Лондон

Отправлено 30 января 2008 - 09:53

Т.е. продолжая аналогию с полётами на Луну, процесс нужен:
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).


Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:
1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.
2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком
3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования
4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.

Все это сводится к тому, что процесс фактически один и для него определены метрики, характеристики. А вот уже конкретно активности имеют специфику реализации и если они не позволяют выявить характеристики, метрики, которыми оперируют на уровне процесса целиком, то они как-то выпадают из общего процесса. Вся беда в том, что ручное и автоматическое тестирование в силу объективных причин покрывает только часть того, что можно протестировать ( не все можно автоматизировать ,не все можно пройти вручную ), соответственно, этим активностям надо как-то кореллировать между собой, чтобы на основании результатов получать общую картину. Если этого нет, то будет раздрай, который приведет либо к провалу проекта, либо к выработке некоторых унифицированных характеристик, компонент, метрик, к которым придется прийти вынуждено ,набив немало шишек.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных