За счет чего может повыситься эффективность разработки?

Разработка бывает двух видов.
1. Персональная разработка.
2. Разработка в группе.

1.Персональная разработка.
Даже если у Вас все всегда работает, найдется пользователь, у которого ваш продукт не будет работать или будет работать иначе. Задача разработчика - найти ошибку и устранить. Без тестов Вы, как слепой котенок, идете по цепочке событий, отслеживая сбой, и хорошо, если у вас есть доступ к компьютеру, на котором возникли проблемы, а если доступа нет?
При использовании тестов, они сами покажут где проблема или значительно сузят ее поиск.
А ошибки могут быть из-за:

• Несовместимости с новой операционной средой
• Обновлений операционной системы
• Ошибок аппаратного обеспечения (материнской платы, видеокарты, жесткого диска и т.д.)
• Некорректной работы драйвера
• Ошибок в новой среде разработке или в новой версии компонентов

Где бы ни были ошибки, их искать и устранять Вам. Тесты помогают решить эту задачу.
Кроме поиска ошибок, тесты позволяют сделать оценку:

• Как будет работать ваш продукт в новой операционной среде?
• Насколько полно и быстро работает Ваша программа?
• Насколько новая среда разработки эффективнее, чем старая?

Кто ответит на эти вопросы, и сколько нужно потратить времени без тестов?
Пользователи могут работать с программой не так, как Вам хочется, а как Вам даже в голову не придет. И Ваша задача сделать проверку работоспособности программы на любой некорректный ввод или неправильное пользование Вашей программой.

2. Разработка в группе.
Для разработчика:
Если Вы работаете в команде, и ваши модули пересекаются с модулями других разработчиков, возможна ситуация, когда модификация других модулей может нарушить ваш работающий функционал.
Вы работаете над другим проектом, и вам «прилетает» претензия, что старый модуль который долго работал, сегодня не работает. Вы уверены, что ничего не меняли, но кто виноват?
Если нет тестов в вашем модуле, то разбираться Вам, где возникла ошибка.
С тестами же «головная боль» перекладывается на того, кто создал ошибку - это самое важное!
Вы освобождаетесь от дополнительной работы, у вас появляется ВРЕМЯ, которое Вы не будете тратить на исправление чужих ошибок.
Время - самый ценный ресурс, который ничем нельзя восполнить, оно только может тратиться, и чем старше становишься, тем больше этим проникаешься. И это свободное время вы можете потратить с большей пользой.
Для руководителя:
Если в компании один программист, и у него один простой продукт, задаешься вопросом: «Зачем нужны тесты?» Но у Вас группа программистов, которая использует общие библиотеки, модули, и тестирование становится очень важным этапом разработки.
Как контролировать работу программистов без тестов?
Программист говорит: «Все хорошо, все работает.» Это действительно так? Какие у Вас есть критерии оценки слов разработчика?
Отчет тестировщика?
Сколько процентов функционала протестирует тестировщик?
У тестировщика есть автоматические тесты?
А у программиста?
Имеется ли отчет программиста по выполненным тестам?
Он сдал работу. Насколько правильно выполняется код и насколько этот код устойчив к ошибочным данным? «Все хорошо, все работает», - Вы слышите слова программиста. Как руководителю Вам лучше верить словам или видеть подтвержденные факты ?
И когда Вы даете задание на изменение/расширение функционала, почему не с первого раза все заработало безупречно? Почему возникают ошибки после слов «все хорошо, все работает»?
Или Ваша компания придерживается правила: «Сделаем релиз - отдадим заказчику. Ошибки будем исправлять потом»?
Если Вы разрабатываете CRM систему, то возможно такой подход будет работать более-менее безболезненно.
Если Вы разрабатываете бухгалтерский\складской учет, то цена вашей ошибки будет иметь более существенное финансовое выражение.
Но если вы разрабатываете системы управления промышленным или медицинским оборудованием, то такой подход неприемлем. Цена ошибки - может быть жизнь человека!
К сожалению, многие отделы разработки работают по правилу: «Ошибки будем исправлять потом», даже при разработке ПО по управлению промышленным оборудованием. И если есть в таких отделах тесты, то в большей части только на бумаге. Потому что программист говорит: «Нет времени», «Время наложения тестов больше или равно времени разработки».
На данный момент TestMeCode - очень быстрая система наложения тестов на код. Проведите тайминг. Сравните, сколько программист будет писать класс, а сколько времени понадобится наложить тест на класс с помощью TestMeCode. Вы будете приятно удивлены.