Слышал у одного лектора мысль о том, что классификации нужны только для того, чтобы пройти собеседование. У С. Куликова этих классификаций наберется на целый постер. С другой стороны, если не заняться организацией тестов вовремя, совсем скоро в репозитории затеряется и сам их автор. Чтобы поддерживать порядок, я стараюсь использовать, как минимум, одну из самых известных — по степени важности
Думаю, что проект с любой спецификой сочетает в себе:
- дымовое тестирование (smoke) — тесты, которые направлены на проверку основной функциональности. Если они не прошли, то дальше тестировать нет смысла. Возможно ли вообще купить товар?
- тестирование критического пути (critical path) — ключевые последовательности действий пользователя. При изучении системы, например, с помощью карты функциональных возможностей, становятся видны самые длинные ветви — это и есть критические пути, которые, кстати, пришли к нам из одноименного метода управления проектами. Возможно ли купить товар со скидкой, воспользовавшись промокодом?
- расширенное тестирование (extended) — испытания с нестандартным использованием приложения, технологические границы и другие шутки про тестировщиков. Что будет, если добавить в корзину какой-нибудь товар в одной вкладке, в другой вкладке его удалить из корзины, а затем в первой вкладке приступить к оформлению заказа?
Между дымовым и критического пути ещё иногда вклинивают санитарное тестирование (sanity), но в его определении я встречал кучу разночтений. Из самого интересного — вот эта статья. Хороший момент, чтобы подчеркнуть, что понимание каждого из терминов крайне относительно, от команды к команде оно может сильно меняться