Хочу поделиться идеей, которую мы реализовали на одном из наших проектов. Изначально, проблема была в следующем: когда пакет выкладывался на RC окружение (release candidate) и начиналось финальное тестирование, админы частенько обнаруживали ошибки в серверных логах. Естесственно, такой пакет нельзя было катить в прод, несмотря на то, что внешне приложение ведёт себя адекватно и никаких других проблем обнаружено не было. Так почему нельзя? Потому что за этими ошибками легко не заметить реальные проблемы. Приходилось быстренько хот-фиксить причины этих ошибок, перевыкладывать пакет и заново всё тестировать. Всё это усугубляЛось тем, что выкладки в прод происходят каждый день, а значит потеря даже одного часа на перевыкладку сильно бьёт по производительности всей команды.
Мы стали думать - как можно обнаруживать подобные проблемы на ранних стадиях тестирования? Промежуточным вариантом стал специальный GET-параметр в запросе, при наличии которого внизу страницы появлялся блок, содержащий часть лога, относящегося к текущей сессии. Это позволило решить проблему, но было не очень юзабельно для тестировщиков. Главная проблема - не хочется смотреть логи, когда проблем нет!
Основной инструмент ручного тестировщика - браузер, а значит нужно научить браузер реагировать на ошибки в логах. Функциональность любого современного браузера легко расширяется плагинами, что мы и сделали. Получить логи не было проблемой - server-side уже умел их отдавать для вёрстки. Только теперь мы это делали незаметно для пользователя при заходе на тестовые среды. Ну а поскольку формат лога зафиксирован - найти в них ошибки и “зажечь лампочку” рядом с адресной строкой - раз плюнуть.
Вообще, формат браузерных плагинов кажется мне довольно перспективным. В них удобно интегрировать полу-автоматические инструменты для ручных тестировщиков - всё всегда под рукой.
comments powered by Disqus