Готовим к выходу очередную версию продукта. Новые билды в тестирование получаем каждые 2 недели. Мне поручили тестировать модуль, который уже работает в продакшине, но которым мало кто пользуется. Выпустили его еще до прихода тестеров на проект, поэтому там якобы куча багов и я должен их всех изловить и ножки им по откручивать.
Весь на энтузиазме я взял да и заавтоматизировал кучку тестов.
Раунд 1, 2
Мой модуль не работает вообще.
Раунд 3
Через день авто-тестирования вскрылось, что наш сервер падает при непрерывной нагрузке. Причем происходит это эдак минут через 30. Все улыбнулись, что-то подкрутили, и заявили, что бага исправлена.
Раунд 4
Запускаю тесты, теперь сервер отваливается через час. Бага сразу понизилась в приоритете нашими доблестными менеджерами и висит на девелоперах в ожидании своего окончательного закрытия. Между бесконечными рестартами сервера успеваю найти еще пачку багов, причем очень специфических, связанных именно с интеграцией модуля, в нашу систему. Все покачали головой и решили, что чинить её надо, но как - никто не знает, поэтому ее назначили на руководителя разработки для дальнейшего исправления.
Раунд 5
Мой модуль не работает вообще.
Раунд 6
"А земля-то вертится".
Модуль работает, но все также отваливается через час работы, все открытые мной баги либо отклоняют с комментариями: "Так работает 100 лет, так и будет работать дальше, так что не мешай мальчик" , либо просто откладываются для принятия решения в последний момент :(
До выхода в продакшн осталось 2 месяца...
Скажите, Вам такое знакомо?
четверг, 24 сентября 2009 г.
Сказка - быль, да в ней намёк
Подписаться на:
Комментарии к сообщению (Atom)
Сообщения
8 комментариев:
Да.
не знакомо, Agile рулит )
знакомо, да :)
а никакого представителя заказчика нет? CRMа, человека хорошо знающего подобные продукты, best practices? Такой человек мог бы помочь доказать, что если это "так работало сто лет", значит оно просто работало неправильно и надо исправлять...
А вообще, я так понимаю, этот модуль и баги на него низкоприоритетны как раз потому, что им мало кто пользуется. Хотя падать каждый час конечно не дело.
Есть такая тема как политическая борьба за влияние внутри очень большой организации. Благодаря этой самой политике вот такая вот Ж и происходит в описанной выше истории. Люди которые знают что и как должно работать, давят на руководство группы разработки, которое не желая показаться некомпетентной, делает все что можно, для того, чтобы не афишировать проблемы на проекте. А проблемы эти мониторятся фильтрами в багтрекере и поэтому: "Нет багов - нет проблем". А остальное - путь огнем горит.
Теперь про модуль. Да им сейчас мало кто пользуется, но в будущем планируют его массовое использование, которое сейчас не представляется возможным из-за проблем со стабильностью. Но такое ощущение, что это волнует только меня...
Вот.
Еще как знакома ситуация :)
"не желая показаться некомпетентной"
Наверное, один из первых признаков некомпетентности )
Тут есть пара вариантов в общем-то:
1. Дружить с этими людьми. Наладить контакт, поговорить не о тестировании и проекте а о футболе, сходить пива попить, в стрип-бар в конце концов. Получить доверие и расставлять приоритеты вместе с лидом девелоперов с минимальным вмешательством менеджера.
2. Обойти их процессом. Не брать в обсуждение проблем, не ставить в СС, вообще давать минимум информации о багах и состоянии проекта. Здесь все будет зависеть от отношений с разработчиками.
Вот так. Оба способа военные, не совсем честные, фактически возлагая большую часть ответственности за успех на вас, формально оставляя ее на менеджере. Можно пользовать как временное решение для некомпетентных менеджеров. В перспективе, конечно, приведет в аут.
А да, и еще.
"не знакомо, Agile рулит )"
Вот уж это слово скоро на заборах будут писать. Представляю, как приду со сгоревшим процессором в сервис, а мне там зарядят:
"Вот если бы вы по эджайл работали, ничего бы не случилось. Мы работаем по эджайл, поэтому сгоревший процессор видим впервые"
Я думаю, что такое невнимание к багам найденным в модуле и правда связано с тем, что "им мало пользуются юзеры". Тоесть критичность этого модуля где-то в разряде minimal. А, как известно, баги минимальной критичности всегда будут фикситься после багов с высокой и нормальной критичностью. все понимают логику почему так.
А насчет того что он падает каждый час - так это ж с высокой нагрусзкой (как я понимаю). Вы гоняете свои тесты непрерывно в течении часа. А в реальной жизни туда ходят раз в сутки. поэтому в реальности модуль работает и не падает. Что, чобственно, и треюуется от него. И, видимо, внезапного наплыва юзеров туда не ожидается. От того и не обращается внимание на Ваши результаты тестирования.
Конечно мы всегда хотим чтобы все было идеально, чтобы наши проекты выдерживали высокие нагрузки. В реальность все расскавляет по своим местам. Модуль удоблетворяет условию необходимой производительности - вот и ладненько.
Пример, если Вы знаете что Ваша семья за неделю съедает 3 кг картошки. Вы же не станете покупать 10 кг (хотя Петя Васечкин уверяет Вас, что нужно 10 кг ибо его семья съедает столько). В крайнем случае Вы купите 4 кг (на запас).
Спасибо всем за комментарии...
emeralda, вы пишите как человек, который кроме специфицированных требований не хочет видеть внегласных требований к качеству продукта: "ну падает, ну вы сами виноваты, что дали большую нагрузку, не давайте ее и все будет работать..."
А тестировать как? так же? по одному тест кейсу в день?
я даю "нагрузку", в оном потоке 150 транзакций подряд - система ложится на пол и лежит. Это что нагрузка для WEB приложения?
- Смешно.
Ну да и ладно, я дал мало информации, чтобы можно было спорить о том кто прав, а кто нет...
Просто я не менеджер, я смотрю прежде всего на качество, ну не куплю я телевизор, если он каждый час будет выключаться сам по себе. И мне было бы стыдно производить такие девайсы.
Вот.
Отправить комментарий