Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:

Не понял, почему не уместно. В чём заключается принципиальное отличие по Вашему мнению?

1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.

Приведите мне пример чего-нибудь софтверного, что легко сделать, но сложно протестировать. На самом деле всё, что сделано человеком можно и проверить, но для этого, конечно, надо, как минимум, чтобы проверял тот, кто тоже может такое сделать сам.

2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком

Оценка результатов теста - это подпроцесс или просто активность? Т.е. он формализован, фиксирован, управляем, измерим в любом случае? Нет ли там каких-то частностей?

3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования

Т.е. автоматизированное тестирование принципиально без метрик и характеристик провести нельзя. Процессность в него заложена от рождения?

4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.

Опять же. Разве для выбора стратегии обязательно нужен процесс? Что вы собираетесь измерять в выборе стратегии, какие метрики? И вообще, представляю себе томик "Политика выбора стратегии тестирования" (формализация процесса).

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

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

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

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

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

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

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

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

Т.е. я пришёл, выполнил анализ, проектирование и дизайн (например один вообще, сам, а кто мне может помешать?), это сформировало процесс, который необходим для старта автоматизации. Я удовлетворил необходимому условию наличия процесса для начала автоматизации из первой обсуждаемой статьи (в случае, если я изначально держал в голове именно такой план). Я всё правильно понял?
Просто возникает вопрос, а согласны ли Вы с первой обсуждаемой статьёй? Вот цитаты:
"Для внедрения автоматизации тестирования ПО необходим ... зафиксированный и работающий процесс тестирования"
"Процесс тестирования должен существовать, работать, поддаваться изменениям и анализу, а для этого процесс должен быть зафиксирован письменно и любые процессные изменения должны фиксировать тоже письменно. На процесс, который строится, ставить автоматизацию сверху нельзя – развалим."

Ваш вопрос звучал так

Кстати, я просил сравнить живой и мёртвый процесс с точки зрения пригодности для автоматизации тестирования, в Вы мне говорите, что разница между ними в жёсткости основы. Только я не понял, какой из них полагается более жёстким?

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

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

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

Что именно непонятно?

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

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

Тут вот в голову пришла такая модельная задачка, чтобы вы могли лучше проиллюстрировать свои мысли:
Допустим у меня есть существующий работающий процесс регрессионного тестирования, я хочу внедрить автоматическое нагрузочное. Что из существующего процесса я должен для этого взять, без чего нельзя обойтись?

Но ведь есть же и белые и серые ящики... Но это уже не вопрос внедрения автоматизации, а вопрос уровня, на который вы ее внедряете.

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)

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

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

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

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

Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке?

По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.

Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.

Возьму свой любимый gray box тест и запущу с нужной интенсивностью в некоторое количество потоков - это несколько десятков строк кода дополнительно.

Мне показалось, что Вы хотели поспорить про приоритеты видов автоматизированного тестирования с точки зрения приносимой пользы вне контекста своей статьи, т.к. компонентное тестирование в ней не рассматривается. Я что-то путаю?

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

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?

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

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

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

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

Можно вы тут пока сами? Вернусь на той неделе.

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

По моему это попытка определить множество через множество. Что такое логическая единица кода?

Это так важно?
Короче, динамическое тестирование такой сущности - это модульное тестирование

UNIT unit1;INTERFACE    PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1;    BEGIN         ...    END;END;

А такой - компонентное:

class Motto {  public static void main(String[] args) {    System.out.println("Java rules!");    }}

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

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

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

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

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

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

А если качественную оценку поставить на место - перед количественной. Вы же специалист по бизнес-приложениям и работали на системах с пакетной обработкой, понимаете, что просто нажать кнопку старта недостаточно. Неужто в этом случае работа только через GUI - самый оптимальный вариант, если отвлечься от цены. И так ли уж редка эта ситуация? А системы отчётности, через GUI, без парсера отчёта?

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

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

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

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

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

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

Ну т.е. стратегия это всё-таки проектный, а не процессный артефакт. :) Я согласен, процесс тестирования не нужен для выбора стратегии.

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

Я Вам ещё раз говорю, нет таких програмных систем

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

Ну мы конечно про софтверное тестирование говорим, а не про принтеры. Но засчитано, я слишком широко выразился. Предлагаю оставить на усмотрение читателя.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну это уже не вручную же Это уже автоматика.

Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)

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

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

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

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

А подход к нагрузочному тестированию вшит в процесс?

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

И потом посмотреть, всё ли там необходимо и все ли эти ресурсы могут существовать только в рамках процесса регрессионного тестирования.

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

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

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

Нет, не понимаю.
Хорошо, будем считать что процесс это просто последовательность стадий, алгоритм, что после чего делать и какими входами выходами активности цепляются друг за друга.
Представим что есть уже внедрённый процесс регрессионного тестирования, который несколько десятков раз сработал.
И представим, что есть просто записанный на бумаге процесс автоматизировааного тестирования, который можно внедрить сверху вниз в первый же раз как вам понадобится провести итерацию автоматизированного тестирования.
В чём преимущество первого процесса перед вторым в данном случае? Или в чём сложность внедрения второго с первого раза?

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

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

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

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