Тестирование, выполняемое разработчиками
Разработчики обычно выполняют "чистые тесты" Разработчики склонны тестировать код на предмет того, работает ли он (чистые тесты), а не пытаться нарушить его работу всевозможными способами (грязные тесты). При незрелом процессе тестирования обычно выполняют около пяти чистых тестов на каждый грязный. В организациях со зрелым процессом тестирования на каждый чистый тест обычно приходятся пять грязных. Это отношение изменяется на противоположное не за счет снижения числа чистых тестов, а за счет создания в 25 раз большего числа грязных тестов ([Boris Beizer]).
Разработчики обычно идеализируют свой код. Они скорее проверяют, что код работает, чем он не работает. Но если код работает, то тестировщик(бывший разработчик) некачественно делает свою работу.Тк цель тестирования именно найти ошибки. Если разработчик рассчитывает, что в его коде нет ошибок, то он их там и не найдет.
Переключаться между двумя ипостасями хороший_тестировщик - хороший_разработчик сложно, но необходимо.
В X-Cart нет полноценного масштабного тестирования, поэтому основная надежда именно на тестирование, проводимое разработчиком.
Введена рекомендация
*Для каждой контрибуции указывается число чистых и грязных тестов.Рекомендуется кратко описывать все найденные и исправленные ошибки/проектные решения/исключения/предположения.
Соотношение грязь/чистота позволяет быть честным по отношению к себе.И быть средством самоконтроля.
Если ты проверил успешную регистрацию, проверил успешный checkout, создание ордера
ты сделал 3 чистых теста, но 0 грязных.
Для данного примера соотношение должно быть
3/15 или 3/12
Соотношение 3/0 показывает показывает, что тестирование проведено некачественно.
Мы только нашли узкую тропинку, по которой контрибуция работает,но не нашли огромное кол-во тропинок, когда контрибуция "заблудится"/не работает.
Мы не очертили границы контрибуции, мы не знаем, что она может делать, а что нет.
Значит контрибуция не работает.
Соотношения хуже 1:5-1:4 говорят, что контрибуция некачественная.
Кратко описывать ход разработки - полезно. Тк позволяет оглянуться назад и проверить
-какие области кода,наиболее подвержены ошибкам
-нет ли ошибок в требованиях
-исправлены ли корневые причины ошибок
-насколько зрелая контрибуция, сильно ли она "течет" по багам
-имеем ли мы утечку бензина/масла или это только легкий кондесат
-почему были приняты те или иные проектные решения.
-какие предположения были приняты
Одно из важнейших правил эволюционного развития ПП
Одно из важнейших правил эволюционного развития ПП
Главное ничего не сломать, а потом можно уже что-то менять/добавлять.
Если грязных тестов нет, то значит это правило игнорируется разработчиком.
Как подходить к выбору грязных/чистых тестов ?
Для каждой контрибуции есть область изменений - это каждая точка подключения/ каждое обращение к модулю.
и собственно сам модуль
-Области изменений
Нужно поднятся на 1-2-3 уровня места интеграции модуля и проверить все фишки, которые относятся к этому уровню.
Это кстати повод делать модуль, как можно более независимым.
-Сам модуль
Тут просто тестирование самого модуля, согласно спецификации.
Разработчики обычно выполняют "чистые тесты" Разработчики склонны тестировать код на предмет того, работает ли он (чистые тесты), а не пытаться нарушить его работу всевозможными способами (грязные тесты). При незрелом процессе тестирования обычно выполняют около пяти чистых тестов на каждый грязный. В организациях со зрелым процессом тестирования на каждый чистый тест обычно приходятся пять грязных. Это отношение изменяется на противоположное не за счет снижения числа чистых тестов, а за счет создания в 25 раз большего числа грязных тестов ([Boris Beizer]).
Разработчики обычно идеализируют свой код. Они скорее проверяют, что код работает, чем он не работает. Но если код работает, то тестировщик(бывший разработчик) некачественно делает свою работу.Тк цель тестирования именно найти ошибки. Если разработчик рассчитывает, что в его коде нет ошибок, то он их там и не найдет.
Переключаться между двумя ипостасями хороший_тестировщик - хороший_разработчик сложно, но необходимо.
В X-Cart нет полноценного масштабного тестирования, поэтому основная надежда именно на тестирование, проводимое разработчиком.
Введена рекомендация
*Для каждой контрибуции указывается число чистых и грязных тестов.Рекомендуется кратко описывать все найденные и исправленные ошибки/проектные решения/исключения/предположения.
Соотношение грязь/чистота позволяет быть честным по отношению к себе.И быть средством самоконтроля.
Если ты проверил успешную регистрацию, проверил успешный checkout, создание ордера
ты сделал 3 чистых теста, но 0 грязных.
Для данного примера соотношение должно быть
3/15 или 3/12
Соотношение 3/0 показывает показывает, что тестирование проведено некачественно.
Мы только нашли узкую тропинку, по которой контрибуция работает,но не нашли огромное кол-во тропинок, когда контрибуция "заблудится"/не работает.
Мы не очертили границы контрибуции, мы не знаем, что она может делать, а что нет.
Значит контрибуция не работает.
Соотношения хуже 1:5-1:4 говорят, что контрибуция некачественная.
Кратко описывать ход разработки - полезно. Тк позволяет оглянуться назад и проверить
-какие области кода,наиболее подвержены ошибкам
-нет ли ошибок в требованиях
-исправлены ли корневые причины ошибок
-насколько зрелая контрибуция, сильно ли она "течет" по багам
-имеем ли мы утечку бензина/масла или это только легкий кондесат
-почему были приняты те или иные проектные решения.
-какие предположения были приняты
Одно из важнейших правил эволюционного развития ПП
Одно из важнейших правил эволюционного развития ПП
Главное ничего не сломать, а потом можно уже что-то менять/добавлять.
Если грязных тестов нет, то значит это правило игнорируется разработчиком.
Как подходить к выбору грязных/чистых тестов ?
Для каждой контрибуции есть область изменений - это каждая точка подключения/ каждое обращение к модулю.
и собственно сам модуль
-Области изменений
Нужно поднятся на 1-2-3 уровня места интеграции модуля и проверить все фишки, которые относятся к этому уровню.
Это кстати повод делать модуль, как можно более независимым.
-Сам модуль
Тут просто тестирование самого модуля, согласно спецификации.
Комментариев нет:
Отправить комментарий