Сообщений в теме: 44

[Clauster]

Забыл...

... Почему тогда два понятия?
...
Можно немного не в тему вопрос: Вы "Собачье сердце" читали/смотрели?

Понятие "Стратегия" абстрактное, а вот "стратегия тестирования" уже конкретное.
И читал и смотрел, а что?

[Case]

Начнём с содержания, которое вы привели:

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

Далее цитата, которую вы привели (кстати, спасибо, я никак не мог понять откуда "ноги растут"):

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

Как я вижу ничего не исключает ответа на вопрос "как" или описания инструментов с помощью которых можно проводить тестирование.

Создание тестов, метод создания тестов... Запись скриптов - это метод создания тестов, верно? Автоматический прогон набора скриптов, которые были отобраны для данной конкретной конфигурации и тестовых данных - это метод тестирования конкретного набора функционала. В чём противоречие? В том что Бейрез приводит полное определение не проговаривая отдельно частных случаев? По-моему, как раз правильно. Я вот попробовал на конкретных примерах разобраться - вижу разночтения.

Как насчёт примера стратегии? Или шагов по её разработке? С цитатами вроде разобрались, теперь самое интересное - ваша точка зрения.

Теперь к вашему последнему ответу "смотрите содержание...." - уважаемый, вы или не поняли о чём я писал или намеренно отмахнулись (думаю, что второе) от того о чём я упомянул.

Повторюсь: вы пытаетесь мапить понятие уровня проекта (стратегия, план) на уровень тестирования конкретного функционала (модули, классы, потоки, циклы). С такой точки зрения спорить безыдейно: я вам про Фому, вы мне про Ярёму.

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

[Case]

Стратегия является эффективной, если тесты, включенные в неё, с большой вероятностью обнаружат ошибки тестируемого объекта.

Я не могу удержаться и рискну свалить обсуждение в другое русло (если захотите поддержать тему - откроем новый топик). Стратегия изначально направленная на поиск ошибок, как по мне, в корне нечто ущербное. Что эта стратегия даст на выходе? Количество найдённых ошибок - что это даёт при условии что мы не знаем сколько ошибок было и осталось?

Пользователь/клиент не платит за количество найденных ошибок. Он платит за продукт, его функциональность, логично?

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

[Case]

... Можно немного не в тему вопрос: Вы "Собачье сердце" читали/смотрели?

И читал и смотрел, а что?

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

Кстати, вы совершенно правы - это две большие разницы и я называю статью имел в виду именно Стратегию в тестировании.

[Case]

Да, кстати, каким образом тестирование потоков транзакций позволяет сокращать количество тестов?

Извините, вы внимательно читали?

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

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

[barancev]

Слава, Вы совершенно напрасно задираете Недоотписанного Мембера (извините, уважаемый, имени не знаю :)).

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

Что касается названий "тестирование циклов", "тестирование транзакций", то пусть Вас это не смущает. Никакого отношения к циклам в программе (do-while или for) эти циклы не имеют. И транзакции это абстрактные, а не связанные с, например, базами данных. Не забывайте про название книги :) Это просто такие названия. Вообще-то они были призваны добавить понятности и наглядности, ан оказалось, что наоборот -- запутали :)

Да, Бейзер в описании стратегий не указывает, какими инструментами следует пользоваться. И это в самом деле для предлагаемых им стратегий несущественно. То же тестирование циклов может быть с равным успехом осуществлено как при помощи Робота, так и при помощи Раннера. Или даже руками. Важна схема, логика построения тестового набора. И к Вашим примерам, Слава, это тоже относится в полной мере. Чем Вы предлагаете тестировать пресловутый калькулятор? А не всё ли равно?

И добавлю к диспуту о названии -- я бы предложил назвать "Стратегии в тестировании" :)

[daniel]

Коллеги!

Большое спасибо за дискуссию и отдельное спасибо Вячеславу за статью!!!

У меня есть предложение оставить военную терминологию и начать дискуссию с принятых в тестировании определений.

Что есть тест план, что есть тестовая стратегия (определение стратегии в статье есть)
Затем рассмотреть различия для RUP и agile(если они есть, извините за невежество)

Вячеслав, еще раз спасибо за статью!

[Case]

Слава, Вы совершенно напрасно задираете Недоотписанного Мембера

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

