Вашему проекту тестировщик не нужен? О важности тестирования

Какая профессия в IT связана с большим количеством мифов и стереотипов? Вероятно, профессия тестировщика! Очень многие до сих пор задаются вопросом, а чем он занимается и можно ли обойтись на проекте без него? Забегая далеко вперед, ответим сразу: “Нет, нельзя!” И в этой статье расскажем почему, проследим его путь на проекте и развеем самые популярные мифы про эту профессию. Что ж, приступаем!

Стереотип № 1: Самый главный стереотип связан с мнением, что основная работа тестировщика — это охотиться на дефекты сайта или приложения. А после с возгласом “Я сломал!” радостно бежать к разработчику и показывать свою “добычу” в виде технического бага.

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

Из этих двух стереотипов закономерно рождается вопрос: “А зачем все-таки нужны тестировщики и нужны ли они вообще?”

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

И тут возникает еще один вопрос: “Разве не могут программисты самостоятельно искать ошибки в ПО без привлечения тестировщика?”

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

Этапы работы тестировщика на проекте

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

1. Уточнение и анализ требований к программному продукту.

2. Составление плана тестирования.

3. Написание тестовой документации.

4. Тестирование продукта с использованием технических средств.

5. Проверка результатов.

1. Уточнение требований к программному продукту

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

Приведем пример из нашей практики: по задумке заказчика на странице регистрации должны располагаться поля “e-mail” и “пароль”. Задача тестировщика в этом случае уточнить:

• какие электронные почты допускаются;

• какой длины должен быть пароль; 

• какие символы/цифры, строчные/заглавные буквы обязательно будут присутствовать; 

• на какую страницу должен быть переход после успешной регистрации; 

• какие ошибки и как должны показываться при валидации почты/пароля и так далее.

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

2. Составление плана тестирования

Вместе с этим тестировщик продумывает план тестирования. Все держать в голове невозможно, поэтому инженер создает документ, где описывает:

• проверки, которые планируются;

• тестовые данные, которые будут использоваться (например, фейковые аккаунты пользователей); 

• как и какими инструментами необходимо провести нагрузочное тестирование, тестирование безопасности; 

• что нам потребуется от команды разработки, чтобы провести тесты.

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

3. Написание тестовой документации 

На основе составленного плана тестирования подготавливается документация. Она бывает разная, есть несколько видов документов, которые создаются в процессе тестирования продукта. Самый знаменитый — “баг-репорт”. Он необходим, чтобы зафиксировать дефект и пошагово описать его воспроизведение. Чем лучше и точнее описан баг, тем быстрее разработчик его устранит. Тест-кейсы полезны не только всем членам команды разработки, но и непосредственно заказчику. В них пошагово описывается, как работает тот или иной функционал, вплоть до сценариев, как должна отработать валидация  —процесс проверки того, соответствует ли конечный продукт изначальным требованиям. 

4. Тестирование продукта с использованием технических средств

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

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

5. Проверка результатов

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

Чем грозит отказ от тестирования ПО?

Вопрос объемный и сложный. Упростим задачу и покажем на конкретном примере: в нашу компанию пришел запрос на аутсорс — интернет-магазин, который ранее тестировался только службой поддержки заказчика. С первого взгляда все работало нормально: бизнес-логика в порядке, дизайны пиксель в пиксель. Но сервер приходилось часто перезагружать, приложение притормаживало. Команде была поставлена задача выявить и локализовать проблему. Пришлось протестировать все приложение. И что же мы увидели?

1) Помимо утечки памяти тестировщики поняли, что если вставить номер заказа в url (адрес сайта) можно просматривать чеки любого пользователя, а не только своего аккаунта.

2) В ответе от сервера, кроме необходимых данных (имя, e-mail, рейтинг и так далее), подгружался еще и баланс пользователя.

3) При входе в приложение от сервера приходил пароль пользователя (хоть и зашифрованный, но и это очень и очень плохо).

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

Чтобы не допускать подобных ситуаций, нужно четко понять, что приложение или сайт — это не только красивый визуал. Это сложные механизмы со своими “законами” и внутренними системами. И у приложения, и у сайта есть скрытая часть как в автомобиле, которая работает “под капотом”. И как автомобилю нужен не только водитель, но и механик, так и IT-продукту нужен тестировщик, который вовремя обнаружит поломку и предотвратит негативные последствия.