Тесты-кейсы как код (TсaC) и как с этим живется в больших командах

Многие уделяют излишнее внимание TMS, забывая об изначальной цели нашей работы — обеспечении качества продуктов, желательно с наименьшими затратами. В докладе разберем и сравним разные способы организации работы QA-инженеров с акцентом на Test cases as Code для больших и быстрорастущих команд.

Обсудим:

• Кому и для чего концепция TсaC может быть полезна.
• Классические реализации с BDD и интеграции с TMS.
• Переосмысление и реализацию этой концепции от команды банка с помощью доступных всем инструментов.

Основные тезисы:

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

Из доклада вы узнаете, как идеи описанные в докладе «Тест-кейсы как код» Артема Ерошенко и идеи из книги «Specification by Example» Гойко Аджича можно реализовать на практике.

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

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