7 подходов к тестированию
Всем привет! Меня зовут Игорь Ниточкин, я IT-директор с опытом работы в сфере более 10 лет. На данный момент я руковожу агентством тестирования и хочу поделиться своими наблюдениями.
Мы разберем 7 основных подходов к тестированию и расскажем, как сделать его полноценным и качественным. Своеобразная эволюция из 7 ступеней. Поехали!
Подход 1: Тестированием занимается разработчик или менеджер.
Эту ступень сложно выделить как отдельный подход, так как, фактически, это отсутствие профессионального тестирования. Вместо профессионала с объективной оценкой проект тестирует сам разработчик или принимающий менеджер.
Часто это бывает по нескольким причинам: отсутствие бюджета, желание сэкономить, невозможность нанять профессионального тестировщика или же просто непонимание важности тестирования.
Конечно, это лучше, чем полное отсутствие тестирования, но ненамного.
- Разработчик имеет, что называется, «замыленный глаз» и проверяет только те функции, которые должны работать так, как он изначально задумал, и те сценарии, которые реализовал. То есть не уделяет должное внимание всем пользовательским сценариям. Субъективное отношение к проекту и желание быстрее закончить создают соблазн закрыть глаза на многие нюансы.
- Менеджер в силу своей нагрузки поверхностно смотрит, всё ли работает, не проверяя каждый модуль по-отдельности. Это интуитивное тестирование, которое далеко от профессионального. Он не владеет экспертизой: может обнаружить очевидные ошибки, но многие нюансы упускаются из вида.
В итоге все баги системы всплывают уже у конечных пользователей, что снижает кредит доверия к компании, отпугивает покупателей, портит репутацию бренда.
Подход 2: Тестировщиков нанимают на стадии завершения.
Типичный метод при каскадной модели разработки программного обеспечения, когда проект делится на этапы.Профессиональный тестировщик, который появляется только на стадии сдачи проекта или каждого этапа - это первая ступень в эволюции тестирования.
Основные минусы метода:
- При тестировании системы в самом конце существенные ошибки на уровне архитектуры будут найдены слишком поздно, придётся переписывать большой кусок кода или переделывать с самого начала. Это, как минимум, невыгодно.
- Это свободное интуитивное тестирование, что в свою очередь влечет за собой игнорирование ряда альтернативных пользовательских сценариев.
- Проект во время разработки претерпевал изменения, изначальная документация уже не соответствует конечному результату, что осложняет разбор баг-репортов.
Итог: на первый взгляд логичный подход к тестированию изначально не учитывает обнаружение глобальных ошибок.
Подход 3: Тестировщики проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи.
Этот подход позволяет находить баги «по мере поступления» при гибкой методологии разработки. Тестировщик интегрируется в команду разработчиков. Каждая функция последовательно и многократно тестируется.В этом случае тестирование ещё нельзя назвать подробным и структурированным, оно всё ещё носит более интуитивный характер.Главный минус: подход бессистемный.
Тестировщику надоедает каждый раз вручную проверять типичные задачи, например, авторизацию на сайте, и спустя время он начинает упускать эти «мелочи» из вида. Альтернативные сценарии также могут быть упущены из вида.
Подход 4: Тестировщики занимаются тест-дизайном.
Именно на этой стадии появляется осознанное профессиональное тестирование. То есть это не рандомная проверка, основанная на интуиции, а систематизированный процесс, закрепленный необходимой документацией.
Осознанно уделяется внимание анализу всех требований. Вся работа разбивается на тест-блоки.
Проектирование и создание тестовых случаев будет проводиться с учетом специфики проекта и требований к нему в соответствии с определёнными ранее критериями качества и целями тестирования. Подготавливается тестовая документация, включающая в себя тест-планы, чек-листы, баг-репорты, регрессы и спецификации требований.
Очевидных недочётов такого подхода нет. При правильном подходе к тестированию это уже должный уровень.Но можно и лучше:
Подход 5: Внедряется система управления тестированием.
Это стадия, на которой уже есть планирование тестирования: чёткое понимание, когда будет проводится регресс, в какой момент проводятся смоки, есть регламенты тестирования.
Когда компания растёт, необходимо хранить и систематизировать свои наработки. Внедряются системы хранения тест-кейсов и инструменты тестированияНапример, мы в Qualitica используем TestRail. Это инструмент, который используется для общего управления тестированием, хранения всех требований и тест-кейсов на проекте.
С помощью этого инструмента формируются отчеты о проведенном тестировании.Улучшение контроля за процессом тестирования даёт новый уровень качества продукта. Система ускоряет ввод в проект новых участников.
Подход 6: Появляется автоматизация тестирования.
Разработчики и тестировщики пишут автотесты: unit-тесты и ui-тесты. То есть все регулярные проверки автоматизируются. Исключается человеческий фактор: забыл или было лень «в сотый раз» проверять одно и тоже.
Для простейших тест-кейсов: авторизации, регистрации, публикации записей и т.д. - пишутся авто-тесты. Подключаются не ручные тестировщики, а автоматизаторы. Простейшие функции, которые, скорее всего, не будут меняться, проверяются автоматически каждый раз при проверке релиза.Существует множество технологий для автоматизации тестирования.
Со временем в мы выделили для себя следующие:
- Фреймворк для тестирования – TestNG/JUnit.
- Язык программирования - Java, Python.
- Сборщик проекта – Maven/Gradle.
- Библиотека для ui-тестов используется библиотеку - Selenide, PyTest.
- Для back-тестов используется библиотека RestAssured.
- Формирование отчётов через Allure.
- Jmeter – инструмент для организации нагрузочного тестирования.
Автотесты значительно сокращают временные расходы и повышают качество продукта.
Подход 7: Усложняется иерархия, появляются новые роли в команде тестирования.
Верхом эволюции тестирования можно назвать появление иерархии и узких специалистов: тест-менеджер, тест-лид, тест-аналитик, тест-дизайнер и так далее. Каждый человек отвечает за свой фронт работы.
- Тест-менеджер владеет всей информацией по продукту, видит «картину в целом», занимается организацией работы, управлением командой тестирования. В его функции входит коммуникация с заказчиком и командой разработки.
- Тест-лид координирует тестирование и распределяет задачи внутри команды.
- Тест-аналитик анализирует требования, готовит документацию.
- Тест-дизайнер трансформирует требования в чек-листы и тест-кейсы.
- Есть тестировщики, которые тестируют непосредственно вручную и интегрированы в команду разработки.
- Автоматизаторы пишут автотесты для тех функций, которые уже не меняются.
Вывод
Не для каждого проекта требуется большая команда тестировщиков, где-то будет достаточно на первоначальном этапе интегрировать в проектную команду 1-2 тестировщиков, а где-то потребуется организовать системный подход к контроля качества с ведением всей необходимой тестовой документации.
Каждый проект по-своему уникальный, и в выборе подхода к тестированию можно и нужно проявлять гибкость.
К нам в Qualitica обращаются клиенты с разными проектами. Это может быть простой сайт, интернет-магазин или сложный портал с личными кабинетами и множеством модулей. У нас в свою очередь есть система управления тестированием, узкие специалисты, иерархия и, конечно, автоматизация. Мы умеем и готовы помочь повысить качество ваших услуг и программных продуктов.