В наше время все приходится делать быстро. И проекты по внедрению систем учета также должны быть быстрыми. Заказчик не готов растягивать сроки на несколько месяцев. Результат ему нужен здесь и сейчас.
Как правило, подготовительный этап при внедрении программного продукта осуществляется за несколько недель (постановка задачи, доработка функционала, обучение пользователей, ввод остатков). Затем сырой продукт передается клиенту в рабочую эксплуатацию. И уже во время эксплуатации доводится до ума.
При таком подходе во время рабочей эксплуатации с большой долей вероятности пользователи будут натыкаться на различного рода ошибки. Очень плохо, если в процессе работы пользователя выскакивает окошко, оповещающее об ошибке, в котором «не понятно че написано» или «абракадабра какая-то». Еще хуже, когда никаких ошибок в работе пользователя не «вываливается», но результат его работы неправильно отражается в учетных данных. Выявляются такие ошибки намного позднее, когда очень срочно нужно подготовить какой-либо отчет для руководителя, а он показывает неправильные данные.
Как победить ошибки в программах?
- Можно постараться не делать их. Это практически невозможно.
- Можно своевременно их исправлять. Для этого было бы не плохо своевременно их находить, то есть, качественно тестировать творения программистов.
- Можно ничего не делать и исправлять ошибки после поступления жалоб от клиентов. Это не наш метод.
Первый вариант практически невозможен, ошибаются все, просто с разной периодичностью и разными последствиями. Последний вариант даже рассматривать не будем. Остается один вариант – тестирование.
Обычно тот, кто ставит задачу программисту, и тестирует продукт. Это может быть ведущий программист, методолог, руководитель проекта, кто угодно, непосредственно связанный с самим проектом и знающий, что именно требуется от разработанного программистом продукта, блока, модуля.
Такое тестирование, как правило, выявляет большинство ошибок в логике работы программы, в расчетах и вычислениях. Единственным минусом тестирования является то, что специалистам, вовлеченным в проект, очень сложно смоделировать нештатные ситуации: они знают как должна работать программа, знают как нужно в ней работать и правильно работают. Очень полезно после такого тестирования дать поработать с программой специалисту, не вовлеченному в проект. Взгляд со стороны помогает выявить недостатки и ошибки в работе с программой.
Помимо самого тестирования ведущий программист должен просматривать и программный код. На этом этапе можно выявить нерациональные методы решения той или иной задачи, приводящие к неоправданному замедлению работы или к увеличению объема данных.
И, конечно же, никто не отменял тестирование на стороне заказчика. Обычные рядовые пользователи отличаются завидными способностями ставить программы в тупик. Во время тестирования пользователи еще и обучаются работе в программе, что позволяет сэкономить так важное для нас время.
Ошибок в программах не избежать, но бороться с ними нужно. И лучше это делать на этапе их зарождения, до попадания продукта заказчику. Поэтому нельзя экономить на тестировании, а тем более пренебрегать им.
Комментарии
5Хотя бы методолгия бы была подведена под описанный метод.