Идеальный тестовый набор

Дню тестировщиков посвящается. С праздником коллеги!

— Разумный оценит достижение цели меньшим потом, так как труд нам дарован для созидания
(c) Притчи Шоу-Дао «ЧЬЕ ИСКУССТВО ЛУЧШЕ»

Примечание. В статье термин «тест» употребляется в значении «элементарная проверка»

Примечание 2. В моих логических построениях могут быть ошибки.

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

Попробуем зайти немного с другого конца.

Пусть для определения уровня тестовщика была создана программа, содержащая 100 ошибок одинаковой важности. Ни один дефект не блокирует тестирование. Тестировщиков просят составить тестовый набор и протестировать, используя его.

Полагаю, что гипотеза «Идеальный тестовый набор находит все ошибки» имеет право на существование. На практике идеальные тестовые наборы не встречаются. Наверное.

Но как минимум одним из критериев качества набора будет процент ошибок, который он находит.

Если:

«Тестировщик А» спроектировал и провел 1000 тестов и за неделю нашел 80 ошибок,
«Тестировщик Б» спроектировал и провел 1000 тестов и за неделю нашел 50 ошибок,

То тестовый набор «А» лучше. Но что делать с набором «В», который находит 90 ошибок, но содержит 10 000 тестов, а на проектирование и выполнение уходит 10 недель? Он лучше или хуже «А»?

Выдвинем еще одну гипотезу: «при равном количестве находимых ошибок лучше тот тестовый набор, на проектирование и выполнение которого требуется меньше времени». Сделав небольшое допущение переформулируем: «при равном количестве находимых ошибок лучше тот тестовый набор, который короче». Если есть три тестовых наборов в 100, 1000, 10 000 и все три находят все 100 ошибок, то ближе всех к идеалу первый.

Идеальный тестовый набор:

Находит все дефекты
Нет ни одного теста, который не находит ошибку

Если мне не изменяет память Луиза Тамре в своей книге приводит следующую рекомендацию: проведите тесты на граничные точки и на точки с обоих сторон от граничных. Т.е. если в требованиях сказано, что валидными являются любые двузначные число, то проверять надо на 9, 10, 11, 98, 99, 100. На мой же взгляд тесты на 11 и 98 явно лишние. Ошибки такого класса очень редки. Вместо этих тестов проведите тесты имеющие более высокую вероятность нахождения ошибок. В условиях дефицита времени рекомендация Луизы верный путь к уменьшению прибыли для большей части проектов.

Все? Нет, пока не все. Ситуации бывают разные. Пусть на тестирование вышеописанного приложения есть только 2 дня.

Тестировщик «Г» спроектировал и провел 450 тестов и нашел 60 ошибок.
Тестировщик «Д» отказался от проектирования. Провел 600 тестов, из них 50 по два раза и нашел 65 ошибок.

Тестовый набор «Д» — лучше.

Гипотеза. Когда времени очень мало, а задача стоит «Найдите хоть что-то, все равно мы все поправить не успеем» тестирование «свободным поиском» может оказаться очень эффективным.

Идеальный тестовый набор:

Находит все дефекты
Нет ни одного теста, который не находит ошибку
На проектирование и прогон уходит наименьшее время

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

Идеальный тестовый набор:

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

Можно внести еще несколько пунктов, но они малосущественны и более-менее очевидны.

Я же хочу сконцентрировать внимание на другом:
«Чем ближе программисты и тестировщики к идеальному тестовому набору и идеальному процессу отладки, тем они лучше.»

Полагаю здесь нет возражение? Или все таки есть? Потому что из этого следуют крушение нескольких иллюзий. А это больно.

Не желающих расставаться с иллюзиями рекомендую дальше не читать.

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

Второй вывод из статьи. Согласно одному из исследований, автоматизация теста в 10 раз дороже, чем ручной прогон.

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

«Чем более хороша команда, тем от большего числа автоматизированных регрессионных тестов они должны отказываться. Написание кода тестов после написания кода приложения – удел …»

Ну вы поняли.

Источник