7 подходов к тестированию

Всем привет! Меня зовут Игорь Ниточкин, я IT-директор с опытом работы в сфере более 10 лет. На данный момент я руковожу агентством тестирования и хочу поделиться своими наблюдениями.
Мы разберем 7 основных подходов к тестированию и расскажем, как сделать его полноценным и качественным. Своеобразная эволюция из 7 ступеней. Поехали!

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

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

Конечно, это лучше, чем полное отсутствие тестирования, но ненамного.

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

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

Основные минусы метода:

Итог: на первый взгляд логичный подход к тестированию изначально не учитывает обнаружение глобальных ошибок.

Этот подход позволяет находить баги «по мере поступления» при гибкой методологии разработки. Тестировщик интегрируется в команду разработчиков. Каждая функция последовательно и многократно тестируется.В этом случае тестирование ещё нельзя назвать подробным и структурированным, оно всё ещё носит более интуитивный характер.Главный минус: подход бессистемный.

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

Именно на этой стадии появляется осознанное профессиональное тестирование. То есть это не рандомная проверка, основанная на интуиции, а систематизированный процесс, закрепленный необходимой документацией.
Осознанно уделяется внимание анализу всех требований. Вся работа разбивается на тест-блоки.

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

Очевидных недочётов такого подхода нет. При правильном подходе к тестированию это уже должный уровень.Но можно и лучше:

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

Когда компания растёт, необходимо хранить и систематизировать свои наработки. Внедряются системы хранения тест-кейсов и инструменты тестированияНапример, мы в Qualitica используем TestRail. Это инструмент, который используется для общего управления тестированием, хранения всех требований и тест-кейсов на проекте.

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

Разработчики и тестировщики пишут автотесты: unit-тесты и ui-тесты. То есть все регулярные проверки автоматизируются. Исключается человеческий фактор: забыл или было лень «в сотый раз» проверять одно и тоже.

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

Со временем в мы выделили для себя следующие:

Автотесты значительно сокращают временные расходы и повышают качество продукта.

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

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

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

К нам в Qualitica обращаются клиенты с разными проектами. Это может быть простой сайт, интернет-магазин или сложный портал с личными кабинетами и множеством модулей. У нас в свою очередь есть система управления тестированием, узкие специалисты, иерархия и, конечно, автоматизация. Мы умеем и готовы помочь повысить качество ваших услуг и программных продуктов.