Митап Testify #8: Качество вопреки хаосу 5 декабря в 18:00

Гибридный подход к тестированию против парадокса пестицида. Кейс Lamoda Tech

626 2 min

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

Компания Lamoda Tech путем проб и ошибок выработала собственную стратегию для качественного покрытия релизов тестами. Тимлид команды разработки Наталья Филиппова рассказала, из чего состоит этот подход.

Lamoda против парадокса пестицида

Чек-листы или тест-кейсы? Поиск идеального баланса 

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

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

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

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

⭑ Парадокс пестицида — эффект, при котором при регулярном прогоне тестовых сценариев ошибки перестают обнаруживаться.

Чтобы обойти парадокс, мы решили создать гибридный подход, который объединяет преимущества тест-кейсов и чек-листов: 

  • Используется подход тест-кейсов для использования ожидаемых результатов.

  • Вместо четких критериев прохождения каждого шага — список проверок, как в чек-листе.

Это позволяет тестировщику включить несколько проверок в одном шаге тест-кейса и упрощает проверку каждого шага тест-кейса. 

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

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

Правила написания гибрида

Свой подход мы структурировали в системе управления тестированием Test IT и установили правило, что один шаг в нашем гибриде соответствует одной проверке, а ожидаемый результат должен отражать возможные варианты. Мы не описываем их подробно, так как исчерпывающее тестирование на практике все равно невозможно.  

Например, на нашей продуктовой странице есть блоки «Отзывы», «Фотоотзывы» и «Вопросы». Если бы мы писали тест-кейсы, понадобилось бы не менее 15 тест-кейсов, но с помощью нового подхода уместили всё в один гибрид, в котором проводим пять проверок.

Гибридный подход к тестированию в Test IT

Тестирование фичей: чек-листы + гибрид

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

Чек-лист в Confluence для интеграционного тестирования

Такой формат удобен для проведения интеграционного тестирования: мы отмечаем, какие тесты прошли, а какие провалены. Эта информация сохраняется, ее видят продакты, аналитики и разработчики, однако мы не используем ее в дальнейшем. Например, при прогоне релиза. 

Если мы понимаем, что фича точно будет включена в релиз, то пишем для нее гибрид. Например, так у нас было с «Возвратами». Сначала мы написали чек-лист в Confluence, а после успешного теста составили к нему гибрид в Test IT. 

Написание автотестов на основе тест-кейсов

UI-автотесты мы пишем на Kaspresso и XCUITest, которые ведутся в коде проекта, и кроме разработчиков и тестировщиков никто не знает о том, какие автотесты есть и что они проверяют, поэтому было принято решение их документировать. 

У UI-автотеста  есть предусловия, шаги и ожидаемый результат, подход тест-кейсов идеально подошел под формат.

UI-автотесты в Test IT UI-автотест в коде проекта

Документирование автотестов позволило нам сначала составлять конкретные тест-кейсы, а затем уже на их основе писать автотесты. Раньше, когда мы писали автотесты сразу в коде, возникала проблема с тест-дизайном, что замедляло процесс тестирования. Теперь же, фиксируя свои мысли «на бумаге», мы избавились от этой проблемы.

К чему мы пришли. Выводы

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

Была ли статья полезной?