Вероятно, ваша цель включает в себя, помимо всего прочего, выявление серьезных проблем (на фоне незначительных) и это выявление должно быть быстрым. Если это так, то что это означает с точки зрения выполнения тестов?
- Тестируйте то, что изменилось а потом все остальное. Наибольшую опасность представляют исправления и обновления.
- Тестируйте основные функции перед второстепенными. Тестируйте самые важные и востребованные функции продукта. Тестируйте функционал который делает продукт продуктом.
- Тестируйте возможности прежде чем надежность. Тестируйте работают ли функции в принципе прежде чем детально углубляться в проверку работы каждой из них в различных условиях.
- Тестируйте обычные ситуации раньше эзотерических. Используйте распространенные данные и сценарии использования.
- Тестируйте распространенные опасности раньше экзотических. Тестируйте наиболее вероятные нагрузки и недопустимые состояния.
- Тестируйте на высоковредные проблемы прежде чем на безвредные. Тестируйте части продукта которые принесут большой ущерб в случае сбоя.
- Тестируйте самые востребованные области раньше незапрошенных. Тестируйте любые области и любые задачи, которые интересны кому-либо в команде.
Вы также будете находить важные проблемы раньше, если узнаете как можно больше о продукте, программном обеспечении и оборудовании, с которым он должен взаимодействовать и людях, которые будут его использовать. Изучайте это внимательно.
Из книги Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord
Disclaimer: все переводы это личная забава автора, являются весьма вольными и ни на что не претендуют. Критика в комментариях приветствуется.
- Ценность каждого решения зависит от условий его применения.
- Есть много вариантов решений, но нет лучшего.
- Команда - самая важная составляющая любого проекта.
- Часто проекты отнимают много времени там, где мы этого не ждем.
- Продукт - это конечное решение. Если задача не решается, продукт не работает.
- Грамотное тестирование это сложный интеллектуальный процесс.
- Только здравый смысл и мастерство, совместно прилагаемые на протяжении всего проекта, позволят нам сделать все правильно и в срок, чтобы эффективно протестировать наши продукты.
Пояснения принципов в действии:
- Группы тестирования существуют для выполнения работ связанных с тестированием. Они не участвуют в разработке; они обслуживают проект.
- Тестирование выполняется от лица заинтересованных сторон - в процессе разработки, испытаний, отладки, исследования или реализации продукта. Совершенно разные стратегии тестирования могут быть применены для этих разных целей.
- Совершенно нормально разным группам тестирования иметь разные цели. Методы достижения одной цели могут не подойти или быть антипродуктивными для достижения другой.
- Неправильные метрики опасны.
- Суть тест-кейса лежит в его возможности предоставить информацию (т.е. уменьшить неопределенность)
- Все ошибаются. Даже если вам кажется что продукт проходит вашу проверку, он возможно сломается там где вы (или автотесты) этого не проверяли.
- Автоматизированное тестирование это не автоматическое ручное тестирование: абсурдно подразумевать под автоматизированными тестами имитацию тестирования человеком.
- Разные типы дефектов вскрываются разными типами тестов - тесты должны усложняться или нацеливаться на различные уязвимости чтобы программа становилась более стабильной.
- Тестовые артефакты дают хороший результат когда они удовлетворяют соответствующим требованиям заинтересованных сторон.
Пример:
Рассмотрим два проекта:
- Разработка системы управления самолетом. Корректное поведение означает высочайшую техническую и математическую точность. Соответствие требованиям Федерального авиационного агентства. Всё, что вы делаете (или не делаете) может стать основанием для суда в течение 20 лет. В команде прививается инженерная культура в которой ценятся такие качества как осторожность, точность, повторяемость и двухсторонний контроль.
- Разработка текстового процессора для Веба. Корректное поведение в данном случае значит потакать огромному числу пользователей Microsoft Word для их привлечения к вашему продукту. Нет регулярных требований имеющих значение (кроме отвечающих общим потребностям). Через 20 месяцев надо выпустить продукт, хороший либо плохой. Команда не следует инженерной культуре, попытки следовать культуре из первого случая будут приводить к ущербу для окружающих.
- Методы тестирования подходящие для первого проекта обречены на провал во втором.
- Методы подходящие для второго будут выглядеть преступно халатными в первом.
Источник: http://www.context-driven-testing.com/
