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

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

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

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

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

• Разработчик имеет, что называется, «замыленный глаз» и проверяет только те функции, которые должны работать так, как он изначально задумал, и те сценарии, которые реализовал. То есть не уделяет должное внимание всем пользовательским сценариям. Субъективное отношение к проекту и желание быстрее закончить создают соблазн закрыть глаза на многие нюансы.
• Менеджер в силу своей нагрузки поверхностно смотрит, всё ли работает, не проверяя каждый модуль по-отдельности. Это интуитивное тестирование, которое далеко от профессионального. Он не владеет экспертизой: может обнаружить очевидные ошибки, но многие нюансы упускаются из вида.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фреймворк для тестирования – TestNG/JUnit.
• Язык программирования - Java, Python.
• Сборщик проекта – Maven/Gradle.
• Библиотека для ui-тестов используется библиотеку - Selenide, PyTest.
• Для back-тестов используется библиотека RestAssured.
• Формирование отчётов через Allure.
• Jmeter – инструмент для организации нагрузочного тестирования.

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

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

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

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

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

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