Домой » Теория автоматизации » Какие тест — кейсы автоматизировать?

Какие тест — кейсы автоматизировать?

Test Case

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

Что вообще происходит?

Нет смысла покрывать автотестами, что покрыто unit – тестами и интеграционными тестами. Зачем тестировать дважды? Хотя был проект когда вроде и юнит – тесты есть, но всё равно на сложных элементах (меню навигации, таблицы и прочие самодельные) выскакивали баги. Тогда у нас были стори именно на тестирование их функционала.

В таком случае основной функционал мы не сильно трогали, т.к. он косвенно покрывался end-to-end тестами. Старались по максимуму протестировать редко используемые и не совсем критичные функции.

Как прекрасно, что мы сегодня здесь собрались!

Немаловажным является и состав QA – команды. Рассмотрим худший вариант: автоматизаторов гораздо меньше, чем мануальных тестировщиков. В таком случае extend тесты не представляется возможным покрыть, т.к. не всегда хватает время и на критикалы. Чтобы сильно не тормозить и успеть к срокам мы автоматизировали самые трудозатратные и часто используемые тест – кейсы. Иногда тот или иной тест сложно заавтоматизировать и траты на его автоматизацию несопоставимы с выгодой, в таком случае его следует пропустить. Лучше вместо него, пускай, будут проходиться несколько лёгких.

Не подскажите, как пройти к библиотеке?

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

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

Когда начинаем?

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

И жили они долго и счастливо!

В принципе, накапитанил я сколько пришло в голову. Если есть вопросы/дополнения – смело пишите в комментарии или на почту.

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*
*