Так Фредерик Брукс описывает разработку и тестирование софта примерно полвека назад:
Мы централизовали все наши машины и библиотеку магнитных лент и создали для обслуживания их работы профессиональную и опытную команду машинного зала. С целью максимизации скудного времени S/360 мы выполняли все отладочные прогоны пакетно на любой системе, которая была свободной и подходящей. Мы проводили четыре попытки в день (с оборотом в два с половиной часа) и запрашивали четырехчасовой оборот.
(…)
Отладка системы всегда становилась уделом ночной смены, как астрономия. Двадцать лет назад на 701-й я был посвящен в продуктивную неформальность предрассветных часов, когда начальники машинного зала крепко спят дома, а операторы нарушают правила.
Люди работали круглосуточно, чтобы машины не простаивали. Еще 20-30 лет назад крупное ПО полностью компилировалось раз в сутки и код выкладывался на тестирование. Там же:
Программист составлял тщательный дизайн своей процедуры отладки, планируя, где остановиться, какие области памяти проверять, что там найти и что делать, если он не найдет. Это дотошное программирование отладочной логики само по себе могло занимать половину времени от написания отлаживаемой программы.
Смертный грех состоял в том, чтобы смело нажимать кнопку START, не разбив программу на тестовые секции с запланированными остановами.
(…)
Вся процедура, однако, была составлена так, чтобы минимизировать потребление компьютерного времени и обслуживать как можно больше программистов.
Сейчас по ночам обычно спят, а инструменты всего цикла разработки ПО поменялись. У почти каждого разработчика в арсенале виртуальные машины, контейнеры и прочие докеры для экспериментов и не только. Тестировать и выкладывать даже большой код можно настолько часто, насколько это позволяет местный DevOps.
Несмотря на изменение технологий, часть книги про организационные вопросы разработки актуальна и сейчас. И не только для разработки.