Не однократно сталкиваюсь с такой ситуацией, что как не тестируй продукт, все равно качество остается на том же уровне (используя 10-20% всего функционала - работает норм, если идет увеличения % использования, то начинается цирк), потому что код спроектирован и написан мягко говоря - оторви и выкинь ))).
И самое, что обидное - это не понимание “проект менеджеров”, что это будет бесконечно крутиться в цикле, лучше продукт не становиться с добавлением новых фитчей. На критику с моей стороны, ответ единый - в силу большого динамического роста нового функционала. нет времени все переделывать!
Коллеги возникает вопрос, а есть ли вообще будущее у таких продуктов?
Будущее есть: когда все эти проблемы начнут всплывать на live, и разгневанные юзеры в итоге не захотят пользоваться продуктом, выбрав более вменяемую альтернативу, - весь тим дружно соберут на поминки. Оставят может пару человек на саппорт для тех отчаянных клиентов, которые все еще верят в продукт. Остальных разгонят с фразами - “Это бизнес, детка. Но ты не переживай. Завтра мы возьмем новый проект, чтобы через 2 года ты нам сказал тоже самое по поводу качества. И возможно мы даже к тебе прислушаемся. Хотя, вряд ли…”.
П.С. Если никто в компании не прислушивается к QA - пора менять компанию. Но тут еще дело в компетентности сотрудников, которые не в состоянии должным образом построить процессы.
Ну а если как таковой альтернативы на отечественном рынке нет? И как показывает практика пользователи не используют весь функционал ПО, Вы правильно сказали, что рано или поздно все равно будут оказываться (или пользователям будут обещать золотые горы, а на деле пустые обещания)
Ну тут еще может играть роль политика самой компании. Если это аутсорс, то есть такой тип исполнителей, которые целенаправленно говнокодят пишут плохой код, чтобы у них всегда была работа. На поздних этапах разработки заказчик уже вряд ли уже откажется от команды в пользу другой компании, ибо итоговые затраты будут превышать стоимость нового костыля у текущей. Разве что только вовсе закрыть продукт.
Так что тут либо вам флаг в руки, дабы поставить полноценные QA процессы на новом проекте, либо придется сидеть и плакаться в тряпочку о том, как все плохо. Хотя и тут есть свои подводные камни. От одного человека мало что зависит. Тут нужно взять хотя бы по 1 толковому лиду для каждой роли.
Желание “протестировать все” конечно отлично, но есть реальный мир, который задает нам жесткие сроки и рамки (бюджет, человеко-часы и т.д.). Есть множество проектов у которых “под капотом” все очень и очень печально. Причем многие из них используются нами в повседневности. Но из-за того, что используется нами лишь часть существующего функционала, то многие ошибки могут спокойно себе жить тихо-мирно от релиза к релизу и никому не мешать. Это конечно, не значит что это хорошо и так и должно быть. Но в коде часто встречаются вообще “мертвые” куски, которые никогда не исполняются.
Кто бы что ни говорил, но за качество кода в первую очередь несет ответственность тот кто его пишет. А это делает далеко не QA. Его задача - построить процессы. Сделать так, чтобы говнокодить было сложно и мучительно, но писать хорошо - легко и приятно. К сожалению, в 95% (тут может быть любая другая цифра от 80% до 99,99%) случаев QA имеет мало влияния на разработку и вообще расценивается больше как приемка.
В реальности сталкиваюсь часто либо с излишней бюрократизацией процесса и попытками замерить всякие странные и непонятные показатели (для галочки/начальства), либо отсутствием всяких метрик как таковых. Золотой середины почти не встречал.
P.S. слышал истории про “говнокодящий” аутсорс, но это не всегда правда. И уж точно не всегда делается с каким-то “злым” умыслом. В большинстве случаев там просто слабее компетенции (часто берут новичков после ВУЗа или на последних курсах). Как итог они просто не имеют достаточной квалификации. Еще бывают “неадекватные” сроки. Из-за которых хочешь не хочешь, а начинаешь говнокодить и делать методом “копи-паста”. Потому что нужно сделать уже сейчас, а времени на посидеть и продумать архитектуру нет и не предвидится в ближайшее время.
Просто в любом деле должна быть заинтересованность всей команды, а не отдельных личностей! Из этого всего и вытекает: нестабильность команды, колоссальная текучесть кадров и т.д. Итог: game over конторы
testomat.io управление авто тестами
Но тут еще дело в компетентности сотрудников, которые не в состоянии должным образом построить процессы.