Как важный фактор, который легко упускают из виду в процессе тестирования программного обеспечения, анализ дефектов, которые напрямую влияют на качество работы персонала, а в конечном результате на монетизацию проекта. Только полностью проанализировав дефекты, можно избежать беспокойства. Допуская ошибки в анализе дефектов, можно снизить свой личны…
Это и есть одна из основных проблем веб-проектов, которую можно обозвать никак иначе, как недооценка текущей ситуации, со всеми вытекающими последствиями: финансовыми потерями, занижением рейтинга среди подобных ресурсов и изменению отношений пользователей на отрицательный. А всего то надо было - ПРИНЯТЬ ПРОБЛЕМУ, РАЗОБРАТЬСЯ И ИСПРАВИТЬ и чем быстрей будет исправлено, тем больший вес получит ресурс. Это все отразится в отзовиках и прочих разговорнях.
Это и есть одна из проблем интернета — решать за компанию, что они недооценили.
Исправить надо согласно важности
проблемы. Может быть об этой проблеме знали 2.5 человека. Тогда исправить можно чуть позже, т.к. сейчас возможно что-то делается перед новым годом и всё загружены. Зачем исправлять проблему, которая может намного меньше принесет, чем новая фича? Но исправить надо, только позже.
А автор посчитал, что он лучше знает, как помогать компании. Для этого сделал огласку дыры спустя 3 дня(!). Смешно. Баги, даже уязвимости в топовых приложениях исправляются от нескольких
дней, до нескольких недель. А тут душа не выдержала 3 дня — срочно пилить пост! Да релизный цикл задачи во многих компаниях может занимать и неделю, как у меня, например. Так что ничего удивительного в том, что суперджоб не исправил баг за 3 дня, нет.
Но возможно, суперджобу просто пофиг на это и исправят как-нибудь потом :)
Дождемся ответа от их представителей