Существует устойчивое мнение в кругу тестировщиков, что если дефект сложно воспроизвести, не нужно тратить на него уйму времени, а правильней всего идти дальше и проверять что-то другое.

А есть группа QA-специалистов, которые тратят массу времени на поиск причин возникновения подобного бага, попросту оставляя процесс тестирования на паузе. Но есть ли золотая середина у всего этого?

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

Причины «за»

1. Когда возникает дефект – это плохо

Может быть, вы как тестировщик проверяете ПО, где все качественно настроено и функционирует корректно. Но если возникает дефект, система попросту ламается, либо же пропадает важная часть информации. Подобные вещи не допустимы ни в каком проявлении. Даже если ошибка воспроизводится исключительно при 2% тестовых случаев, крайне важно понять, что именно происходит, так как одна небольшая ошибка может стать катализатором отказа всей системы.

2. Баг плавающий, но встречается крайне часто

Допустим, у нас есть программное обеспечение, которым будут пользоваться исключительно в систематическом порядке (нерегулярно). При авторизации, продукт в 50% случаях принимает вводимые данные, а при остальных 50% – нет.

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

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

3. Баг связан с важными техническими неполадками и проблемами

Может быть так, что тестируемое ПО функционирует хорошо при нескольких тестовых пользователях, но когда оно становится общедоступным, начинаются массовые технические сбои. Не нужно пропускать подобные вещи со словами «у меня же все работало».

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

Но вне зависимости от реальной причины, крайне важно найти такой баг и отредактировать до того момента, пока с продуктом не начнут взаимодействовать реальные пользователи.

Причина «против»

1. Тесты проходят уже давно, но баг был воспроизведен лишь однажды

Программное обеспечение – вещь нестабильная и уж точно неидеальная в своем функционировании. В нем могут рождаться самые непредсказуемые странности и неурядицы технического характера (перепады мощностей, проблемы с интернет-соединением и прочее).

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

2. Времени мало, но вы уверены, что найденный баг – нерискованный

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

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

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

3. А был ли баг? (вместо вывода)

Всегда, когда QA сталкивается с очень странным дефектом, нужно спрашивать у самого себя – может ли он подождать или же бороться с ним нужно прямо сейчас? Масштабы бага, частота его проявления и вероятность его наличия в реальном окружении помогут специалисту по тестированию ПО принять наиболее важное и правильное решение прямо сейчас.