«Я работаю программистом очень давно. Я писал программы на языке BCPL на компьютерах PDP-11, когда не было никаких Copilot-ов (прим.: BCPL — низкоуровневый предок С). В 1980х не было Интернета, я не мог зайти на StackOverflow. Не было ни юнит-тестов, не было CI-конвейеров, автоматически перехватывающих ошибки, и никто не проводил «баг-баши«.
После долгих лет такой работы мне захотелось перемен, и я решил уйти в тестирование. Я купил книгу, которая взорвала мой мозг — я нашел там вещи, о которых мы даже не догадывались (прим.: известная в то время книга Сэма Канера “Основы тестирования программного обеспечения”.)
Я хотел опробовать кое-что из прочитанного у Канера, но встретил сопротивление со стороны руководства, которое считало, что Agile — это всего лишь быстрый просмотр программы перед отправкой, потому что «клиенты лучше нас находят баги».
Я много раз публиковал эту цитату и иногда получал в ответ: «Ну да, это правда».
Дело в том, что клиенты всегда будут использовать ваши программы так, как и представить себе невозможно. Когда появилась электронная почта, разве кто-то думал о спаме? Думали ли в Samsung или Porsche о том, что на их стиральных машинах и автомобилях можно будет играть в Doom?
Если тестировщики достаточно добросовестны, то клиенты не найдут баги, потому что баги будут обнаружены и исправлены во время тестирования. Напомнило «ошибку выжившего», то есть историю о бомбардировщиках во Второй мировой войне. После каждой миссии повреждения каждого бомбардировщика кропотливо проверялись и фиксировались. Аналитики просматривали эти данные в поисках самых уязвимых мест в самолете. В полученных данных прослеживалась четкая закономерность: большинство повреждений приходилось на крылья и корпус. Поначалу казалось логичным укреплять в первую очередь эти места. Однако более глубокий анализ показал, что пробоины в возвращающихся самолетах представляли собой места, где бомбардировщик мог получить много повреждений и при этом продолжать полет и благополучно вернуться на базу. А более серьезные повреждения (например в топливные баки или мотор) приводили к тому, что самолет сбивали, и его повреждения были недоступны для анализа.
Какое отношение это имеет к программированию и багам?
Если во время тестирования вы обнаружили баг на проде, о котором не сообщили клиенты, это может означать, что:
- Клиенты просто не используют эту часть программы. Возможно, стоит более внимательно посмотреть логи по этой части, и проверить, как она используется. Если не используется, то почему?
- Ваш мониторинг не смог обнаружить баг — проверьте логи и совершенствуйте мониторинг.
- Несовершенство методов регистрации багов клиентами. Есть ли у клиента легкий способ сообщить о проблеме? Если есть, насколько вероятно, что клиент действительно воспользуется им?
Если это новый баг, это указывает на то, что в ваших процессах тестирования есть недостатки:
- Продакшен-окружение не вполне соответствует тестовому окружению.
- Пользователи используют программу не так, как вы её тестируете. Рандомизируйте ваше тестирование.
- Пользователи используют другие модели телефонов и/или версии операционных систем, а не те, которыми пользовались вы при тестировании.
Багов на проде это неприятно, но используйте их как возможность для обучения. Чтобы никто не мог сказать, что клиенты находят баги лучше вас. Это хороший майндсет.»