Clauster, если где-то задел, прошу извинить!

[barancev]

Слава, Вы совершенно напрасно задираете Недоотписанного Мембера

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

Clauster, если где-то задел, прошу извинить!

Слава, я не про обиды, а по существу -- ведь определение Бейзера Вам замечательно подходит к этой статье! Вот мне и удивительно -- почему Вы говорите, что "видите разночтения" с описанными в статье примерами. Лично я не вижу :)

[Case]

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

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

Да, предлагаемые им стратегии весьма напоминают типы тестирования, но загляните в шаблон RUP, и все сомнения, хорошо это или плохо, развеются как дым (подсказка: см. название пункта 3.1).

Алексей, вот тут не могу согласится. Типы тестов это составляющая стратегии, но никак не одно и тоже. Первое что приходит на ум QA и testing. Снова скатываемся к вопросам терминологии, от которой я старательно уходил всю статью. Иначе будет пояснение терминов через другие термины, которые также требуют пояснения. (Дневники Иона Тихого: "Сепульки-Сепуление-Сепулькарий-Сепульки" получится.)

Что касается названий "тестирование циклов", "тестирование транзакций", то пусть Вас это не смущает. Никакого отношения к циклам в программе (do-while или for) эти циклы не имеют. И транзакции это абстрактные, а не связанные с, например, базами данных.

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

И к Вашим примерам, Слава, это тоже относится в полной мере. Чем Вы предлагаете тестировать пресловутый калькулятор? А не всё ли равно?

Именно! Пример более чем абстрактный, подобран специально, чтобы отобразить подход. Я не проговариваю ни слова об инструментах, ни о самих тестах (кроме того, что они есть).

И добавлю к диспуту о названии -- я бы предложил назвать "Стратегии в тестировании"

Приму как вариант. Пожалуй, только стоит обьяснить почему их много. С примерами. ВТорое издание статьи готовить прийдётся, а не хочется :)

[Case]

Что есть тест план, что есть тестовая стратегия (определение стратегии в статье есть)

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

daniel: Спасибо за отзыв.

[Case]

Слава, я не про обиды, а по существу -- ведь определение Бейзера Вам замечательно подходит к этой статье! Вот мне и удивительно -- почему Вы говорите, что "видите разночтения" с описанными в статье примерами. Лично я не вижу :)

Я вижу разночтения в понимании того зачем в статье приводится работа с тестами. Rlabs к примеру так и сказал, что прочёл то, что хотел прочесть :) С одной стороны хорошо, что статья даёт почву для "подумать" и поспорить по существу, но видимо сухое академическое определение далось бы легче мне самому и вызвало меньше толков :) Я только об этом.

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

[Clauster]

Повторюсь: вы пытаетесь мапить понятие уровня проекта (стратегия, план) на уровень тестирования конкретного функционала (модули, классы, потоки, циклы). С такой точки зрения спорить безыдейно: я вам про Фому, вы мне про Ярёму.

Вроде на всё, кроме этого, ответил господин Баранцев.
Тут в свою защиту скажу так: мне был бы понятней термин "стратегический план тестирования" нежели "стратегия тестирования" в контексте вашей статьи. Тогда бы для меня всё встало на свои места. А то, получется, вроде как мы оба правы. У Бейзера, например, стратегии тестирования рассматриваются с точки зрения теории моделирования.
С примером сложновато, много писать, да и времени, честно говоря мало, и так, на свой страх и риск, в форум отвлекаюсь. Может вы просто прочтёте Бейзера?

[Case]

Рад видеть в обсуждении.

Бейзера я прочту в любом случае. Про терминологию понял.

[SALar]

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

[SALar]

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

Стратегия же тестирования, на мой взгляд, дает определение целям и подцелям, и служит одной из отправных точек для составления плана. Стратегия тестирования в первую очередь должна отвечать на вопросы:
* Зачем будут проводиться те или иные виды тестирования?
* Почему не будут проводиться те или иные виды тестирования?
Во вторую очередь:
* В какой последовательности?
* Можно ли объединить какие-то виды?
* Качество тестирования и рекомендуемые методики.

[SALar]

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

... клиент-серверную систему ... Пусть система имеет "толстого" клиента, сервер приложения и сервер базы данных,
Это трехзвенная (трехуровневая) архитектура.

