Программирование как "Антибиотик" проекта: "Одно лечим - другое калечим"

Shlackbaum
На сайте с 18.08.2010
Offline
311
5265

Коллеги, добрый день.

Я за советом к опытным программерам, тим-лидам или просто успешно управляющим командами с веб-разработкой.

-

Систематически возникает следующая проблема:

1) Программисты внедряют что-то на сайт - например новую категорию на сайте (или правки по старой категории).

2) Проверка внедряемого (собственно по поставленному ТЗ) не выявляет каких - либо проблем.

3) В местах, которые согласно ТЗ не были затрагиваемы проверяющим начинаются проблемы. Отвалилось что-то здесь, что-то там. Что-то еще появилось там где не должно было и так далее.

В результате получается, что задача проходит проверку, но полученный результат, если что-то слетело просто катастрофичен.

-

Есть несколько напрашивающихся "простых" вариантов решения:

1) После любой правки проверять все.

- Катастрофически нерентабельно с точки зрения ресурсов. Можно сократить время проверки знанием условно "глобальных переменных", которые участвуют не только в проверяемом разделе, но и в других. И таким образом проверять только те места, где еще участвует эта глобальная переменная. Но проблема в том, что зачастую нет данных о том, переменная глобальная или нет (если касается веб-сайта). То есть нет понимания, что конкретно это меню выводится не только в этом разделе, но еще и в другом месте. В общем и целом путь нерентабельный как я его вижу. И непонятно кто должен отвечать за эту проверку (чьи ресурсы уйдут на проверку) - программиста или специалиста, который проверяет задачу. Т.к. проверяющий свою задачу должен только ее и проверить, а не все вокруг.

-

2) Дать на "ковровую проверку" всем заинтересованным участникам.

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

-

3) Сложный механизм учета всех глобальных переменных до начала работ. Требует полного понимания программистом проекта до начала каких-либо работ (или же системы, которая будет "светить" об изменениях в конкретных местах проекта для учета). Слишком нерентабельно - требует огромного подготовительного периода, чтобы "что-то делать" - да и мне кажется так происходит только в случае если вся разработка была на одной команде. Если то один то другой подрядчик выполняет над проектом какие-то работы, то понять на этапе первых правок "что за что завязано" может быть крайне сложно. Если добавить сюда умельцев, которые делают мега-костыли, которые убивают собственно иерархию проекта, то путь вообще в никуда.

-

В общем проблема меня задолбала. Программисты, к которым я обращаюсь - разводят руками - "так все делают" - и либо одна правка вызывает 3 дополнительных косяка - либо тратят тонну ресурсов на перепроверку.

На форуме есть эксперты и опытные специалисты в боевых задачах - я взываю к вам, может быть вы нашли решение для избежания этой проблемы, когда программисты дай бог на 10 решение генерят 2 косяка и их надо исправлять. Но иногда программисты на 1 решении генерят 3 дополнительных проблемы. И это уже ну совсем плохо.

-

Вопрос:

Как правильно этот вопрос менеджерить?

Как правильно подготовиться к изменениям и внедрениям заранее?

Что предусмотреть, чтобы это было не слишком ресурсозатратно?

.

Спасибо

L
На сайте с 07.11.2013
Offline
56
#1

Программист -> тестировщик -> выкатка на боевой

Что то вы упустили в этой цепочке

Старый серч переехал на новый адрес => https://se.guru
Shlackbaum
На сайте с 18.08.2010
Offline
311
#2
lkolobok:
Программист -> тестировщик -> выкатка на боевой
Что то вы упустили в этой цепочке

Тестировщик тестирует по тому заданию, которое поставлено. И там все ок.

А летит то, что находится вне ТЗ. Потому что никто не планирует, что полетят те вещи, на которые ТЗ не стоит.

О том, насколько реально проверять "все всегда и подряд, даже если это не относится к ТЗ" п.1 моего решения

S
На сайте с 30.09.2016
Offline
459
#3

