Дорогая ошибка. Пример из России.
Когда нас просят привести примеры программных ошибок, приведших к серьезным потерям, мы приводим примеры из зарубежного опыта. А хотелось бы из нашей практики.
Фирма «Арктикгруп» [1], крупнейший продавец сотовых телефонов, цифровых фотоаппаратов, КПК и всяческих гаджетов, а также холодильников, телевизоров и пылесосов[1] вела сложный складской учет. Приспособить существующие на рынке системы под себя, не представлялось возможным, и была написана собственная программа учета [2].
В какой то момент, в душу управляющего складом заползло сомнение, что количество товара на складе не соответствует данным складской системы. Что именно натолкнуло его на эту мысль, стеллаж ли забитый коробками, но числившийся по базе пустым, или случайная находка товара, которого не было в базе, или просто избыток свободного времени, сейчас уже неважно.
Сомненья дьявол ловок и хитер [3]. Но как проверить подозрение? Тотальная ревизия отпадает. Остановить работу склада на несколько дней нельзя. Проверить товар на складе размером с ангар за одну ночь нереально. Прошерстить большой объем при постоянных изменениях – задача не для слабонервных. Управляющий складом был по настоящему талантлив. Метод проверки, предложенный им, был неординарен и красив. Он посчитал и сравнил суммарные объемы товара по БД и наличествующие на складе. Точности метода хватило. Было обнаружено превышение остатков на складе на несколько процентов по сравнению с информацией в БД.
Ошибка обнаружена, но не локализована.
• Ошибка может быть вызвана организационными промахами. Например, неоприходывание товара, поступившего на склад во внеурочное время.
• Может быть вызвана некорректными начальными данными. Например, при вводе системы в строй забыли ввести часть позиций.
• Может быть в программном обеспечении.
Первые два варианта были проверены и отброшены. Осталась информационная система. Тут надо сказать, что система эксплуатировалась несколько лет. А процент выявленных нарушений явно указывал, что ошибка существует несколько лет. Возможно, с начала эксплуатации программы.
Еще несколько дней были потрачены на проверку системы учета. Действительно ошибка была в программе. Она возникала при редком варианте использования программы уровня неба [4]. Дальше все просто и неинтересно.
Я же хочу подчеркнуть несколько моментов:
• От момента обнаружения ошибки до занесения ее в багтрекер прошло много дней.
• Ошибка, приносившая ежегодно очень серьезные потери (более сотни тысяч долларов) долгое время не была обнаружена.
• Ошибка была обнаружена конечным пользователем не при прогоне программы, а достаточно экзотическим методом.
• Ошибка была достаточно сложной, чтобы отдел разработки не смог обнаружить ее в течение нескольких лет. Для обнаружения данной ошибки необходимо не только быть профессионалом в тестировании, но обладать серьезными познаниями в смежных областях, таких, как проектирование БД, особенности различных архитектур и т.д.
———————————————————————
[1] Случай реальный, но все названия изменены.
[2] На крупных производствах с их спецификой проще написать свою систему, нежели использовать коробочный продукт. Так, например, и МТС и Вымпелком использовали системы созданные под себя.
[3] © Евгений Клячкин
[4] Определение этого термина можно найти в великолепной книге Алистера Коберна «Современные методы описания функциональных требований к системам»