Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Причины охотиться на баг

Когда баг возникает, это страшно

Возможно, вы тестируете систему, где все по большей части хорошо работает. Но если возникает баг, система падает, или теряются данные, или пользователь не может оформить заказ. Это серьезная проблема. Даже если баг воспроизводится в 1% случаев, важно разобраться, что происходит, потому что в результате вы можете потерять пользователей.

Проблема плавающая, но встречается часто

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

Проблема указывает на важные неполадки в производительности

Возможно, ваше ПО отлично работает при одном-двух тестовых пользователях в тестовом окружении, но на проде вы начинаете наблюдать странности. Не отмахивайтесь от этого словами "У меня все работает"! Этот баг может означать, что приложение испытывает проблемы под нагрузкой. Возможно, виновата утечка памяти, которая усугубляется в зависимости от длительности использования, или запросы к серверу занимают слишком много времени, и проблема ухудшается при большом количестве запросов, блокируя базу данных. Вне зависимости от причины, важно выявить ее и исправить до того, как на нее наткнутся пользователи.

Причины отложить охоту на потом

Вы тестируете не первую неделю, а с проблемой столкнулись лишь однажды

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

Вы почти уверены, что уже знаете причину

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

У вас поджимает время, а проблема, с вашей точки зрения, не рискованная

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

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

Пропадали ли у вас носки?

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

Обсудить в форуме