;
Александр Александров

Окей, гуру! Классические ошибки тестирования - тогда и теперь

17.09.2020 151

«Давным-давно, кажется в прошлую пятницу, жил в одной стране
медвежонок, под именем Винни-Пух. А почему под именем?
Потому что над его дверью была надпись «Винни-Пух»,
а он под ней жил.»

А.Милн. «Винни-Пух и все-все-все»


Давным-давно, в 1997 году, Брайан Марик написал статью "Классические ошибки тестирования". В этой статье ошибки тестирования были классифицированы по нескольким областям, перечисленным ниже.

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

Сейчас, через 11 лет,  я решил провести новый анализ состояния этих ошибок и познакомить вас с моим мнением, оценками и сомнениями. 

Но давайте по порядку.

Роль тестирования

Ошибки, обнаруженные Б. Мариком:

  • Представление о том, что тестировщики отвечают за обеспечение качества

  • Представление о том, что цель тестирования – найти дефекты

  • Представление о том, что тестировщики пропускают важные дефекты

  • Вопросы удобства использования системы не считаются важными

  • Нет фокуса на оценке качества (и качестве оценок)

  • Отчет о дефектах вне контекста их появления

  • Слишком позднее начало тестирования

Планирование трудозатрат на тестирование

  • Усилия по тестированию сосредоточены на функциональном тестировании

  • Недооценка роли конфигурационного тестирования

  • Откладывание до последней минуты стрессового и нагрузочного тестирования

  • Не тестируется документация

  • Не тестируется процедура установки системы

  • Переоценка надежд на бета-тестирование

  • Переход к выполнению тестовой задачи только после завершения предшествующей

  • Некорректная идентификация рисков

  • Жесткое следование плану тестирования

Личные качества

  • Тестирование как временная работа для новых программистов

  • Набор тестировщиков среди неудавшихся программистов

  • Тестировщики не владеют предметной областью тестируемого приложения

  • Тестировщик должен уметь программировать

  • Формирование команды тестировщиков, в которой отсутствует «личностное разнообразие»

  • Физическое разделение программистов и тестировщиков

  • Программисты не могут тестировать собственный код

  • Программистов не поощряют и не обучают тестировать

Работа тестировщика

  • Фокус на прогоне, а не на разработке тестов

  • Не проводится ревью проектирования тестов

  • Излишняя / недостаточная детализация тестовых сценариев

  • Не фиксируются и не исследуются «странные» ситуации

  • Проверка не только того, что система должна делать, но и того, что она не должна делать

  • Тестовые сценарии понятны только их авторам

  • Тестировщики используют только графический пользовательский интерфейс

  • Плохие описания дефектов

  • Недостаточность регрессионного тестирования при обнаружении нового дефекта

  • Игнорирование накопленного опыта тестирования

Автоматизация тестирования

  • Планирование автоматизации всех тестов

  • Автоматизация всех ручных тестов

  • Использование  инструментов автоматической записи тестов через графический интерфейс

  • Ожидание большого числа новых дефектов при регрессионном тестировании

Покрытие кода

  • Тестирование против покрытия кода имеет ту же самую цель, что и тестирование против требований

  • Сокращение объемов регрессионного тестирования, поскольку оно не добавляет покрытия

  • Использование покрытия кода как метрики производительности тестировщиков

  • Полный отказ от покрытия кода

Bug

Что же улучшилось за 23 года?

К сожалению, особо ничего :(

Многие по-прежнему считают, что:

  • Тестировщики отвечают за качество, хотя цель тестирования – дать объективную оценку качества разрабатываемого и поставляемого продукта

  • Тестировать надо против требования, хотя есть и неявные требования, и в требованиях бывают ошибки

  • Серьезность дефекта можно устанавливать «по договоренности», а не на основании принятой всеми классификации

  • Метрики тестирования, статическое тестирование, модульное тестирование – без всего этого можно обойтись

  • Если каждую функцию можно протестировать отдельно, они прекрасно будут работать вместе

  • Документацию тестировать не надо, главное – протестировать систему

  • Никаких рисков в тестировании нет и быть не может

  • Любой может работать тестировщиком - знать и уметь для этого ничего не надо

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

  • Тестовые сценарии – это излишество, в крайнем случае используются чек-листы

  • Если все тестовые сценарии перестали обнаруживать дефекты, тестирование закончено

  • Тестовые сценарии должны быть понятны только их авторам

  • Автоматизация всех ручных тестовых сценариев– это круто!

  • А автоматизация вообще без тестовых сценариев – это супер-пупер-круто!

  • Если автоматизировать регрессионное тестирование, можно найти гораздо больше дефектов


Как думаете, почему все это не так? Как это исправить?

Поделитесь мнением в комментариях

Ваш гуру, Александр


Расскажи друзьям:

 
Оценка и обучение ИТ-специалистов по ключевым направлениям разработки программного обеспечения. Курсы от экспертов-практиков по языкам программирования, системному и бизнес-анализу, управлению проектами, тестированию ПО, архитектуре ПО. Luxoft Training – единственный учебный центр в России, авторизованный IIBA. Действует скидка 10% на обучение физических лиц.
   Подпишись на ежемесячный DigestLT
Успешная форма подписки.
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.