;
Окей, гуру! Классические ошибки тестирования - тогда и теперь
«Давным-давно, кажется в прошлую пятницу, жил в одной стране
медвежонок, под именем Винни-Пух. А почему под именем?
Потому что над его дверью была надпись «Винни-Пух»,
а он под ней жил.»
А.Милн. «Винни-Пух и все-все-все»
Давным-давно, в 1997 году, Брайан Марик написал статью "Классические ошибки тестирования". В этой статье ошибки тестирования были классифицированы по нескольким областям, перечисленным ниже.
В 2009 году я провел анализ текущего состояния этих ошибок, и тогда тенденция казалась мне обнадёживающей.
Сейчас, через 11 лет, я решил провести новый анализ состояния этих ошибок и познакомить вас с моим мнением, оценками и сомнениями.
Но давайте по порядку.
Роль тестирования
Ошибки, обнаруженные Б. Мариком:
-
Представление о том, что тестировщики отвечают за обеспечение качества
-
Представление о том, что цель тестирования – найти дефекты
-
Представление о том, что тестировщики пропускают важные дефекты
-
Вопросы удобства использования системы не считаются важными
-
Нет фокуса на оценке качества (и качестве оценок)
-
Отчет о дефектах вне контекста их появления
-
Слишком позднее начало тестирования
Планирование трудозатрат на тестирование
-
Усилия по тестированию сосредоточены на функциональном тестировании
-
Недооценка роли конфигурационного тестирования
-
Откладывание до последней минуты стрессового и нагрузочного тестирования
-
Не тестируется документация
-
Не тестируется процедура установки системы
-
Переоценка надежд на бета-тестирование
-
Переход к выполнению тестовой задачи только после завершения предшествующей
-
Некорректная идентификация рисков
-
Жесткое следование плану тестирования
Личные качества
-
Тестирование как временная работа для новых программистов
-
Набор тестировщиков среди неудавшихся программистов
-
Тестировщики не владеют предметной областью тестируемого приложения
-
Тестировщик должен уметь программировать
-
Формирование команды тестировщиков, в которой отсутствует «личностное разнообразие»
-
Физическое разделение программистов и тестировщиков
-
Программисты не могут тестировать собственный код
-
Программистов не поощряют и не обучают тестировать
Работа тестировщика
-
Фокус на прогоне, а не на разработке тестов
-
Не проводится ревью проектирования тестов
-
Излишняя / недостаточная детализация тестовых сценариев
-
Не фиксируются и не исследуются «странные» ситуации
-
Проверка не только того, что система должна делать, но и того, что она не должна делать
-
Тестовые сценарии понятны только их авторам
-
Тестировщики используют только графический пользовательский интерфейс
-
Плохие описания дефектов
-
Недостаточность регрессионного тестирования при обнаружении нового дефекта
-
Игнорирование накопленного опыта тестирования
Автоматизация тестирования
-
Планирование автоматизации всех тестов
-
Автоматизация всех ручных тестов
-
Использование инструментов автоматической записи тестов через графический интерфейс
-
Ожидание большого числа новых дефектов при регрессионном тестировании
Покрытие кода
-
Тестирование против покрытия кода имеет ту же самую цель, что и тестирование против требований
-
Сокращение объемов регрессионного тестирования, поскольку оно не добавляет покрытия
-
Использование покрытия кода как метрики производительности тестировщиков
-
Полный отказ от покрытия кода
Что же улучшилось за 23 года?
К сожалению, особо ничего :(
Многие по-прежнему считают, что:
-
Тестировщики отвечают за качество, хотя цель тестирования – дать объективную оценку качества разрабатываемого и поставляемого продукта
-
Тестировать надо против требования, хотя есть и неявные требования, и в требованиях бывают ошибки
-
Серьезность дефекта можно устанавливать «по договоренности», а не на основании принятой всеми классификации
-
Метрики тестирования, статическое тестирование, модульное тестирование – без всего этого можно обойтись
-
Если каждую функцию можно протестировать отдельно, они прекрасно будут работать вместе
-
Документацию тестировать не надо, главное – протестировать систему
-
Никаких рисков в тестировании нет и быть не может
-
Любой может работать тестировщиком - знать и уметь для этого ничего не надо
-
Поиск тестировщиков не производится среди технических писателей и служб поддержки, хотя из них получаются прекрасные тестировщики, хорошо знающие систему и потребности пользователей
-
Тестовые сценарии – это излишество, в крайнем случае используются чек-листы
-
Если все тестовые сценарии перестали обнаруживать дефекты, тестирование закончено
-
Тестовые сценарии должны быть понятны только их авторам
-
Автоматизация всех ручных тестовых сценариев– это круто!
-
А автоматизация вообще без тестовых сценариев – это супер-пупер-круто!
-
Если автоматизировать регрессионное тестирование, можно найти гораздо больше дефектов
Как думаете, почему все это не так? Как это исправить?
Поделитесь мнением в комментариях
Ваш гуру, Александр
Расскажи друзьям: