а я где-то написал что он знает java? я вот твой кейс про "тесты" упомянул

а что Вы перечислили?

если мне как менеджеру надоели регрессии - я фасилитирую брэйншторм тех людей которые влияют на качество - то есть всей команды. Поставлю им цель мол "ребят заебали - что вам нужно что бы через пол года на 30% уменьшить количество регрессий при той же пропускной способности"

почитай.. хз

короч я понял что тебе не оч интересно это обсуждать потому хер с тобой. Пусть "менеджеры решают надо писать тесты или нет"

каким образом концепция тестов для php отличается от тестов на java?

У фрилансера просто нет тех проблем которые есть у команд

Поэтому и решения несуществующих для тебя проблем неприемлемы

каким образом похапэшник должен знать про DSM?

ты просто фокусируешь на одном каком-то аспекте разработки, а их на удивление много

а в чем проблема с DSM?

пример

допустим я менеджер у такой команды. И хочу уменьшить регрессии. Первое что я делаю - даю задачи нужным людям собрать метрики. Что бы основные метрики - cycle time, bugs leakage, done issues per 2 week - все это было перед глазами у команды.

Затем я спрашиваю - "хочу меньше регресий - ваши варианты" И тут пошло:

- ой у нас там эта старая херня вечно ломается
- ой тесты надо писать (всегда такие будут)
- ой эти пидорасы разработчики не тестят что делают
- ой эти дизайнеры не рисуют то что надо

В итоге у нас есть разные точки зрения не то почему появляются регрессии. Как следствие надо замерять какие факторы влияют. Просим ввести метрики по багам - трекаем компоненты где баги появляются, вводим рут козы по основным категориям:

- "проебались при составлении требований"
- "проебались при разработке"
- "проебались при проектировании"
- "проебались в коммуникациях"

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

Дальше оказывается что скажем треть всех багов из-за того что какие-то нюансы не обсудили на момент когда задачу брали в работу. Условно не проверили такой-то кейс. И вместо того что бы инвестировать в тесты которых нет мы можем ввести составление чеклистов ДО разработки которые согласованы с QA.

Вжух минус 30% регрессий без дорогих инвестиций.

дальше там "хочу cycle time уменьшить" - выясняется что задачи "подвисают" из-за нагрузки на QA которые заняты ручной регрессией - окей, не вопрос, ставим цель уменьшить тест сюиту для ручной регрессии и что для этого надо.

и т .д.

а зачем знать разные точки зрения команды?
Нужно собрать необходимые метрики, и проанализировав - выставлять приоритет задач

ты их узнаешь, хочешь ты этого или нет)

да это понятно. Просто на них опираться зачем?

в 30-е годы в японии был один дядька который это все придумал. мол не эффективно если ходят менеджеры с секундомером по конвееру и потом "думают как улучшить дела". Лучше отдать секундомер работнику и он больше идей для оптимизаций нагеренит и у него фидбэк быстрее и он лучше понимает проблемы с которыми сталкивается

там не было про то что на них надо опираться, а про то что они размыты и непонятны

эту "новую" идею сейчас модно называть Lean Manufacture.