18 дек. 2008 г.

7 основных принципов Context-Driven школы тестирования.

Disclaimer: все переводы это личная забава автора, являются весьма вольными и ни на что не претендуют. Критика в комментариях приветствуется.
  1. Ценность каждого решения зависит от условий его применения.
  2. Есть много вариантов решений, но нет лучшего.
  3. Команда - самая важная составляющая любого проекта.
  4. Часто проекты отнимают много времени там, где мы этого не ждем.
  5. Продукт - это конечное решение. Если задача не решается, продукт не работает.
  6. Грамотное тестирование это сложный интеллектуальный процесс.
  7. Только здравый смысл и мастерство, совместно прилагаемые на протяжении всего проекта, позволят нам сделать все правильно и в срок, чтобы эффективно протестировать наши продукты.
Пояснения принципов в действии:
  • Группы тестирования существуют для выполнения работ связанных с тестированием. Они не участвуют в разработке; они обслуживают проект.
  • Тестирование выполняется от лица заинтересованных сторон - в процессе разработки, испытаний, отладки, исследования или реализации продукта. Совершенно разные стратегии тестирования могут быть применены для этих разных целей.
  • Совершенно нормально разным группам тестирования иметь разные цели. Методы достижения одной цели могут не подойти или быть антипродуктивными для достижения другой.
  • Неправильные метрики опасны.
  • Суть тест-кейса лежит в его возможности предоставить информацию (т.е. уменьшить неопределенность)
  • Все ошибаются. Даже если вам кажется что продукт проходит вашу проверку, он возможно сломается там где вы (или автотесты) этого не проверяли.
  • Автоматизированное тестирование это не автоматическое ручное тестирование: абсурдно подразумевать под автоматизированными тестами имитацию тестирования человеком.
  • Разные типы дефектов вскрываются разными типами тестов - тесты должны усложняться или нацеливаться на различные уязвимости чтобы программа становилась более стабильной.
  • Тестовые артефакты дают хороший результат когда они удовлетворяют соответствующим требованиям заинтересованных сторон.
Пример:

Рассмотрим два проекта:
  1. Разработка системы управления самолетом. Корректное поведение означает высочайшую техническую и математическую точность. Соответствие требованиям Федерального авиационного агентства. Всё, что вы делаете (или не делаете) может стать основанием для суда в течение 20 лет. В команде прививается инженерная культура в которой ценятся такие качества как осторожность, точность, повторяемость и двухсторонний контроль.
  2. Разработка текстового процессора для Веба. Корректное поведение в данном случае значит потакать огромному числу пользователей Microsoft Word для их привлечения к вашему продукту. Нет регулярных требований имеющих значение (кроме отвечающих общим потребностям). Через 20 месяцев надо выпустить продукт, хороший либо плохой. Команда не следует инженерной культуре, попытки следовать культуре из первого случая будут приводить к ущербу для окружающих.
  • Методы тестирования подходящие для первого проекта обречены на провал во втором.
  • Методы подходящие для второго будут выглядеть преступно халатными в первом.
Источник: http://www.context-driven-testing.com/

3 комментария:

Анонимный комментирует...

"Через 20 месяцев надо выпустить продукт, хороший либо плохой."

Учитывая, что перевод «вольный», предлагаю с "надо" употребить только "хороший", исключив " надо плохой". Понятно, что в сравнении с п.1 требований к конечному продукту меньше в п.2.

Анонимный комментирует...

Автор: Vita

bugsclock комментирует...

Не, не, не. Либо хороший, либо плохой, но надо выпустить (это типа требование бизнеса например). Плохой продукт ("плохость" понятие относительное) тоже имеет право на выпуск. Я как-нибудь расширю в блоге толкование этих принципов, дайте время...