Чёткий план проекта, разбитый по задачам планирования, проектирования, дизайна и имплементации даёт менеджеру тестирования фундамент, необходимый для решения задачи, которую ставит вопрос "когда", то есть вопрос связанный с планированием тестирования.
Не даст, если не будет еще нескольких вещей, таких как доступные ресурсы и цели (нормированные понятия о достижимом результате) проекта. С ресурсами проще, они как правило известны, а вот с целями проблема. Очень мало людей, вне зависимости от сертификатов и занимаемых должностей могут сказать, что же является целью. И еще раз. Стратегия тестирования, план тестирования и программа (план-программа) это разные вещи. Принципиально разные. То, что RUP объединяет их в одном документе, это его право. Я видел стандарты, которые позволяли добавлять в этот же документ еще и тестовые сценарии и чек листы. И что? Это все равно разные вещи.
Я к тому веду, что Чёткий план проекта, разбитый по задачам планирования, проектирования, дизайна и имплементации + цели дает основание для написания плана. А еще "+ ресурсы" дает основание для написания программы (плана-программы).

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

[Green]

Case, статья удалась, а главное, прямо на больной мозоль для многих.
:-)

Я со своей казуистикой, хочу отметить только несколько маленьких недочетов.

1. Цитата:
В качестве дополнительной задачи, которая решается в процессе понимания стратегии тестирования, можно рассматривать задачу минимизации затрат на тестирование.

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

2. Цитата:
Как видим, Стратегия тестирования, как артефакт, органично вписывается в План Тестирования.

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

3. Цитата:
Что идеологически более правильно: выделять стратегию для всего проекта, или разрабатывать конкретные подходы для каждой области тестирования, зависит от конкретного проекта.

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

[Case]

Возможно я оформлю свое видение в виде статьи.

Было бы очень здорово.

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

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

... клиент-серверную систему ... Пусть система имеет "толстого" клиента, сервер приложения и сервер базы данных,
Это трехзвенная (трехуровневая) архитектура.

Согласен. Моя ошибка. Видимо сначала была идея про клиент/сервер, а потом разнёс на три уровня пропустив описание. Спасибо.

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

Я не сказал что это стратегия, я на примере акцентировал внимание на том, что даёт её разработка.

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

Например следующую версию на следующем окружении или тесты от 1-го до 5-ти на первом, от 6-ти до 10-ти на втором и т.д.?. Я не оговаривал этих моментов в статье (не хотелось уходить в разработку тестов и выбор конфигураций, упрощал как мог) - получился бы достаточно большой труд, хочется оставаться в рамках статьи.

[Case]

Case, статья удалась, а главное, прямо на больной мозоль для многих. :-)

Цель такая не ставилась, но обсуждение пошло достаточно интересное. На чей мозоль то попал?

1. Цитата:
В качестве дополнительной задачи, которая решается в процессе понимания стратегии тестирования, можно рассматривать задачу минимизации затрат на тестирование.
Не совсем понятно, что первично, а что вторично. Складывается представление, что вопрос минимизации затрат решается до определения стратегии, хотя это не так.
Стратегия первична. Когда ее определили, тогда начинаем решать задачи по минимизации в рамках уже определенной стратегии.

Вопрос как выразить мысль. По мне если задача дополнительная, то она как бы вторичнее :)

2. Цитата:
Как видим, Стратегия тестирования, как артефакт, органично вписывается в План Тестирования.

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

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

А если не вписана? План работы с рисками бывает в плане проекта, бывает вынесен в отдельный документ. Аналогично и тут.

3. Цитата:
Что идеологически более правильно: выделять стратегию для всего проекта, или разрабатывать конкретные подходы для каждой области тестирования, зависит от конкретного проекта.

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

Тоже немного отобьюсь :) Проект: биллинговая система. Есть отдельный и крайне навороченный модуль математики рассчёта потреблений, потерь електро енергии. Есть в этом же проекте графический редактор, есть модуль формирования отчётности. Разработка идёт местами параллельно, местами один модуль откладывается весь тим перебрасывается на другие задачи, есть сторонняя сисема с которой мы интегрируемся как с сервисом. Стратегия тестирования в этом случае на весь проект будет достаточно общая и мало интересная на практике.