Профессия тестировщик в сфере ИТ одна из самых специфичных и окутана многочисленными мифами. Немногие знают, чем занимается этот специалист, и в каких проектах без него нереально обойтись.
Первый из мифов гласит, что главная задача тестировщика заключается в выявлении дефектов на сайтах и в приложениях. Если что-то поломалось, нужно бежать к нему и демонстрировать технический баг.
Другой стереотип заключается в том, что создатели программных обеспечений на этапе написания кодов никогда не допускают ошибок, досконально продумывают все детали, попутно организовывая работу в команде.
Профессия тестировщик чрезвычайно востребована, спрос на таких специалистов продолжает увеличиваться. Они отвечают за проверку различных сценариев поведения пользователей в ходе использования приложения либо ресурса. В их обязанности входит:
- определение потенциальных багов еще на стадии знакомства с требованиями;
- выявление скрытых дефектов за счет своего опыта и знаний;
- ускорение релиза проекта.
Тестировщики ищут ошибки, страхуя разработчиков, повышая качество их работы. Даже самые опытные разработчики ошибаются, допущенные им недочеты иногда трудно выявить.
Программисты, конечно, могут освоить тестирование и выполнять проверки, но только поверхностно. Поиск собственных ошибок задача трудная, ведь глаз замыливается. К тому же, час труда программиста оплачивается гораздо выше, чем тестировщика. Компаниям выгодно иметь в штате двух специалистов. Тестировщик повышает качество работы ПО.
Как работает тестировщик?
Тестировщик погружается в проект для лучшего понимания принципов его работы. Сначала он уточняет и анализирует требования к определенному программному продукту. Затем составляет план проверки, готовит тестовые документы. Тестирует продукт при помощи технических приспособлений, проверяет результаты. Остановимся на каждом из этих этапов подробнее.
Уточнение требований к программному продукту
Тестировщик не просто проверяет готовые опции в ПО. Это только одна из многочисленных задач, которые перед ним ставятся. Он начинает работать сразу после поступления первых требований к программному продукту. Прогнозирует возможные проблемы, чтобы избежать переделок в дальнейшем.
Допустим клиент хочет, чтобы на странице, предназначенной для регистрации пользователей, было поле для логина и пароля. Тестировщику необходимо уточнить, какие e-mail допустимы, узнать длину пароля, особенности применяемых при его создании символов (буквы будут только строчными или обязательно нужны заглавные, нужны ли цифры).
Далее нужно определиться со страницей перехода после окончания регистрации. Ошибками, которые будут демонстрироваться после введения пароля с логином.
Чем больше сведений удастся получить, чем больше внештатных ситуаций получится спрогнозировать. Разработчику будут предоставлены более четкие требования, а значит, качество его работы повысится, так как большая часть деталей будет прописана в тз.
Формирование плана проверки
Одновременно с этим формируется план проверки. Все запомнить нереально, необходимо описать тесты, которые предстоит выполнить. В план вносят:
- проверочные сведения, которые будут применяться (к примеру, поддельные аккаунты);
- перечень инструментов для проведения нагрузочного тестирования с акцентом на безопасности.
Обязательно прописывается матрица трассировки – специальный документ в формате таблицы с наглядной демонстрацией зависимости между опциями. Тестировщику нужно указать, какие данные должны предоставить разработчики для выполнения проверок.
Формирование тестовых документов
План проверок служит базой для подготовки тестовой документации. Насчитывается несколько разновидностей таких документов. Наибольшей популярностью пользуется «баг-репорт», его используют для фиксации проблем и пошагового описания работы функционала, включая сценарии работы валидации. Речь идет о проверке соответствия конечного продукта исходным требованиям.
Тестирование продукта с применением технических приспособлений
За теорией следует практика. Тестировщик вручную и при помощи машинных механизмов проверяет продукт на всех стадиях его формирования.
Оценка результатов
На финальном этапе тестировщик сравнивает план с результатами, полученными по итогам проверки. Вносит дополнения в тестовые документы, которыми потом воспользуется разработчик.
Чем чреват отказ от проверки программного продукта?
Отказ от полноценной проверки программного продукта чреват негативными последствиями в виде испорченной репутации, финансовых потерь. Даже если на первый взгляд все работает нормально, могут быть скрытые проблемы. Утечка памяти, к примеру, открывает возможность просмотра чеков других покупателей.
Бывают ситуации, когда помимо основных данных подгружается еще и баланс. К негативным последствиям можно отнести получение злоумышленниками паролей пользователей, путь и в зашифрованным виде – это все равно недопустимо.
Мошенники в результате некорректной работы ПО могут получить доступ к личным данным пользователей, им даже не придется ничего взламывать. Тестировщик выявляет подобные баги до того, как кто-то понесет убытки, что повлечет за собой привлечение к суду заказчика – владельца сайта или приложения.
Во избежание негативных последствий нужно четко понимать, что сайт – это не просто презентабельный девайс. Речь идет о сложном механизме, который функционирует по своим правилам. У него имеется скрытая часть. Ему, как и машине, помимо водителя требуется еще и механик, роль которого играет тестировщик, своевременно выявляющий неисправности, предотвращающий отрицательные последствия.
