Ода скриптовому тестированию
#1
Отправлено 30 мая 2012 - 16:42
Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.
Словарь
В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое
Читать дальше
Тренинги по тестированию ПО
#2
Отправлено 01 июня 2012 - 23:37
При всем уважении к автору, но называть скриптованное и исследовательское тестирование (и др.) подходами ошибочно. Это не более чем виды тестирования, которые замечательно комбинируются. Какой-то определенный баланс между ними, да, это уже подход.Автор: Наталья Руколь
Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.
Словарь
В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое
Читать дальше
#3
Отправлено 02 июня 2012 - 14:25
Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))При всем уважении к автору, но называть скриптованное и исследовательское тестирование (и др.) подходами ошибочно. Это не более чем виды тестирования, которые замечательно комбинируются. Какой-то определенный баланс между ними, да, это уже подход.
Почему нельзя называть скриптовое и исследовательское тестирование подходами? Можно какое-нибудь определение слова и что именно в этом контексте противоречит значению слова?
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#4
Отправлено 04 июня 2012 - 07:48
Запуталась!
"В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. "
Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?
"документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"
хм... ну если есть требования(спецификация) можно заниматься анализом.
Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?
Если нету требований (спецификации), то чтоб заниматься анализом, созданием карты, разбиением на классы.. и тыпы ---
то нужен сам софт, хоть как-то работающий. Чтоб включить и посмотреть - как он работает. Вроде - никак по-другому.
А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?
#5
Отправлено 04 июня 2012 - 09:03
Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?
По этим тестам, которые "во время" - потом еще тестирование планируется?
#6
Отправлено 04 июня 2012 - 09:20
По этим тестам, которые "во время" - потом еще тестирование планируется?
Да.
#7
Отправлено 05 июня 2012 - 03:42
В тот момент, когда мы тестируем не по заранее созданным тестам, тестирование НЕ скриптовое. Если в процессе такого тестирования мы создаём тесты, а потом по ним будем осуществлять планирование и тестирование, то последующие итерации будут в скриптовом тестировании.Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?
Ну требования всегда есть, если разработчики сидят код пишут. Вопрос только в их задокументированности. Чем менее детальны требования и спецификации, тем важнее тест-анализ."документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"
хм... ну если есть требования(спецификация) можно заниматься анализом.
Если вкратце, то да.Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?
Ну я вменяемо документированных требований никогда не встречала, а тест-анализ провожу всегда. Узнаю как и что должно работать, выясняю, продумываю тесты. И кстати проектирование тестов без учёта интерфейса делает их значительно более полезными, ориентированными на бизнес-логику, а не на чек-боксики и радио-баттоны.Если нету требований (спецификации), то чтоб заниматься анализом, созданием карты, разбиением на классы.. и тыпы ---
то нужен сам софт, хоть как-то работающий. Чтоб включить и посмотреть - как он работает. Вроде - никак по-другому.
Да, мы можем совмещать исследовательское тестирование с написанием тестов для последующего скриптового, не поняла, что в этом странного?А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?
Я не встречала условий, в которых бы можно было использовать только один подход, их обычно надо комбинировать.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#8
Отправлено 05 июня 2012 - 07:19
Серьмяга статьи в том, что тесты (как и кулинарные рецепты домашней выпечки) полезно документировать.
Про полноту покрытия тестами.
Ну во-первых, стоит сначала понять -- про какое именно покрытие речь идет.
Про покрытие функциональных требований или еще про какое.
Собственно, покрытие - величина считаемая.
Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).
#9
Отправлено 06 июня 2012 - 06:39
Если есть требования - ставить плюсики рядом с проверенными.Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).
+ Code Coverage, если вообще никакой документации нет.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#10
Отправлено 06 июня 2012 - 07:50
а диаграммы раскрашивать фломастерами.....Если есть требования - ставить плюсики рядом с проверенными.
+ Code Coverage, если вообще никакой документации нет.
Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).
#11
Отправлено 07 июня 2012 - 15:25
Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).
Кстати, технически это несложно сделать. Большинство сред исполнения/framework-ов позволяют записать, какие строчки кода вызывались хотя бы один раз за определенный интервал времени (profiling/tracing). Независимо от степени документированности тестов можно померять % строк кода, которые выполнились за одну сессию/сеанс/раунд/прогон тестирования.
#12
Отправлено 08 июня 2012 - 15:55
Если нету требований (спецификации), то чтоб заниматься анализом, созданием карты, разбиением на классы.. и тыпы ---
то нужен сам софт, хоть как-то работающий. Чтоб включить и посмотреть - как он работает. Вроде - никак по-другому.
А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?
Необязательно. Иногда можно пользоваться джедайскими техниками....
Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).
Например я знаю, что вменяемый модуль "оргструктура" для приличной (>1000 UC) КИС-ы для организации 5000+ человек должет содержать порядка десятка объектов класса:
* сотрудник
* позиция
* отдел
и прочее
Для кажного из объектов стандартный CRUDL и чего то нестандартное. Полсотни юзкейсов, несколько сотен тестов. В принципе все это можно смоделировать в голове без спецификации и без софта. Так же можно просто держа в голове эти 100 - 300 тестов провести их и не пропустить ни одного. В принципе можно. Но как говорил один мой хороший знакомый, очень хороший человек и очень, очень хороший специалист: "Так засрать мозг и оперативную память ради какой то фигни!"
------------
Из опыта. Спецификация на этот модуль пишется грамотным, опытном аналитиком примерно за неделю, почти без обращений к заказчику, потому как во всех организациях примерно одно и то же. И после 3-ей КИС-ы (лет 10 опыта) такие спеки можно писать не включая мозг. И тестировать тоже можно не включая мозг.
Ну потому опытных людей иногда и ищут. И что удивительно иногда им за этот опыт даже доплачивают.
------------
Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).
Кстати, технически это несложно сделать. Большинство сред исполнения/framework-ов позволяют записать, какие строчки кода вызывались хотя бы один раз за определенный интервал времени (profiling/tracing). Независимо от степени документированности тестов можно померять % строк кода, которые выполнились за одну сессию/сеанс/раунд/прогон тестирования.
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#13
Отправлено 08 июня 2012 - 16:04
Я сейчас пишу перечень предложений по тестированию. Ну и реестр тесткейсов там ка одно из. Мне проще проверить часть моих гипотез на форуме, тем более, что кому то это потом может пригодиться.
-- Гипотеза ------------------------
На мой взгляд, в статье забыта два важнейших выигрыша от реестра.
1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.
2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.
Указанные же в статье преимущества относительно менее значимы. Точно так же как забытая, но нежно любимая менеджерами и заказчиками возможность расчета трудоемкости.
-- Конец гипотезы ------------------------
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#14
Отправлено 08 июня 2012 - 22:41
Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))
При всем уважении к автору, но называть скриптованное и исследовательское тестирование (и др.) подходами ошибочно. Это не более чем виды тестирования, которые замечательно комбинируются. Какой-то определенный баланс между ними, да, это уже подход.
Почему нельзя называть скриптовое и исследовательское тестирование подходами? Можно какое-нибудь определение слова и что именно в этом контексте противоречит значению слова?
#15
Отправлено 09 июня 2012 - 01:27
А! Тогда полностью согласна :)Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#16
Отправлено 09 июня 2012 - 01:30
Эм... Это же преимущество №1 в статье?1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.
Я бы не сказала, что без скриптов нельзя грамотно разбить работу в команде, поэтому это сложно назвать преимуществом.2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.
Обучение для профессионалов: Школа тест-менеджеров | Школа тест-аналитиков | Школа Тестировщиков
Услуги для тест-менеджеров: Аутсорсинг тестирования | Поиск тестировщиков | Консалтинг
#17
Отправлено 09 июня 2012 - 07:01
Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.
Вопрос был "как померять", а не "хорошая ли это метрика".
А ссылка не совсем в тему. Речь шла именно про ручное тестирование, а не unit-testing, с которым обычно особых вопросов про оценку покрытия не возникает (у программистов).
Количество пользователей, читающих эту тему: 1
0 пользователей, 1 гостей, 0 анонимных