Когда тестировать?
- Статистика говорит о том, что более 50% дефектов вносится в программу до кодирования.
- Исходя из теории ограничений, контроль качества до узкого места приносит огромный эффект и является одним из мощнейших способов поднятия производительности фирмы.
- Исходя из теории ограничений, узким местом следует делать самый дорогой или уникальный участок.
- Статистика говорит о том, что кодирование, как правило, является самым дорогим участком.
Возможно внедрение контроля качества до кодирования является одним из перспективнейших способов увеличения производительности фирмы по разработке ПО?
Я полагаю, что да.
22 Апрель 2011 в 18:09
Средства для этого, как ни странно. уже давно известны. Это формальные инспекции требований (особенно тест планов) и Specification By Example - определение тест планов перед написанием кода.
22 Апрель 2011 в 22:17
Замечательно. Но вот насколько часто применяется?
2 Август 2011 в 17:36
“Исходя из теории ограничений, узким местом следует делать самый дорогой или уникальный участок.” А разве не самый менее производительный участок?
Я ксати тоже сейчас дочитываю книгу по ТОС, вот только все никак не хватает времени, что бы сесть и основательно помозговать, как наиболее правильно\эффективно перенести теорию на разработку ПО.
3 Август 2011 в 11:41
“Самый дорогой” - в том смысле, что на обработку одной единицы заказа на этом участке расходуется наибольшее количество ресурса (времени, кВт*ч, …).
Для усредненной системы в 125KLOC распределение затрат:
* Требования - 7%
* Архитектура - 15%
* Конструирование - 44%
* Тестирование - 23%
* Управление - 11%
Конструирование - наиболее дорогой участок. Вот перед ним и надо ставить ОТК.
3 Август 2011 в 14:25
Сергей, тогда такой вопрос:
В ТОС акцентируется внимание на производственном _процессе_, если я не ошибаюсь. Но процесс разработки ПО не будет выглядеть как вы его описали, ведь будут иттерации “багофикс - тестирование”, которых будет столько же сколько и версий продукта, а кроме того, в паралели будет проходить тестирование кейсов и имплементация нового функционала\требований. Я веду у ктому, что нельзя сказать, что тестирование идет раздельно с конструированием, ведь даже когда пишут первую верси-костяк, в это время пишутся ТС скелетоны. Это и есть для меня самая больша ятрудность в том, чтобы перенести ТОС на разработку в полной мере… Что вы думаете по этому поводу?
4 Август 2011 в 13:57
> Я веду у ктому, что нельзя сказать, что тестирование идет раздельно с конструированием
Мои поздравления. Вы готовы к убийству очередной “Священной коровы”.
IMHO. Тестирование не является и никогда не являлось самостоятельной стадией разработки ПО. Выделение тестирования в отдельную стадию - грубейшая ошибка, которая приводит к путанице в дальнейших рассуждениях. Результат - чудовищно неэффективные процессы.
Более правильной будет схема, подобная этой:
*Требования
* * Разработка требований
* * Верификация требований
* Архитектура
* * Разработка Архитектуры
* * Верификация Архитектуры
* Конструирование кода
* * Разработка кода
* * Верификация кода
* Конструирование пользовательской документации
* * Разработка документации
* * Верификация документации
* Поставка
* * собственно поставка
* * Верификация поставки
Вот с такой схемой уже можно работать.
Но она только кажется простой. Дело в том, что у инженеров неизбежно будет частичная кросфункциональность. Так тестировщики будут заниматься и “Верификацией требований” и “Верификацией кода”. Поиск ограничений в такой системе и управление потоком заказов - дело не слишком простое. Роищите диск к книге ” Manufacturing at Warp Speed” (Детмер Уильям, Шрагенхайм Эли - “Производство с невероятной скоростью”) и поиграйте на кошечках.
> ведь даже когда пишут первую верси-костяк, в это время пишутся ТС скелетоны
Естественно. Весь смысл автоматизации тестирования - это уменьшение времени итерации, пусть даже ценой существенного увеличения цены единицы продукции. “Ну и что с того, что вместо 10 ручных тестировщиков у нас теперь 30 автоматизаторов, зато мы сократили цикл поставки на треть”.
Последовательность:
code - test - fix - test - fix
являлась серьезным ОГРАНИЧЕНИЕМ уменьшения времени поставки. Возможность паралельно вести разработку кода и тестов - огромный шаг вперед. Следующий шаг - тесты гоняют программеры, а не тестировщики (еще одна священная корова). Таким образом можно избежать потерь на переключение контекста. Написал код и гоняй тесты пока модуль не будет отлажен. Кстати. Ручное занесение дефектов в трекер также становится атавизмом, который надо прибить (еще одна священная корова).
Успехов.