Сообщение сделало мой день) Дай пятюню!

Дожили. В субботу ночью обсуждение работы, девушки успокаивают, у мужской части сбился цикл. Мдаа.... 🧐

Дак это Олег постоянно эту тему гнёт. А тестировщики как связующее звено между менеджером, разработчиком, заказчиком и готовым продуктом никуда не денутся. Почему нельзя сразу построить процесс чтобы тестировщик в этом случае стал не нужен? Почему нельзя модифицировать процессы так чтобы тестировщик в этом случае был не нужен? Наверное потому что человеческий фактор, время-деньги, бизнес хочет так - никуда не денутся. Тестировщик как мне кажется особенно нужен в продуктах с разветвлённым клиентским флоу, который при этом постоянно меняется включая многие ключевые функции. Вишенка на торте это когда проект приправлен большим количеством легаси, когда небольшое изменение в одном месте ломает довольно сильно другое. Далее дополняем команду молодыми разрабами, которые не знают проект. И в итоге получаем проект- минное поле. Как в таком случае обойтись без опытного исследователя продукта, который бы искал это взаимосвязи, который бы сводил к минимуму влияние человеческого фактора? Который бы знал продукт со стороны пользователей? Обычная история менеджер с разрабом в личке договорились, в задачу изменения не внесли, или разраб делает, а потом менеджер задачу меняет. Привет тестировщику. Можно конечно жить в мире где на зелёных лугах пасутся единороги, но в реальности неужели всё так радужно у всех на проектах, что появляются мысли о тестировщиках массово выкинутых на мороз?  Вот есть задачка:Заказчики это внутренние отделы. Есть на тест 2 задачи, обе противоречат друг другу в каких-то аспектах. Заказчики, менеджеры и разрабы разные у задачи, а вот тестировщик один. Как выкинуть из этого процесса тестировщика? Т.к. никто кроме тестировщика не вкурсе этих противоречий в том числе из-за того что они не лежат на поверхности в описании задач? В общем моё мнение проекты типо Олега это скорее исключение, у них выходит учитывая их специфику и я за них рад, но думать о смене профессии из-за этого смысла не вижу. Если уж совсем жестить, то скажу QC будут живее всех живых и никуда в ближайшее время не денутся.

Хотя чего это я)

@ArtProfitRoll Артем, спасибо за мнение. Единственное, что я на самом деле гну - когда вы, люди из этого чата, будете принимать решения как делать разработку и тестирование, а вы будете принимать такие решения, вы должны знать правильные ответы, вы должны знать последствия, вы должны знать что "у нас нет времени" это не аргумент, вы должны знать что нельзя удовлетворить требования бизнеса о time to market хреновыми решениями, вы должны отдавать себе отчет и взять на себя ответственность за разгребание проблем которые вы создаете сейчас.

В конце концов, вы должны знать, что задача без автотестов - это не сделанная задача.

Прчнму нельзя сделать так, чтобы отдельная роль QA была не нужна? Многие так делают и успешно существуют. Но не все. Кому катке процессы обеспечения качества нравятся, кто в какие "верит". Вон люди верят, что написание автотесттв сходу поднимет качество

Правильных автотестов

Ты не учитываешь текущий уровень развития организации. Есть организации для которых это разумное решение - задача без автотестов

@alfemy про торг с собой я писал вчера

Я повторюсь-если ты киоск с шаурмой то тебе не нужны автотесты. С точки зрения бизнеса.

Какая выдалась неделя в этом чате жаркая)

@alfemy передергиваешь. просто хочу тебе напомнить что 100% разработчиков в нашей команде работают от силы 2 года, о каком зрелости, культуре или осознанности мы говорим?

Да нет, Саша просто указывает на ограничения. Если подходить к формулировкам серьезно, то надо учесть разные варианты и разные решения в этих вариантах.

Кстати, можем заняться и сформулировать.

Твоя зрелость и твой опыт уравновешивают молодость команды

Тесты можно не писать только в одном случае, если во всю систему больше никогда никто не будет вносить изменений, не апгрейдить фреймворк, не апгрейдить интерпретатор, не патчить дырявые зависимости.

Т.е. таких случаев не существует.

Нет. Можно не писать когда цена пропущеной ошибки меньше затрат на автотесты

С языка снял