воскресенье, 8 ноября 2009 г.

Экстремальное тестирование

Хотелось бы уточнить название поста. Я хотел бы написать о тестировании в XP команде.
Экстремальное программирование XP базируется на 12 основных практиках:
  1. Разработка через тестирование (Test driven development)
  2. Игра в планирование (Planning game)
  3. Заказчик всегда рядом (Whole team, Onsite customer)
  4. Парное программирование (Pair programming)
  5. Непрерывная интеграция (Continuous Integration)
  6. Рефакторинг (Design Improvement, Refactor)
  7. Частые небольшие релизы (Small Releases)
  8. Простота (Simple design)
  9. Метафора системы (System metaphor)
  10. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
  11. Стандарт кодирования (Coding standard or Coding conventions)
  12. 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
Теперь же попробуем проецировать практики на тестирование.


  1. TDD вопреки популярному мнению программистов не отменяет отдел тестирования. Качество продукта это забота не только тестировщиков, но и программистов тоже. Я бы сказал так, что TDD это еще один шаг к улучшению качества продукта.
  2. При игре в планирование естественно должна участвовать команда тестирования, хотя бы для того, чтобы обозначить наиболее критичные участки ПО(баги к примеру).
  3. Заказчик рядом тоже является практикой для улучшения качества ПО. В некоторых случаях заказчик и является тестирующим звеном, при этом надо понимать, что должного качества команда подобным шагом может и не добиться (50 на 50 я бы сказал).
  4. Самую известную практику XP, я трансформировать не буду, потому что на тему "Парное тестирование" есть отличный пост от Панкратова написанный уже давно.
  5. CI во многих командах ложится на плечи команды тестирования, а именно: автоматизация сборки, прогон тестов, слежение результатов и т.д. Логика таких действий думаю понятна.
  6. Лично я, только за то, чтобы программисты рефакторили свой код. Им на помощь кроме юнит тестов, должны придти и автоматизированные функциональные тесты написанные QC
  7. Частые и небольшие релизы скорее направлены для того, чтобы команда была в тонусе. Если 2-й пункт был соблюден и тестировщики участвовали в планировании, то и провалов быть не должно(как правило)
  8. → Все эти практики направлены для разработчиков ПО. Применение данных практик для отдела тестирования, возможно лишь для автоматизированных функциональных тестов. Либо при проверке исходного кода на соответствию стандартов (по личному опыту бывает и такое)
  9. 40-часовая неделя скорее есть здравый смысл, поскольку как правило усредненная эффективная работа человека равна этому показателю. Тестировщики тоже люди и ничем от других не отличаются :)
В конце выскажу следующее: В начале хотелось описать собственные практики для ускорения процесса тестирования, но потом решил не связывать их с XP. Это было бы глупо описать свои советы прикрываясь громким заголовком. Свои методы опишу в одном из следующих постов.

P.S. Для холивара: Наиболее близкой школой тестирования по духу к agile методологиям считаю Context driven testing school (CDTS).

Комментариев нет:

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