Разновидности тестирования.

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php

У меня вопрос к уважаемым коллегам.
А никто не пробовал - сначала как-то классифицировать программные продукты, а потом привязать классификацию разновидностей тестирования к типам/видам продуктов?
хм.. (мечтательно...) а если еще и статистику собрать.
Ну типа -- программные продукты класса "Игры". ХХ% игр тестируются такими-то разновидностями, УУ% - такими-то.

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

Посмотрите два ГОСТ-а:
* ГОСТ 9126 от 93 года
* ГОСТ 28195 от 89 года
потом можно продолжить разговор, ссылаясь на эти стандарты.

Также рекомендую ГОСТ 34.603. последний косвенно относится к теме, но все таки. Также умеренно полезен для обсуждения данной темы SWEBOK, раздел "тестирование" http://swebok.sorlik...re_testing.html

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php

Это где-то очнь далеко от тестирования. Но вообще можно и как фб делать - нагрузки сразу на живых пользователях проверять.
Главное чтобы мозг рака вот до такого не добрался (а необремененный знаниями и перенасыщенный терминами мозг может): http://loadstorm.com.../happy-new-year

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

Я боюсь все еще сложнее и волшебный ответ как всегда - "there is no silver bullet for this problem".
Опять же - "контроль качества" это странная фикция, просто потому что "Там где моют руки - там все нормально", например. С другой стороны, "качество" это субъективное понятие и активность тестировщика по выявлению нужных субъектов и выявлению их же нужд она +/- всегда нужна. Опять же - опеределение атрибутов качества которые нас интересуют вопрос зачастую вполне обсуждаемый: http://thetesteye.co...acteristics.pdf

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

Посмотрите два ГОСТ-а:
* ГОСТ 9126 от 93 года
* ГОСТ 28195 от 89 года
потом можно продолжить разговор, ссылаясь на эти стандарты.

Также рекомендую ГОСТ 34.603. последний косвенно относится к теме, но все таки. Также умеренно полезен для обсуждения данной темы SWEBOK, раздел "тестирование" http://swebok.sorlik...re_testing.html

ГОСты - это хорошо. 28195 - скачала, 9126 - давно уж лежит на компе. Как и SWEBOK.

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

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

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

ПСИ. Это не тестирование, но один из видов контроля качества. Не тестирование, но QC. Применяется для контроля некоторых атрибутов из групп "Функциональные возможности (Functionality)" и "Практичность (Usability)" в классификации 9126.

Но! Вот здесь есть фокус, которым может воспользоваться настоящий джедай. ПСИ проводятся по программе и методике испытаний (подготовленной например по 34.603). И само написание ПМИ способно существенно улучшить продукт. Я называю это "встраиванием качества в процесс". Таким образом, написание ПМИ относится не к тестированию и не к QC, но к "QA". Если все сделано правильно и подготовлена хорошая ПМИ для ПСИ, то само ПСИ может оказаться избыточным. Рецепт для настоящих опытных джедаев.

Это уже BDD какой-то получается. В любом случае и те и те проверки стоит скорее называть "rejection checks" а не "acceptance tests", как это принято. По смыслу корректнее получится. И в любом случае это все еще недостаточные процедуры.

ПСИ. Это не тестирование, но один из видов контроля качества. Не тестирование, но QC. Применяется для контроля некоторых атрибутов из групп "Функциональные возможности (Functionality)" и "Практичность (Usability)" в классификации 9126.

Но! Вот здесь есть фокус, которым может воспользоваться настоящий джедай. ПСИ проводятся по программе и методике испытаний (подготовленной например по 34.603). И само написание ПМИ способно существенно улучшить продукт. Я называю это "встраиванием качества в процесс". Таким образом, написание ПМИ относится не к тестированию и не к QC, но к "QA". Если все сделано правильно и подготовлена хорошая ПМИ для ПСИ, то само ПСИ может оказаться избыточным. Рецепт для настоящих опытных джедаев.

И спорить не буду.
Здесь уже влезаем в терминологию.

Даже пожалуй в область стандартов (если они существуют для разрабатываемого ПО).
ПСИ к примеру (и, соответственно ПМИ) в ГОСТ РВ 0019-001-2006 отсутствует.
Но есть - "Описание квалификационного тестирования" и , соответственно, "Отчет о квалификационном тестировании программного обеспечения".

В ГОСТ Р 51904-2002 тоже присутствует квалификационное тестирование.

Мне нужно отсортировать баги по видам тестирования. Есть ошибка спецификации, куда ее нужно отнести?

Есть ошибка спецификации, куда ее нужно отнести?

Это классификация по времени нахождения или по артефакту в котором найдено.

Есть ошибка спецификации, куда ее нужно отнести?

Это классификация по времени нахождения или по артефакту в котором найдено.

Я имела в виду к какому виду тестирования отнести. Например нефункциональное тестирование.
Ошибку спецификации можно отнести к documentation testing?

Ошибку спецификации можно отнести к documentation testing?

Все таки зависит от ситуации, но по мне ответ - да, попробую объяснить свою позицию:

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

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

Есть ошибка спецификации, куда ее нужно отнести?

Это классификация по времени нахождения или по артефакту в котором найдено.

Я имела в виду к какому виду тестирования отнести. Например нефункциональное тестирование.
Ошибку спецификации можно отнести к documentation testing?

