tgoop.com/QA_with_a_spoon/90
Last Update:
🌟 Проверки логирования в тестах (формулировка проблемы)
Эта тема давно у меня побаливает. Что конкретно болит? Например, вот это: в функциональные тесты довольно часто добавляются не только функциональные ожидаемые результаты, но и логи, которые тоже нужно проверить. То есть в одном тесте проверяется
- функциональный сценарий
- то, как этот сценарий залогирован
В чем проблема, собственно? Мне навскидку пришло в голову несколько.
Проблема 1: Консистентность бага тесту. Точнее, ее отсутствие.
Например, баг observability фейлит функциональный тест. Функционально некритичный баг фейлит функционально критичный кейс.
А что бы мне хотелось? Чтобы баги фейлили соответствующие тесты, чтобы была консистентность между багом и тестом. Критичный функциональный баг фейлит критичный функциональный тест. Мелкий баг про смещенную кнопку фейлит некритичный тест про отображение кнопки.
Из проблемы консистентности вытекает проблема прозрачности.
Проблема 2: Прозрачность документации.
Если функционально все ок, а в логах проблема (например, что-то не залогировано или есть эксепшен) - получается, я должна пометить этот кейс как failed.
То есть документация говорит: у нас не работает важный функциональный сценарий!
Чтобы увидеть, что проблема именно с логами, а не функциональностью, нужно уже посмотреть на баг репорт.
А что бы мне хотелось: чтобы документация максимально прозрачно показывала, какие есть проблемы и какова их критичность. Если в тест ране пофейлен тест про создание сделок - значит, у нас проблема именно с созданием сделок (а не с логированием, цветом кнопок, расположением окна создания сделки и т п). Если у нас проблема с логированием/цветом кнопок и т п - то тест на создание сделки Passed, тест на логирование/цвет кнопок и т п Failed.
Проблема 3: Затраты на прогон тестов.
Точно ли надо проверять логирование каждый раз, когда мы проверяем создание сделки? Какой риск мы хотим этим закрыть? Точно ли надо его закрывать именно этим способом? Не можем ли мы сэкономить время и силы, проверяя логи только тогда, когда это действительно нужно?
Если мы не можем аргументировать, почему мы тестируем это так - возможно, мы тестируем это просто по привычке, потому что так принято, потому что кто-то в прошлом написал тесты такого вида, а все остальные просто повторяют этот паттерн, принимая его на веру.
А что бы мне хотелось: чтобы мы не только тестировали то, что нужно протестировать, но и НЕ тестировали то, что НЕ нужно протестировать. Чтобы мы не только уточняли и расширяли тестовое покрытие там, где нужно, но и сокращали его там, где оно не нужно, и не делали работу, которую можно не делать.
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Share with your friend now:
tgoop.com/QA_with_a_spoon/90