Программирование без ошибок

В наше время все приходится делать быстро. И проекты по внедрению систем учета также должны быть быстрыми. Заказчик не готов растягивать сроки на несколько месяцев. Результат ему нужен здесь и сейчас.

Как правило, подготовительный этап при внедрении программного продукта осуществляется за несколько недель (постановка задачи, доработка функционала, обучение пользователей, ввод остатков). Затем сырой продукт передается клиенту в рабочую эксплуатацию. И уже во время эксплуатации доводится до ума.

При таком подходе во время рабочей эксплуатации с большой долей вероятности пользователи будут натыкаться на различного рода ошибки. Очень плохо, если в процессе работы пользователя выскакивает окошко, оповещающее об ошибке, в котором «не понятно че написано» или «абракадабра какая-то». Еще хуже, когда никаких ошибок в работе пользователя не «вываливается», но результат его работы неправильно отражается в учетных данных. Выявляются такие ошибки намного позднее, когда очень срочно нужно подготовить какой-либо отчет для руководителя, а он показывает неправильные данные.

Как победить ошибки в программах?

1. Можно постараться не делать их. Это практически невозможно.
2. Можно своевременно их исправлять. Для этого было бы не плохо своевременно их находить, то есть, качественно тестировать творения программистов.
3. Можно ничего не делать и исправлять ошибки после поступления жалоб от клиентов. Это не наш метод.

Первый вариант практически невозможен, ошибаются все, просто с разной периодичностью и разными последствиями. Последний вариант даже рассматривать не будем. Остается один вариант – тестирование.

Обычно тот, кто ставит задачу программисту, и тестирует продукт. Это может быть ведущий программист, методолог, руководитель проекта, кто угодно, непосредственно связанный с самим проектом и знающий, что именно требуется от разработанного программистом продукта, блока, модуля.

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

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

И, конечно же, никто не отменял тестирование на стороне заказчика. Обычные рядовые пользователи отличаются завидными способностями ставить программы в тупик. Во время тестирования пользователи еще и обучаются работе в программе, что позволяет сэкономить так важное для нас время.

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