vc.ru ищет PHP Middle разработчика

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 обращаются клиенты с разными проектами. Это может быть простой сайт, интернет-магазин или сложный портал с личными кабинетами и множеством модулей. У нас в свою очередь есть система управления тестированием, узкие специалисты, иерархия и, конечно, автоматизация. Мы умеем и готовы помочь повысить качество ваших услуг и программных продуктов.

{ "author_name": "Игорь Ниточкин", "author_type": "self", "tags": [], "comments": 6, "likes": 11, "favorites": 17, "is_advertisement": false, "subsite_label": "dev", "id": 137530, "is_wide": true, "is_ugc": true, "date": "Fri, 26 Jun 2020 13:43:31 +0300", "is_special": false }
Объявление на vc.ru
0
6 комментариев
Популярные
По порядку
Написать комментарий...
0

+

Ответить
0

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

Довольно странная рекламная статья, которую в добавок неплохо было бы вычитать. ;) 

Расскажу как строить правильное QA, дорого. 

Ответить
0

 Автоматизаторы, как выделенный из команды разработки фулл-тайм юнит, вообще довольно сомнительная затея.

Почему сомнительная затея? Тогда выделение DBA, DevOps тоже сомнительная затея.

Ответить
0

Самое парадоксальное, что переход на уровень 6-7 никак не гарантирует рост качества тестирования. И выясняется это как раз при помощи уровня 1: аналитик/менеджер потестировал, и стало понятно, что из условно 2-х фичей корректно работает 0 фичей) Зато иерархия, митинги, подходы и выступления на конфах)

Ответить

Комментарии