Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)Ну это уже не вручную же Это уже автоматика.
- Форум тестировщиков
- → Публикации a66at
169 публикаций создано a66at (учитываются публикации только с 06 июня 2023)
Отправлено автор: a66at 30 января 2008 - 13:28 в QA: обеспечение качества
Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)Ну это уже не вручную же Это уже автоматика.
Отправлено автор: a66at 30 января 2008 - 14:17 в QA: обеспечение качества
Отправлено автор: a66at 30 января 2008 - 11:53 в QA: обеспечение качества
По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.Но как вы без дополнительных средств расчитаете время отклика системы на определенные операции при определенной нагрузке?
Возьму свой любимый gray box тест и запущу с нужной интенсивностью в некоторое количество потоков - это несколько десятков строк кода дополнительно.Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.
Отправлено автор: a66at 30 января 2008 - 11:31 в QA: обеспечение качества
Ну т.е. стратегия это всё-таки проектный, а не процессный артефакт. :) Я согласен, процесс тестирования не нужен для выбора стратегии.Я разве указал, что я собираюсь измерять выбор стратегии? Я указал, что ее надо выбрать. Помимо этого, определить цели, охват, выработать характеристики, метрики, на основании которых мы будем делать какие-то выводы.
Ну мы конечно про софтверное тестирование говорим, а не про принтеры. Но засчитано, я слишком широко выразился. Предлагаю оставить на усмотрение читателя.Есть задачи, которые можно проверить только визуально, например, корректность вывода на печать, когда надо оценить уже отпечатанный текст. То есть когда что-то выходит за пределы чисто софтверных проверок. Есть задачи, которые на уровне кода не проверяются, так как они на уровне кода либо недоступны либо их расколупать на этом уровне сложно.Я Вам ещё раз говорю, нет таких програмных системэтим активностям надо как-то кореллировать между собой, чтобы на основании результатов получать общую картину.
Отправлено автор: a66at 30 января 2008 - 10:12 в QA: обеспечение качества
Не понял, почему не уместно. В чём заключается принципиальное отличие по Вашему мнению?Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:
Приведите мне пример чего-нибудь софтверного, что легко сделать, но сложно протестировать. На самом деле всё, что сделано человеком можно и проверить, но для этого, конечно, надо, как минимум, чтобы проверял тот, кто тоже может такое сделать сам.1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.
Оценка результатов теста - это подпроцесс или просто активность? Т.е. он формализован, фиксирован, управляем, измерим в любом случае? Нет ли там каких-то частностей?2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком
Т.е. автоматизированное тестирование принципиально без метрик и характеристик провести нельзя. Процессность в него заложена от рождения?3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования
Опять же. Разве для выбора стратегии обязательно нужен процесс? Что вы собираетесь измерять в выборе стратегии, какие метрики? И вообще, представляю себе томик "Политика выбора стратегии тестирования" (формализация процесса).4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.
Я Вам ещё раз говорю, нет таких програмных систем, которые бы нельзя было протестировать модульно (и при этом пользовательские прецеденты могут вообще не участвовать), а системы, которые нельзя или сложно протестировать через GUI есть и в большом количестве. Расклад по частотам слов в SWEBOK это косвенно подтверждает.этим активностям надо как-то кореллировать между собой, чтобы на основании результатов получать общую картину.
Отправлено автор: a66at 30 января 2008 - 14:49 в QA: обеспечение качества
А подход к нагрузочному тестированию вшит в процесс?Подход. Прежде чем чего-то внедрять, нужно определить свои нужды, подготовить основу. Все-таки и у нагрузочного тестирования есть определенные сценарии, определенные условия.
Отправлено автор: a66at 31 января 2008 - 07:58 в QA: обеспечение качества
Я так понимаю что Вы подразумеваете, что для автоматизации тестирования нужно чтобы существовало не само тестирование, а процесс тестирования и спрашиваю, зачем конкретно это нужно.И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?
Теперь Вы говорите что Вам требуется вот это, но описываете, на мой взгляд, уже не процесс, а набор абстрактных методов, причём довольно статичный. Что в нём такого уж процессного? И вообще что в нём такого уж специфического для конкретного проекта, почему нельзя просто записать это в методике, что вот нужно делать то-то и то-то и успокоится, а нужно настаивать на существовании полноценного процесса?Если не было нагрузочного тестирования, а теперь надо ввести, то начинается все не с автоматизации непосредственно, а в подготовке ресурсов, необходимых для этого. Определяются цели, оцениваемые параметры, действия, подготавлявается среда, подтягиваются инструментальные средства и т.п. В конечном счете формируется некоторый сценарий. Вот уже на основании этого можно что-то автоматизировать (а сам процесс автоматизации уже мало отличается в разных видах тестирования). Если такой основы нет, то окажется, что вы делаете непонятно что и рано или поздно эти тесты не будут давать нужного представления о реальной ситуации с тестируемым приложением.
А теперь, если немного абстрагироваться, то получится, что и для нагрузочного тестирования и для регрессионного нужно вначале подтянуть ресурсы, инструментальные средства, подготовить среду, заготовить тесты или выявить правила формирования тестов (например в модульном тестировании тест соответствует некоторой функции) и уже потом автоматизировать тесты. То есть в данном случае подход один и тот же независимо от вида тестирования. Но главное то, что автоматизация уже делается тогда, уже есть основа, когда есть чего автоматизировать.
Отправлено автор: a66at 01 февраля 2008 - 14:20 в QA: обеспечение качества
На самом деле, дам небольшую подсказку для увеселения дальнейшего разговора. Для автоматизированного регрессионного тестирования очень ценной информацией, которую можно почерпнуть из процесса ручного регрессионного тестирования является историческая информация о выполнении тестового набора в предыдущих итерациях. Я бы, наверное, именно это посчитал самыми ценными сведениями, которые больше негде взять, кроме предварительно существующего процесса, занимайся я такого рода деятельностью. Но для нагрузочного это, конечно, неверно.Сами тесты. Это артефакты, получаемые в процессе. Существование процесса тут обязательно, так как тесты получаются, когда пройдены активности Анализ - Проектирование - Дизайн, которые уже формируют некоторый процесс как плановую, упорядоченную активность. Только после дизайна есть чего автоматизировать.
Отправлено автор: a66at 01 февраля 2008 - 14:02 в QA: обеспечение качества
Т.е. я пришёл, выполнил анализ, проектирование и дизайн (например один вообще, сам, а кто мне может помешать?), это сформировало процесс, который необходим для старта автоматизации. Я удовлетворил необходимому условию наличия процесса для начала автоматизации из первой обсуждаемой статьи (в случае, если я изначально держал в голове именно такой план). Я всё правильно понял?Сами тесты. Это артефакты, получаемые в процессе. Существование процесса тут обязательно, так как тесты получаются, когда пройдены активности Анализ - Проектирование - Дизайн, которые уже формируют некоторый процесс как плановую, упорядоченную активность. Только после дизайна есть чего автоматизировать.Какие артефакты нужны, названия? Почему их просто нельзя подготовить без предварительного существования процесса? Для функционального регрессионного автоматизированного тестирования.А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.
Я оговорился. Я хотел спросить, если у меня есть только мёртвый процесс, то достаточно ли этого, чтобы удовлетворить необходимому условию существования процесса для начала автоматизации тестирования.Ваш вопрос звучал так
Я указал, что действующий процесс находится ближе к этапу автоматизации, нежели только оформленный на бумаге.Кстати, я просил сравнить живой и мёртвый процесс с точки зрения пригодности для автоматизации тестирования, в Вы мне говорите, что разница между ними в жёсткости основы. Только я не понял, какой из них полагается более жёстким?
Отправлено автор: a66at 01 февраля 2008 - 12:42 в QA: обеспечение качества
А что значит управляемое состояние? По-моему, для процесса, который просто является последовательностью действий, для управляемости достаточно просто возможности менять его описание и распространить новое описание среди участников.Разница в том, что для автоматизированного тестирования нужна куда более жесткая основа, иначе этот процесс быстро выйдет из управляемого состояния.
Давайте конкретику - посмотрю, а так Вы только время тратите, моё и читателей, которым некуда посмотреть. Я несколько раз делал нагрузочное тестирование для сторонних заказчиков, про орг. вопросы имею представление, и ни разу никаких ассетов, артефактов, ресурсов от существующего процесса регрессионного тестирования для этого не понадобилось (от других процессов было нужно, но не всегда, кроме того, те сведения можно и нужно было в ряде случаев добыть "внепроцессно"). Ну разве только, тест-кейсы были нужны для записи скриптов, которые, впрочем, тоже отбирались по признакам, которые нельзя получить из процесса регрессионного тестирования и которые можно было написать тоже "внепроцессно", по документации. Т.е. они были, эти ассеты процесса регрессионного тестирования, но для внедрения автоматизации были не нужны. Вы необходимых среди них тоже назвать не смогли.Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).
Отправлено автор: a66at 01 февраля 2008 - 10:29 в QA: обеспечение качества
Нет, не понимаю.Процессность здесь заключается в том, что этим действиям соответствуют вполне конкретные стадии, на которые нужно время, без которых дальнейшие активности в этом направлении затруднительны, а результаты могут не дать нужной картины о состоянии тестируемой системы.
Отправлено автор: a66at 29 января 2008 - 17:18 в QA: обеспечение качества
Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.
Отправлено автор: a66at 25 января 2008 - 18:01 в QA: обеспечение качества
Желаю скорейшего выздоровления.Коллеги, тяжелая и продолжительная болезнь отвлекла меня от в высшей мере интересной дискурсии. Обиднее всего то, что еще в четверг 17 января, я отдал на рецензию статью, в которой изложил одну из методик оценки целесообразноти внедрения процессов с цифрами.
Теперь собственно предложение. Может кто-нибудь возьмется написать контрстатью (или статью парафраз)? Было бы, знаете, крайне любопытно продолжить дискурсию на основании развернутого анализа.
Статью попробую опубликовать в ближайшее время. Были бы силы.
Отправлено автор: a66at 24 января 2008 - 14:24 в QA: обеспечение качества
Про то что в первую очередь, а что во вторую я бы поспорил.
Отправлено автор: a66at 24 января 2008 - 16:28 в QA: обеспечение качества
Это так важно?По моему это попытка определить множество через множество. Что такое логическая единица кода?Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.
UNIT unit1;INTERFACE PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1; BEGIN ... END;END;А такой - компонентное:
class Motto { public static void main(String[] args) { System.out.println("Java rules!"); }}
Отправлено автор: a66at 24 января 2008 - 12:10 в QA: обеспечение качества
О, мы кажется приближаемся к сердцу тьмы, фундаментальной проблеме в производительности людей. Case, Вы хотели спорить, где Ваша аргументация?Например, если уже прислали готовый "черный ящик". Тут только и остается, что долбать его извне, хотят тестировщики того или нет.
Отправлено автор: a66at 24 января 2008 - 11:15 в QA: обеспечение качества
Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)Но ведь есть же и белые и серые ящики... Но это уже не вопрос внедрения автоматизации, а вопрос уровня, на который вы ее внедряете.
Отправлено автор: a66at 24 января 2008 - 09:21 в QA: обеспечение качества
Что именно непонятно?Только не совсем понял как это к теме "когда и при каких условиях надо внедрять автоматизацию". Я без наезда, просто или я не до конца понял вашу мысль, либо это уже просто ветка ушла в сторону.
Отправлено автор: a66at 24 января 2008 - 16:42 в QA: обеспечение качества
А если качественную оценку поставить на место - перед количественной. Вы же специалист по бизнес-приложениям и работали на системах с пакетной обработкой, понимаете, что просто нажать кнопку старта недостаточно. Неужто в этом случае работа только через GUI - самый оптимальный вариант, если отвлечься от цены. И так ли уж редка эта ситуация? А системы отчётности, через GUI, без парсера отчёта?это holy war, пока никто не возьмётся что-то подсчитать в цифрах
Отправлено автор: a66at 25 января 2008 - 07:48 в QA: обеспечение качества
Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.
Повторю - это должно делаться разработчиками.
Про тестирование на уровне бизнес-модулей.
Основная или базовая функциональность (то что замыкает бизнес-цикл: закрытие периода, перерасчёты, выставление НН, пени и прочей лабуды) зачастую тестировалась внутренней разработкой. Мы делали свои фреймворки, которые дёргали через удалённые вызовы торчащие методы, заменяя по сути вызовы клиента и интерфейсов в другие системы. Отчёты не парсили (ну его нафиг этот "кристалл"), а собирали из базы по опорным точкам на основе бизнес-правил: банально, чтобы например внутри сети электроенергия не возникала.
Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).
Отправлено автор: a66at 25 января 2008 - 17:21 в QA: обеспечение качества
Я бы просто предложил пользоваться SWEBOK 2004 Eng. Там практически всегда можно найти опору, хотя бы косвенно.Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.
Отправлено автор: a66at 25 января 2008 - 14:37 в QA: обеспечение качества
необходимы всего
Отправлено автор: a66at 25 января 2008 - 14:23 в QA: обеспечение качества
Да, с уточнением. Это, конечно, зависит от специфики, но мне показалось, что раз Вы пожелали спорить на эту тему, то у Вас есть какие-то аргументы общего применения против этой позиции, кроме терминологических увёрток, или за противоположную и Вы хотите ими поделиться.Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?
Давайте в следующий раз с этого начнём? :)
Тут уже, ИМХО, софистика зарождается. Предлагаю оставить способ использования статьи и комментариев на усмотрение читателя. Если хотите, уберу хинт об использовании её как методики которую можно (по форме) тиражировать.Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.
Моё сообщение от 10:48.Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.
1. Мотивация руководства
2. Зафиксированный и работающий процесс тестирования
3. Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела
4. Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».
Мне уже пора. Я не уловил в Ваше статье перехода от обобщенных критериев успеха внедрения автоматизации тестирования к оправданности использования или неиспользования для этого САТ.А, теперь дошло. Не закапывайте смысл, а? :)
Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.
Отправлено автор: a66at 25 января 2008 - 11:15 в QA: обеспечение качества
Я не знаю, для чего уж там создавалась практика (Вы по-моему уже за процессами самой работы не видите), но само модульное тестирование - это тестирование - проверка: работает как надо/не работает. Если другого способа проверить этого нет, или он сложнее, то я буду использовать модульное тестирование. Подумайте сами, тестировались ли программы до того как появились пользовательские интерфейсы? :)Добавлю про unit-тестирование на этапе приёмки.
Даже если кому-то нечего делать, потратили кусок времени и покрыли unit-тестами код поставляемой системы - при чём сделал это не поставщик в процессе разработки (ради чего собственно практика и создавалась, на минуточку). Поставили стенд, запустили сборку. Не собирается, unit-ы не проходят. А у поставщика собирается - вот незадача. И система собранная из этого же кода работает.
Отправлено автор: a66at 23 января 2008 - 15:30 в QA: обеспечение качества
Ну давайте, спорьте. SALar, видимо имел в виду, что в современных системах дефекты GUI самые дешёвые в исправлении, поэтому не стоит на них концентрироваться слишком сильно. Не говоря уже о централизованных системах со всякими интеллектуальными терминалами (банкоматами там, мобильными телефонами), в которых, может статься бизнес логику не получится вообще через GUI протестировать. SOA он тоже, кажется, упоминал.Про то что в первую очередь, а что во вторую я бы поспорил.
Интересно даже стало. Это отражение нежелания или неспособности?Unit это вообще не к тестерам
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru