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

Публикации a66at

169 публикаций создано a66at (учитываются публикации только с 29 марта 2023)



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

Отправлено автор: a66at 30 января 2008 - 10:12 в QA: обеспечение качества

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

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

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

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

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

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

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

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

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

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

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

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



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

Отправлено автор: a66at 24 января 2008 - 07:37 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 01 февраля 2008 - 14:02 в QA: обеспечение качества

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

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

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

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

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

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

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

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



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

Отправлено автор: a66at 24 января 2008 - 09:21 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 30 января 2008 - 14:17 в QA: обеспечение качества

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



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

Отправлено автор: a66at 24 января 2008 - 11:15 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 29 января 2008 - 17:18 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 24 января 2008 - 16:42 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 30 января 2008 - 11:53 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 07:48 в QA: обеспечение качества

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

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

Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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



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

Отправлено автор: a66at 01 февраля 2008 - 12:42 в QA: обеспечение качества

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

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 11:10 в QA: обеспечение качества

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

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

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

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

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

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

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

С одной стороны вы пишите что согласны с тем что я написал и тут же двумя-тремя пунктами ниже пишите про своё понимание вопроса.

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

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

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

Unit-тестирование на этапе приёмки - это вы пошутили сейчас верно? Заказчик или сторонний подрядчик на стороне заказчика садится и покрывает код системы (который ему ещё кто-то должен дать, ага) unit-тестами: так и вижу, угу.

Я вам объясняю-объясняю, что иногда (не так редко) это приходится делать практически в чистом виде, а вы не хотите понимать (и это уже не в первый раз). Что с Вами делать? Я вот не помню, то ли в те времена дебаггера в Query Analyser не было, то ли не умел им пользоваться, так нет проблем, заглушил, наставил "assert"-ов и протестил. Приёмка была, точнее сертификационное тестирование. Unit был, testing был. Другие виды синтетики, впрочем, много чаще случаются.



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

Отправлено автор: a66at 23 января 2008 - 15:30 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 11:15 в QA: обеспечение качества

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

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

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



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

Отправлено автор: a66at 30 января 2008 - 07:05 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 14:23 в QA: обеспечение качества

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

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

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

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

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

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

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

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

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

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

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

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

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



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

Отправлено автор: a66at 30 января 2008 - 11:31 в QA: обеспечение качества

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

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

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 14:37 в QA: обеспечение качества

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

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


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



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

Отправлено автор: a66at 30 января 2008 - 13:28 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 25 января 2008 - 17:21 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 30 января 2008 - 14:49 в QA: обеспечение качества

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

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

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

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



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

Отправлено автор: a66at 25 января 2008 - 18:01 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 01 февраля 2008 - 13:31 в QA: обеспечение качества

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

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

Если же процесс только на бумаге, то стадию тест-дизайна ему не миновать.

А каким образом минует стадию тест-дизайна процесс, который не на бумаге? В обоих случаях делается тест-дизайн.

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

Так он пригоден или необходим?



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

Отправлено автор: a66at 26 января 2008 - 16:28 в QA: обеспечение качества

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

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



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

Отправлено автор: a66at 01 февраля 2008 - 14:20 в QA: обеспечение качества

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

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