#тест_дизайн Печаль избыточного (излишнего) тестирования Кажд | Short QA ideas

#тест_дизайн
Печаль избыточного (излишнего) тестирования

Каждый раз, когда вы тестируете что-то "на всякий случай", в этом мире начинает плакать один лид.

Почему избыточное тестирование вредит проекту?
Ясно, что проверить что-то ещё разок обычно тянет лишь из благих намерений, но с другой стороны это:
1) увеличивает время на тестирование (потому что вместо 2 проверок ты проверяешь каждую из 100 страниц)
2) влияет на оценку времени и трудозатрат на задачу (ты никогда не знаешь, не захочется ли протестировать что-то ещё, потому что нет чёткого понимания, что протестировать нужно и достаточно)
Как результат пунктов 1 и 2, фича становится дороже, но не качественнее.
3) "замыливает" глаз (просто потому что внимание - конечный ресурс)
4) демотивирует исполнителя (как и любая бессмысленная монотонная деятельность)

Это ясно, но как понять, что я что-то делаю не так?
Признаки излишнего тестирования
1) вы тестируете, что-то "на всякий случай"
2) вы не можете обосновать, зачем нужна именно эта проверка
3) прохождение проверок даже мелких доработок фичи из раза в раз занимает по несколько часов

ок.
Что делать?
1) записываем проверки (в любом удобном формате), а не держим их в голове/на листочке и тд
2) вовремя размечаем статус прохождения проверок в тест ране (пока не успели забыть, проверен ли этот кейс и с какими данными)
3) лучше узнаём систему, которую тестируем (даже если в задаче написано, что изменения затронут все экраны приложения, это не значит, что их нельзя сгруппировать по общим критериям)
4) применяем техники тест-дизайна (ну хотя бы граничные значения и классы эквивалентности)

Если всё ещё остались сомнения в том, что весь критичный функционал покрыт:
- попробуйте исследовательское тестирование по турам
- проанализируйте причины пропущенных в прод багов (мы вот добавили Предполагаемую причину бага в шаблон баг-репорта)