Shlackbaum, чтобы таких косяков не было, нужно, чтобы одна команда вела проект с начала и дальше. А если заказывать проект у одних разработчиков, потом подгонять "под себя" у других, а потом заказывать надстройки у третьих - так и будет. Или внедрять какой-нить гит, документирование связей, и т.д., и т.п.

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Z0
На сайте с 03.09.2009
Offline
731
#4
Sitealert:
Или внедрять какой-нить гит, документирование связей, и т.д., и т.п.

Так то дорого, противно и неинтересно. Вот и мучаются 🤪

Ваано
На сайте с 01.08.2009
Offline
112
#5

Как вариант автоматические тесты написать, как минимум на жизненно важный функционал.

Туры в Мексику тут (http://www.metmexico.com). Оптимальное отношение цена/качество.
Shlackbaum
На сайте с 18.08.2010
Offline
311
#6

koketkade, жопа...

K
На сайте с 22.11.2017
Offline
17
#7

сделать менее связанные сущности, писать и гонять автотесты, нанять архитектора

Solmyr
На сайте с 10.09.2007
Offline
494
#8

Либо надо более качественно понимать, что затрагивает данное изменение, либо тестировать все. В зависимости от того как вам будет проще.

Но первый вариант, как мне кажется, на практике не реален, невозможно сделать так чтобы проект все время поддерживали одни и те же люди, которые все помнят. Можно добиться чтобы дольше поддерживала одна команда, но все равно когда-то она поменяется. Потому мне кажется, что дешевле и правильнее - это автоматизация тестирования.

Lazy Badger
На сайте с 14.06.2017
Offline
178
#9

Shlackbaum, ваша проблема (не лично, а команды) в том, что у вас нет тестирования как бизнес-процесса, да и тестировщиков реально нет: есть "нажимальщики кнопок по расписанным кейсам"

Полностью все расписывать - долго и дорого, а если кратенько, то

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

- вам (в идеальном случае) придется радикально менять процесс разработки, так как любой правильный test-pipe начинается с unit-тестов... а их правильнее писать тому, кто написал/пишет тестируемые юниты

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

Из цепочки может быть исключен "системный" уровень (с осторожностью), если разработка неотчуждаемая и работает в известной стабильной внешней экосистеме. Стресс-тесты, тесты безопасности и тесты локализации (не перечисленные) также идут в категории "вам виднее", хотя любую поделку, которая имеет выход "в мир" и содержит информацию непубличную, я бы через security-тесты прогонял... но это уже - ваша зона ответственности решать, что делать: ограждаться от возможных хаков (неработающая система, утечка данных) или это не является болевой точкой

Самое главное (в идеале) - иметь по всей цепочке на каждом уровне 100% покрытие, чтобы не оставалось "слепых зон". Это долго, это дорого (потому что на чисто ручном тестировании "обезьянами" вы далеко не уедете или вся толпа обезьянок будут зашиваться в куче тестов, а разработка автотестов для автоматического тестирования - это примерно столько же по бюджету, как сам кодинг продукта), но это работающее решение

А скрам-спринты-агилька и прочий дрек - это оформления, это стиль, а не решение. У вас же сейчас - просто бардак, а "бардак автоматизировать нельзя"

Производство жести методом непрерывного отжига
SV
На сайте с 03.11.2008
Offline
1381
#10

Топик не читал, стартпоста осилил только картинку, но ответ (точнее причина) давно понятна:

Shlackbaum:
Соответственно абсолютно логично, что я посмотрю предложения ваших коллег по цеху и отбросив (или даже не отбросив) специалистов, характеристики которых мне не понравятся (портфолио, отзывы и прочее) - я просто выберу специалиста с минимальной стоимостью из предложенных

Какие тут тестировщики, коллеги :)

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Топики помощи с ⓌordPress (https://searchengines.guru/ru/forum/1032910 ) и основы безопасности сайтов ( https://searchengines.guru/ru/forum/774117 ). *** Помощь\консультации в топиках форума - БЕСПЛАТНО. Платные услуги ( https://wp.me/P3YHjQ-3 ) - с бюджетом от 150$ ***

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий