среда, 21 октября 2015 г.

Скорость обратной связи в процессе «тест-баг-фикс»

Рассмотрим следущие петли обратной связи в процессе «тест-баг-фикс»:

  1. По способу применения
  2. По уровню тестов
  3. По формализации и уровню
  4. По исполнителю

Итак, что мы имеем в результате:

Быстрее всего найти баг может разработчик юниттестами на несобранном приложении, и при этом он может не заносить баг в БТС.

Средний по скорости вариант, это когда баг найден тестировщиком на уже собранном приложении, во время системного или приемочного тестирования, где все баги заносятся в БТС.

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


Что можно предложить, для того чтобы укоротить обратную связь?

  1. Увеличивать покрытие модульными и интеграционными тестами
  2. Привлекать тестировщиков к созданию тестов на уровне кода и API (иногда тестировщики могут более точно и оптимально подобрать тестовые данные на основании раличных техник тест дизайна)
  3. Автоматизировать дымовые и приемочные тесты
  4. Увеличить надежность и скорость прогона системных автоматических тестов (исключить ложные падения, использовать многопоточность, оптимизировать код тестов, исключить дублирующие проверки, использовать мок объекты и заглушки, там где можно)
  5. ...

Отправить комментарий

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.