Байки для оруженосца

Сергей Мартыненко, 2022

Это производственный роман о разработке программного обеспечения. Во многом вдохновение я черпал из цикла «Бета-тестеры», много лет печатавшийся в журнале «Лучшие компьютерные игры».Главы относительно слабо связаны и, в принципе, читать можно с любой.В книге довольно много отсылок к «Глубинным знаниям» по Демингу. Психология, теория вариаций, методы познания мира.Главы достаточно обильно разбавлены юмором. Но это же байки. Если вам не нравится такой стиль изложения, просто не читайте.Примеров кода практически нет. Я не хотел повторять другие книги.Целевая аудитория – IT-шники. Остальным вряд ли интересно.В книге отсутствуют сцены насилия, курения, секса, употребления алкоголя.

Оглавление

Байка для оруженосца 1. Немного о «вреде» тестирования

A. Тестировщики тормозят процесс разработки по Agile?

Q. Вопрос сформулирован неверно. Agile, не Agile — это перпендикулярное измерение. В малых проектах выделенный тестировщик тормозит процесс.

A. А в больших?

Q. Слишком часто тоже тормозит. Но по другой причине. В малых проектах имеет место эффект «чем больше команда, тем дольше делаем проект». В больших же имеем эффект «ограничение системы перенесено на самый дешевый участок».

A. Тестировщики необходимы.

Q. Не то чтобы необходимы, но иногда полезны. Иногда и только после того, как внедрены другие процессы.

A. Тестировщики нужны всегда!

Q. Меня берет сомнение, что уровень процесса тестирования может быть выше уровня процесса версионного контроля. Если версионный контроль на нуле, то надобность в выделенных тестировщиках вызывает сомнение.

A. Но ведь появление тестировщиков в индустрии принесло огромную пользу.

Q. В том виде, в котором происходило это внедрение — это скорее огромный вред. Модель разделения ролей «РУТ» (разработка, управление, тестирование) глубоко порочна.

A. Но без тестировщиков нельзя сделать сложный проект.

Q. Странно. Но делали же. Видимо, пацаны «не знали».

A. Тестирование позволяет лучше удовлетворить заказчика.

Q. Учитывая, что большая часть дефектов вносится в систему до кодирования, мне кажется, в высшей мере странным ставить ОТК только после кодирования. Контроль до кодирования принес бы куда больше пользы.

Смотрите также

а б в г д е ё ж з и й к л м н о п р с т у ф х ц ч ш щ э ю я