Уроки, полученные на горьком опыте в мире технологий 90-х.

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

Внезапно я стал единственным ИТ-ресурсом компании, взяв на себя различные задачи от обслуживания и ИТ-поддержки до разработки и различных других обязанностей, связанных с ИТ. Это было, когда один разработчик мог понять весь спектр программного решения; программное обеспечение было довольно простым по сравнению даже с самыми простыми решениями, которые у нас есть сегодня.

Учитывая относительно небольшой масштаб приложений в нашем портфолио, мы могли оперативно ответить на любые вопросы и решить любые проблемы. Однако времени всегда было мало; с оплатой счетов, выполнением банковских поручений (слава Богу, появление онлайн-банкинга!), звонками в службу поддержки от клиентов, незнакомых с работой компьютера, и личными обновлениями, которые приходилось выполнять из-за ограниченного доступа в Интернет. Мы были на пределе, и разработка программного обеспечения превратилась в ненадежный баланс.

Эти условия созрели для катастрофы, и вскоре после начала моей работы я на собственном опыте убедился в недостатках отказа от проведения тестирования программного обеспечения.

Эпоха, когда один разработчик мог понять все программное решение, давно прошла. В начале 90-х приложений было намного меньше, а в 80-х — еще меньше. Для сравнения: Lotus 123, первое коммерческое приложение для работы с электронными таблицами, было создано и поддерживается одним человеком. Учитывая небольшой масштаб приложений, среди нас, разработчиков, было сильное убеждение, что мы можем спроектировать, написать код и протестировать любой мыслимый сценарий без формального тестирования. Раньше мы делали специальные модификации программного обеспечения и немедленно распространяли их среди клиентов.

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

Так было до тех пор, пока не случилась катастрофа.

В те времена стандартным методом хранения данных на случай сбоя приложения (что случалось часто) было сохранение временных файлов на жестком диске с использованием рудиментарных приемов. Наше программное обеспечение будет сканировать текущую папку на наличие этих временных файлов, чтобы восстановить любую незавершенную работу. Однажды мы получили отчеты от нескольких клиентов о том, что временные файлы удаляются по ошибке. Каждый раз, когда они заполняли форму, поля заполнялись старыми данными, что мешало их работе. Им пришлось удалить все поля формы, чтобы начать заново вручную. Мы назвали это инцидентом P2:

«Приоритет 2 (P2) — затронута основная часть операций клиента. Некоторые аспекты бизнеса могут продолжаться, но это серьезная проблема».

Такие инциденты требовали быстрого разрешения, поскольку они нарушали работу наших клиентов.
, вызывая задержки и высокий риск невыполнения работы в течение рабочего дня. Эта задержка может повлиять на импортно-экспортные операции их клиентов. Срочность была очевидна.

Достаточно ли я подчеркнул риски невыполнения тестирования программного обеспечения? Если нет, то я продолжу.

В ответ мы углубились в код приложения, определили проблему, и потребовалась всего одна строка кода, чтобы «решить» проблему. Мы скомпилировали приложение, сделали несколько копий для отправки нашим клиентам, а также лично доставили и переустановили программное обеспечение для каждого затронутого клиента вручную. Мы пропустили тестирование; это была всего лишь одна строка кода.

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

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

Вы можете подумать, что мы могли восстановить файлы, верно? Ну, это было не так просто. Во-первых, вам нужно было специальное программное обеспечение для восстановления файлов; таких концепций, как корзина Windows, не существовало. Во-вторых, и это наиболее важно, из-за чувствительности данных, с которыми мы имели дело, мы разработали наши приложения для обеспечения эффективного и безвозвратного стирания данных.

Всего одна строка кода без тестирования.

Осадок был для нас не из приятных. Нам пришлось вернуться, исправить, протестировать (да, мы наконец усвоили урок), скомпилировать и предоставить новую версию всем нашим клиентам. Более того, нам приходилось проводить целую неделю по четыре-шесть часов в день в офисе клиента, вручную внося каждую запись из бухгалтерии. Стоимость одной непроверенной строчки кода можно свести к десяткам потерянных часов с нашей стороны на повторный ввод данных, невозможности клиента пользоваться системой учета в течение недели, полагаясь во всем исключительно на бумажные книги, и дополнительным часам нам пришлось потратиться на исправление приложения и его установку в офисе каждого клиента. Не говоря уже о репутационном ущербе нашей фирмы.

Тестирование программного обеспечения — это не просто вариант; она составляет основу обеспечения качества. Ошибки могут нанести существенный ущерб, последствия которого выходят далеко за рамки непосредственной проблемы.

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

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