Ночные релизы: я снялся с глубокого ручника и кажется починил а) проблему с BUG: user_id=<...>; б) проблему с тем, что иногда комментарии долго не появлялись. Сейчас по-прежнему при очень плохом состоянии дел на сервере комментарии могут затормозить на неограниченное время, но состояние дел должно быть для этого очень и очень плохим — это будет исправлено отдельно.
как обычно, минутка размышлений о том, как можно было бы поймать эту проблему стандартными методиками автоматического тестирования. Она кросс-технологическая, она "мягкая" — нет ошибки как таковой, просто апдейты деприоритизируются. Она проявляется только при определенном сценарии, и при этом еще на сервере должен быть определенный паттерн траффика. Все это тривиально воспроизводится на живом сервере (в смысле, такие ошибки постоянно заметны там живым пользователям). Теперь, когда я знаю проблему, я могу, конечно, написать пост-фактум тесты, которые позволят не допустить регрессии в будущем — но вопрос-то в definition of an error. ‎- псы в рапиде
ну то есть сценарий был такой: раскрываешь комментарии; у тебя помечается, что при комментировании этого развернутого поста в tier0 должны попадать два ривера — основной и ривер отдельного поста, который отвечает за развернутые комментарии. ‎- псы в рапиде
ошибка была в том, что когда по развернутым комментариям приходили апдейты, то флажок, что второй ривер должен быть в tier0, терялся. В результате комментарий шел по стандартному пути, то есть через sidekiq. При хотя бы небольшой очереди комментариев это могло занимать существенное время. ‎- псы в рапиде
ну то есть в принципе наверное для этого и нужен QA, чтобы придумывать такие сценарии — развернуть, получить апдейт, прокомментировать, убедиться, что tier0 корректен. я что-то как-то если честно сомневаюсь, что этот сценарий можно придумать с чистого листа, а не по результатам бага. ‎- псы в рапиде
Ну тут есть практика и теория. На практике я обычно бьюсь головой о стену; в теории же тестеров заставляют для каждого бага искать аналогичные проблемы в других местах. То есть вообще QA не должны быть магами, с чистого листа выделяющими проблемные места — просто по результатам такой проблемы кто-то должен пойти и проверить, что еще может развалиться похожим образом. ‎- alf
^ fair enough. ну все равно, должен же быть понятен какой-то общий паттерн багов, которые _могут_ быть пойманы с чистого листа. а дальше уже пытаешься придумывать, как увеличивать кол-во таких паттернов. но вообще это конечно работа программиста. ‎- псы в рапиде
Не допускать регрессии в будущем это уже охенная штука же, особенно в растущей системе. ‎- адский хардлайн в засаде
Ну там вопрос, рассматривать ли гипотетического QA из книг Канера или спуститься на грешную землю. На земле самым надёжным способом остаётся спросить разработчика, что может развалиться — а потом пойти и постучать там, внимательно прислушиваясь. ‎- alf
И коллега прав, не допускать регрессии — это уже настолько круто, что обычно с лихвой окупает автоматизацию. ‎- alf
Что касается стандартных паттернов, ну есть же всякие каталоги и чеклисты, следом за ними анализ классов эквивалентности и граничных условий, etc. Это всё так или иначе работает, хоть и не модно и достаточно скучно. ‎- alf