Открыть список
Как стать автором
Обновить

Комментарии 11

Если ущерб от незакрытого дефекта не превышает затрат на его исправление, то исправлять дефект не надо;
Если ущерб от потенциального дефекта не превышает затрат на его поиск и исправление, то искать дефект не надо;

Это очень порочная практика, особенно из уст тестировщика. Даже не знаю, что из этого важнее почитать


https://en.wikipedia.org/wiki/Swiss_cheese_model
https://en.wikipedia.org/wiki/Broken_windows_theory

Ибо неизвестно как оценить и каким будет "суммарный ущерб"


Если суммарный ущерб от всех известных незакрытых дефектов не превышает выгоды от внедрения существующей версии системы, то её надо внедрять (пусть даже и с известными незакрытыми дефектами).
За ссылки спасибо.

Насчет порочности практики не согласен.
От слова совсем.
Объясняю.

Как оценивать затраты, нам известно.
Как оценивать ущерб, нам тоже известно.
Приходите, научим.
Точность оценки., естественно. варьируется.

После оценок выбирается самое экономичное решение.
Если бизнес готов заплатить не более $1000 за конкретную функцию, он не будет готов заплатить $10000 за ее починку.
Если же он готов заплатить $10000 за починку, то его первоначальная оценка оказалась неверной и ее надо скорректировать.

Надеюсь не увидеть от вас статью "как несколько, казалось бы несвязанных, minor bugs уронили прод" ;)

Если бизнес готов заплатить не более $1000 за конкретную функцию, он не будет готов заплатить $10000 за ее починку.
Если же он готов заплатить $10000 за починку, то его первоначальная оценка оказалась неверной и ее надо скорректировать.

Это ложная дихотомия, Вы отрицаете наличие других возможных причин:


  • Новый функционал был экспериментальным, бизнес еще думал, входить или нет на рынок.
  • Существующий функционал может быть включенным в контракт, а издержки от невыполнения контракта могут быть выше, чем стоимость разработки первоначального функционала

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

Ого, у вас есть Senior Team Lead, значит есть и Junior Team Lead?
Спасибо за комментарий! У нас есть только Senior Team Lead
Если бизнес готов заплатить не более $1000 за конкретную функцию, он не будет готов заплатить $10000 за ее починку.

Бизнес не знает на что он готов до тех пор пока не начнет подгорать.
Спасибо за комментарий. Что правда, то правда )
«Непонятно, что в проекте делают тестировщики. Если они поставляют ПО с дефектами – от этого проекту только хуже. Если они тест-кейсы пишут – да кому эти тест-кейсы нужны?!». Мне приходилось эту фразу слышать от топ-менеджмента неоднократно.

— как избавить тестировщиков от этих не очень корректных и не продуманных вопросов от менеджмента?
Спасибо за комментарий!

Да, такая практика имеет место.
Но мы умеем от нее избавляться с помощью:
• обучения как самих тестировщиков, так и топ-менеджмента
• грамотного управления рисками тестирования
• аргументированных оценок трудозатрат на тестирование
• того, что написано в этой статье.
Другими словами, с помощью всего, что называется управлением тестированием.

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

Информация

Дата основания
Местоположение
Россия
Сайт
career.luxoft.com
Численность
свыше 10 000 человек
Дата регистрации
Представитель
LuxoftRussia

Блог на Хабре