Сообщений в теме: 4

[July Kuzmicheva]

Автор: Дейв Вестервельд (Dave Westerveld)

 

Оригинал статьи: http://blog.testproj...-to-test-tests/

 

Перевод: Ольга Алифанова

 

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

 

Читать публикацию полностью

[checo]

Интересно, а есть ли статьи, как тестировать сами тестовые наборы (в принципе, а не автоматизированные)?

[SALar]

Может поможет, может нет:

"Написание тестов, как вид тестирования требований" 

 

У Коберна неплохой список тестов.

У Орлова по архитектурным ошибкам.

 

Но может я просто не понял вопроса.

[checo]

Да просто заголовок вселил надежду, что там будет рассказана какая-нибудь методика проверки качества тестов в целом. А там снова про автоматизацию.

 

Вопрос в том, можно ли эффективно проверить качество тестов заранее, а не когда повалятся баг-репорты с прода. Когда тестов пишется много, проверять все нереально.

 

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

[SALar]

Первое правило: автоматизация процесса "поиска дефектов", как правило невыгодна.

Второе правило: "Начинать автоматизацию с регрессионного тестирования - бессмысленно."