Какая профессия в IT связана с большим количеством мифов и стереотипов? Вероятно, профессия тестировщика! Очень многие до сих пор задаются вопросом, а чем он занимается и можно ли обойтись на проекте без него? Забегая далеко вперед, ответим сразу: “Нет, нельзя!” И в этой статье расскажем почему, проследим его путь на проекте и развеем самые популярные мифы про эту профессию. Что ж, приступаем!
Стереотип № 1: Самый главный стереотип связан с мнением, что основная работа тестировщика — это охотиться на дефекты сайта или приложения. А после с возгласом “Я сломал!” радостно бежать к разработчику и показывать свою “добычу” в виде технического бага.
Стереотип № 2: Одновременно с этим у людей есть иллюзия, что разработчики ПО должны писать код сразу безошибочно, продумывая все до мельчайших деталей. И попутно организовывать работу внутри команды.
Из этих двух стереотипов закономерно рождается вопрос: “А зачем все-таки нужны тестировщики и нужны ли они вообще?”
Отвечаем: не просто нужны, а необходимы! Кто проверит все мыслимые и немыслимые сценарии поведения пользователя при работе с приложением или сайтом, выявит потенциальные баги, еще на этапе ознакомления с требованиями отловит дефекты на основании своего опыта и умений, чтобы разработчик получил максимально подробную задачу, а продукт быстрее вышел в релиз? Кто, если не тестировщик? От его зоркого взгляда не ускользнет ни одна ошибка, а если и постарается, он все равно ее найдет. Тестировщик выступает своеобразной подстраховкой разработчика, гарантом качества его работы. Каким бы профессионалом не был разработчик, создаваемый им продукт потенциально может иметь неучтенные баги, которые с первого взгляда сложно обнаружить.
И тут возникает еще один вопрос: “Разве не могут программисты самостоятельно искать ошибки в ПО без привлечения тестировщика?”
Полагаем, что программист в силах изучить базу для тестирования и даже проводить поверхностные проверки. Но искать собственные ошибки всегда сложнее, сразу вспоминается фраза “замылился глаз”. Да и стоимость часа работы программиста в разы дороже, чем у тестировщика. В конце концов, тестирование продукта разработчиком не даст такого результата, как проверка специалистом, который является асом именно в обеспечении качества ПО.
Этапы работы тестировщика на проекте
Копнем глубже и рассмотрим полный цикл взаимодействия тестировщика с проектом, чтобы лучше уяснить суть и принципы работы. Разделим процесс обеспечения качества программного продукта на пять условных фаз:
Уточнение и анализ требований к программному продукту.
Составление плана тестирования.
- Написание тестовой документации.
- Тестирование продукта с использованием технических средств.
- Проверка результатов.
1. Уточнение требований к программному продукту
Тестирование готовой функции в приложении — всего лишь одна из задач в работе тестировщика или QA-инженера. Движение запускается ровно с того момента, как только поступают первые требования к ПО. На этом этапе нужно максимально предусмотреть все проблемные моменты, чтобы меньше переделывать потом.
Приведем пример из нашей практики: по задумке заказчика на странице регистрации должны располагаться поля “e-mail” и “пароль”. Задача тестировщика в этом случае уточнить:
- какие электронные почты допускаются;
- какой длины должен быть пароль;
- какие символы/цифры, строчные/заглавные буквы обязательно будут присутствовать;
- на какую страницу должен быть переход после успешной регистрации;
- какие ошибки и как должны показываться при валидации почты/пароля и так далее.
Чем больше информации будет получено, тем больше нештатных случаев удастся предусмотреть. Разработчик получит более полные требования и качественно выполнит свою работу, так как значительная часть деталей уже будет описана в задаче.
2. Составление плана тестирования
Вместе с этим тестировщик продумывает план тестирования. Все держать в голове невозможно, поэтому инженер создает документ, где описывает:
- проверки, которые планируются;
- тестовые данные, которые будут использоваться (например, фейковые аккаунты пользователей);
- как и какими инструментами необходимо провести нагрузочное тестирование, тестирование безопасности;
- что нам потребуется от команды разработки, чтобы провести тесты.
Совместно с разработчиками дополнительно пишется матрица трассировки — документ в виде таблицы, где наглядно показаны зависимости одной функции в логике приложения от другой.
3. Написание тестовой документации
На основе составленного плана тестирования подготавливается документация. Она бывает разная, есть несколько видов документов, которые создаются в процессе тестирования продукта. Самый знаменитый — “баг-репорт”. Он необходим, чтобы зафиксировать дефект и пошагово описать его воспроизведение. Чем лучше и точнее описан баг, тем быстрее разработчик его устранит. Тест-кейсы полезны не только всем членам команды разработки, но и непосредственно заказчику. В них пошагово описывается, как работает тот или иной функционал, вплоть до сценариев, как должна отработать валидация —процесс проверки того, соответствует ли конечный продукт изначальным требованиям.
4. Тестирование продукта с использованием технических средств
По окончании теоретической части тестировщик приступает к практике. С помощью собственных рук и машинных механизмов проводится тестирование продукта на всех этапах его создания.
Чтобы разобраться подробнее, когда и какой тип использовать (мануальное тестирование или автотесты) — мы приберегли для вас статью. В ней мы выявили разницу между этими двумя видами тестирования, а также рассказали подробнее о самом процессе нахождения багов в приложении или на сайте.
Кроме вида, инженер также определяется и с методологией работы, чтобы не проводить избыточное тестирование всего подряд.
5. Проверка результатов
На завершающем этапе тестировщик проверяет соответствие плана и результатов проведенного тестирования. А также дополняет тестовую документацию новой информацией, которая была получена в процессе работы и пригодится в дальнейшем разработчику.
Чем грозит отказ от тестирования ПО?
Вопрос объемный и сложный. Упростим задачу и покажем на конкретном примере: в нашу компанию пришел запрос на аутсорс — интернет-магазин, который ранее тестировался только службой поддержки заказчика. С первого взгляда все работало нормально: бизнес-логика в порядке, дизайны пиксель в пиксель. Но сервер приходилось часто перезагружать, приложение притормаживало. Команде была поставлена задача выявить и локализовать проблему. Пришлось протестировать все приложение. И что же мы увидели?
1) Помимо утечки памяти тестировщики поняли, что если вставить номер заказа в url (адрес сайта) можно просматривать чеки любого пользователя, а не только своего аккаунта.
2) В ответе от сервера, кроме необходимых данных (имя, e-mail, рейтинг и так далее), подгружался еще и баланс пользователя.
3) При входе в приложение от сервера приходил пароль пользователя (хоть и зашифрованный, но и это очень и очень плохо).
Чем все это грозит? Личные данные пользователей практически открыты для злоумышленника и поданы на блюдечке для дальнейших мошеннических операций. Хорошо, что мы обнаружили эти баги до того, как кто-то успел пострадать, а заказчик получил судебный иск от пользователей. В данном случае отказ от тестирования грозил как потерей бюджета, так и потерей репутации.
Чтобы не допускать подобных ситуаций, нужно четко понять, что приложение или сайт — это не только красивый визуал. Это сложные механизмы со своими “законами” и внутренними системами. И у приложения, и у сайта есть скрытая часть как в автомобиле, которая работает “под капотом”. И как автомобилю нужен не только водитель, но и механик, так и IT-продукту нужен тестировщик, который вовремя обнаружит поломку и предотвратит негативные последствия.
Новости из мира IT-технологий, о трендах индустрии, бизнес-сервисах и не только — в ТГ-канале или на сайте Fusion Tech.
Читайте также:
Метрики в тестировании — пустая трата времени или объективный показатель качества и скорости разработки? Когда применяются и что дают цифровому продукту? Вместе с начальником QA-отдела Fusion Tech постараемся разобраться в этих вопросах и выяснить, какие метрики и как влияют на процесс разработки.