Ода скриптовому тестированию

Автор: Наталья Руколь

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

Словарь

В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое

Читать дальше

Автор: Наталья Руколь

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

Словарь

В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое

Читать дальше

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

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

Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))

Почему нельзя называть скриптовое и исследовательское тестирование подходами? Можно какое-нибудь определение слова и что именно в этом контексте противоречит значению слова?

Аа!!!
Запуталась!

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

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?

"документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"

хм... ну если есть требования(спецификация) можно заниматься анализом.
Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?

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

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?

По этим тестам, которые "во время" - потом еще тестирование планируется?

По этим тестам, которые "во время" - потом еще тестирование планируется?

Да.

Т.е. в рамках статьи скриптовое тестирование - - это когда тесты написаны ДО начала тестирования. Так?
А если тесты документируюся ВО время тестирования -- то это уже НЕ скриптовое?

В тот момент, когда мы тестируем не по заранее созданным тестам, тестирование НЕ скриптовое. Если в процессе такого тестирования мы создаём тесты, а потом по ним будем осуществлять планирование и тестирование, то последующие итерации будут в скриптовом тестировании.

"документирование тестов — финальный этап тест-дизайна, которому неизбежно способствует анализ, создание карты продукта/функционала, разбиение на классы, поиск границ, выбор оптимального подхода для комбинаторики…"
хм... ну если есть требования(спецификация) можно заниматься анализом.

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

Правда, зачем карту создавать - непонятно. Чтоб требования (спецификацию) осмыслить?

Если вкратце, то да.

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

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

А как только включили софт и стали смотреть -- так и тестирование вроде как началось, ок?

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

Ок. Ок.
Серьмяга статьи в том, что тесты (как и кулинарные рецепты домашней выпечки) полезно документировать.

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

Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).

Если есть требования - ставить плюсики рядом с проверенными.
+ Code Coverage, если вообще никакой документации нет.

Если есть требования - ставить плюсики рядом с проверенными.
+ Code Coverage, если вообще никакой документации нет.

а диаграммы раскрашивать фломастерами.....

Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).

Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).

Кстати, технически это несложно сделать. Большинство сред исполнения/framework-ов позволяют записать, какие строчки кода вызывались хотя бы один раз за определенный интервал времени (profiling/tracing). Независимо от степени документированности тестов можно померять % строк кода, которые выполнились за одну сессию/сеанс/раунд/прогон тестирования.

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

...
Я лично не представляю, как НЕ документируя тесты, можно оценить покрытие.
Спасиб, если кто расскажет - КАК это сделать)).

Необязательно. Иногда можно пользоваться джедайскими техниками.
Например я знаю, что вменяемый модуль "оргструктура" для приличной (>1000 UC) КИС-ы для организации 5000+ человек должет содержать порядка десятка объектов класса:
* сотрудник
* позиция
* отдел
и прочее

Для кажного из объектов стандартный CRUDL и чего то нестандартное. Полсотни юзкейсов, несколько сотен тестов. В принципе все это можно смоделировать в голове без спецификации и без софта. Так же можно просто держа в голове эти 100 - 300 тестов провести их и не пропустить ни одного. В принципе можно. Но как говорил один мой хороший знакомый, очень хороший человек и очень, очень хороший специалист: "Так засрать мозг и оперативную память ради какой то фигни!"
------------
Из опыта. Спецификация на этот модуль пишется грамотным, опытном аналитиком примерно за неделю, почти без обращений к заказчику, потому как во всех организациях примерно одно и то же. И после 3-ей КИС-ы (лет 10 опыта) такие спеки можно писать не включая мозг. И тестировать тоже можно не включая мозг.
Ну потому опытных людей иногда и ищут. И что удивительно иногда им за этот опыт даже доплачивают.
------------

Было бы интересно глянуть , как Code Coverage без документированных тестов оценивалось ))).

Кстати, технически это несложно сделать. Большинство сред исполнения/framework-ов позволяют записать, какие строчки кода вызывались хотя бы один раз за определенный интервал времени (profiling/tracing). Независимо от степени документированности тестов можно померять % строк кода, которые выполнились за одну сессию/сеанс/раунд/прогон тестирования.

Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.

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

-- Гипотеза ------------------------
На мой взгляд, в статье забыта два важнейших выигрыша от реестра.

1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.

2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.

Указанные же в статье преимущества относительно менее значимы. Точно так же как забытая, но нежно любимая менеджерами и заказчиками возможность расчета трудоемкости.
-- Конец гипотезы ------------------------

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

Посмотрела энциклопедии по слову "подход" на предмет корректности этого термина в этом контексте. И всё равно не знаю, что ответить :))

Почему нельзя называть скриптовое и исследовательское тестирование подходами? Можно какое-нибудь определение слова и что именно в этом контексте противоречит значению слова?

Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.

Контекст такой: поскольку в нашей отрасли все термины являются переводами-кальками с английского, то подход == approach, and my favorite approach isn't scripted or exploratory but context-driven (black\white-box, whatever). Т.е. подход это нечто более глобальное чем просто техника\вид тестирования.

А! Тогда полностью согласна :)

1. Анализ. На пропуск. На избыточность. И на возможность формирования наборов.
Это именно анализ, а не обсуждение или утверждение. В одиночку он тоже прекрасно делается. Ну, при владении методами анализа.

Эм... Это же преимущество №1 в статье?

2. Распределение работ.
Имея реестр легко разбить работы на несколько человек. Не обязательно по тестированию, но так же, например, на автоматизацию тестов.

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

Да, это можно. Если что можете на картинки глянуть: http://blog.shumoos.com/archives/120
Плохо только, что мерика Code Coverage не очень хороша. Да позволяет или найти лишний код, или пропущенный тест. Но иногда. Только иногда.

Вопрос был "как померять", а не "хорошая ли это метрика".

А ссылка не совсем в тему. Речь шла именно про ручное тестирование, а не unit-testing, с которым обычно особых вопросов про оценку покрытия не возникает (у программистов).