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

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

Подход 1:  Тестированием занимается разработчик или менеджер.

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

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

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

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

Подход 2: Тестировщиков нанимают на стадии завершения.

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

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

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

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

Подход 3: Тестировщики проверяют все задачи разработчиков на предмет соответствия результата изначальной постановке задачи.

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

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

Подход 4: Тестировщики занимаются тест-дизайном.

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

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

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

Но можно и лучше:

Подход 5: Внедряется система управления тестированием.

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

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

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

Подход 6: Появляется автоматизация тестирования.

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

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

Существует множество технологий для автоматизации тестирования. Со временем в Qualitica мы выделили для себя следующие:

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

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

Подход 7: Усложняется иерархия, появляются новые роли в команде тестирования.

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

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

Вывод

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

Заказать тестирование
Правила обработки персональных данных

Пользователь, заполняя форму обратной связи на интернет-сайте http://qualitica.ru, принимает настоящие Правила обработки персональных данные (далее — Правила). Действуя свободно, своей волей и в своем интересе, а также подтверждая свою дееспособность, Пользователь дает свое согласие ИП Бормотов Иван Сергеевич на обработку своих персональных данных со следующими условиями:

1. Данное согласие дается на обработку персональных данных, как без использования средств автоматизации, так и с их использованием;

2. Согласие дается на обработку следующих персональных данных, не являющихся специальными или биометрическими: фамилия и имя, телефон, e-mail, пользовательские данные (сведения о местоположении; тип и версия ОС; тип и версия Браузера; тип устройства и разрешение его экрана; источник, откуда пользователь пришел на сайт; язык ОС и Браузера; какие страницы открывает и на какие кнопки нажимает пользователь; ip-адрес);

3. Персональные данные не являются общедоступными.

Письмо отправлено

Наш менеджер свяжется с вами в ближайшее время