Как мы ищем баги

Сегодня расскажем о том, как мы ищем баги.

Весь процесс тестирования можно условно разделить на три этапа:

• вникнуть в задачу,
• подготовить окружение,
• отловить баги.

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

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

Подготовка окружения включает в себя:

• заливку обновлений на тестовый сервер,
• настройку системы и ее окружения,
• создание набора данных для тестирования.

Заливка обновлений – чисто технический процесс, и благодаря использованию системы контроля версий, выполняется одной командой.

Настройка системы и ее окружения, как правило, необходима при тестировании задач, связанных с интеграцией. Это, например, задачи по интеграции с телефонией, 1С, почтовыми серверам, внутренними системами клиента. Зачастую непросто воспроизвести точно такие же условия, как на боевом сервере клиента.

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

Этап отлавливания багов условно можно разделить на стадии:

• визуальная проверка,
• проверка функционала,
• проверка логики.

На стадии визуальной проверки проводится поиск опечаток, сверка наличия всех перечисленных в задании полей и их типов. Оценивается удобство расположения полей, их общее восприятие.

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

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

К сожалению, даже после самого придирчивого тестирования невозможно утверждать, что система на 100% без багов и полностью соответствуют ожиданиям клиента. Когда системой начнет пользоваться человек, для которого она была сделана, всегда могут найтись неточности и несоответствия, которые могли закрасться даже на этапе согласования ТЗ.