В спецификации?
Т.е. в том документе, в соответствии с которым Вы разрабатываете программное обеспечение и на соответствие которому проверяете?

Нет, нельзя.

Вот в руководстве пользователя если ошибка - то да, можно.

Есть ошибка спецификации, куда ее нужно отнести?

Это классификация по времени нахождения или по артефакту в котором найдено.

Я имела в виду к какому виду тестирования отнести. Например нефункциональное тестирование.
Ошибку спецификации можно отнести к documentation testing?

Нет, нельзя.

Спасибо всем, кто откликнулся!

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

КЛАССИФИКАЦИЯ ВИДОВ ТЕСТИРОВАНИЯ

ПО ЗНАНИЮ ВНУТРЕННОСТЕЙ СИСТЕМЫ

Черный ящик (black box testing)
Белый ящик (white box testing)
Серый ящик (grey box testing)

ПО ОБЪЕКТУ ТЕСТИРОВАНИЯ

Функциональное тестирование (functional testing)
Тестирование интерфейса пользователя (UI testing)
Тестирование локализации (localization testing)
Тестирование скорости и надежности (load/stress/performance testing)
Тестирование безопасности (security testing)
Тестирование опыта пользователя (usability testing)
Тестирование совместимости (compatibility testing)

ПО СУБЪЕКТУ ТЕСТИРОВАНИЯ

Бета-тестировщик (beta tester)

ПО ВРЕМЕНИ ПРОВЕДЕНИЯ ТЕСТИРОВАНИЯ

До передачи пользователю — альфа-тестирование (alpha testing)
Тест приемки (smoke test, sanity test или confidence test)
Тестирование новых фунщиональностей (new feature testing)
Регрессивное тестирование (regression testing)
Тест сдачи (acceptance of certification test)
После передачи пользователю — бета-тестирование (beta testing)

ПО КРИТЕРИЮ "ПОЗИТИВНОСТИ" СЦЕНАРИЕВ
Позитивное тестирование (positive testing)
Негативное тестирование (negative testing)

ПО СТЕПЕНИ ИЗОЛИРОВАННОСТИ ТЕСТИРУЕМЫХ КОМПОНЕНТОВ

Компонентное тестирование (component testing)
Интеграционное тестирование (integration testing)
Системное (или энд-ту-энд) тестирование (system orend-to-end testing)

ПО СТЕПЕНИ АВТОМАТИЗИРОВАННОСТИ ТЕСТИРОВАНИЯ

Ручное тестирование (manual testing)
Автоматизированное тестирование (automated testing)
Смешанное/полуавтоматизированное тестирование (semi automated testing)

ПО СТЕПЕНИ ПОДГОТОВКИ К ТЕСТИРОВАНИЮ

Тестирование по документации (formal/documented testing)
Эд Хок тестирование (Ad hoc testing)

вот эти вопросы один в один использовались на собеседовании, в одной компании, куда я устраивалсь на работу. Хочу сказать, что жаль, не видела этого форума раньше!!! Собеседование, прошла, но насколько оно было нерво-трепательным не передать, так что, вдруг кому поможет, читайте книгу Р.Савина, там весьма доступно все это разжевывается. И еще, у всех менеджеров покер-фейс еще тот, так что если вас будут спрашивать "это все?" или "что-нибудь еще?", говорите - да, мол, все. лучше так. чем мычать, пытаясь вспомнить, то чего просто может не быть))

вот эти вопросы один в один использовались на собеседовании, в одной компании, куда я устраивалсь на работу. Хочу сказать, что жаль, не видела этого форума раньше!!! Собеседование, прошла, но насколько оно было нерво-трепательным не передать, так что, вдруг кому поможет, читайте книгу Р.Савина, там весьма доступно все это разжевывается. И еще, у всех менеджеров покер-фейс еще тот, так что если вас будут спрашивать "это все?" или "что-нибудь еще?", говорите - да, мол, все. лучше так. чем мычать, пытаясь вспомнить, то чего просто может не быть))

Ну вроде и на википедии это есть? http://ru.wikipedia....ого_обеспечения

вот эти вопросы один в один использовались на собеседовании, в одной компании, куда я устраивалсь на работу. Хочу сказать, что жаль, не видела этого форума раньше!!! Собеседование, прошла, но насколько оно было нерво-трепательным не передать, так что, вдруг кому поможет, читайте книгу Р.Савина, там весьма доступно все это разжевывается. И еще, у всех менеджеров покер-фейс еще тот, так что если вас будут спрашивать "это все?" или "что-нибудь еще?", говорите - да, мол, все. лучше так. чем мычать, пытаясь вспомнить, то чего просто может не быть))

Ну вроде и на википедии это есть? http://ru.wikipedia....ого_обеспечения

Не знаю был ли мой пост http://software-test...dpost__p__10613 первоисточником, но теперь эта классификация есть в википедии, в книге Савина, на тренингах Алексея Баранцева. Похоже эта классификация становится стандартом де факто.
Жаль, я хочу ее переписать...

Не знаю был ли мой пост http://software-test...dpost__p__10613 первоисточником, но теперь эта классификация есть в википедии, в книге Савина, на тренингах Алексея Баранцева. Похоже эта классификация становится стандартом де факто.
Жаль, я хочу ее переписать...

У Вас более развернуто.
И чисто по посту -- впечатление, что опыт в разработке ПО большой))) и разносторонний.