Comments 5
У вас схема алгоритма проверок по экрану зациклена. Она никогда не закончится
Спасибо за подробную статью. Очень много полезных деталей.
Мне кажется, Ваш подход только выиграет, если вы посмотрите на содеянное как на модель тестирования. Да термин этот более подходит к вашему описанию.
UML, Model based testing вы используете?
Неплохая классификация проверок, и нарисовано очень наглядно.
Единственное, что хочется уточнить, - "Тестировщик, пришедший с другого проекта или из другой компании, должен понимать, что и как ему проверять. В идеале ему не обязательно искать дополнительную информацию: всё есть в тестах." - все же релевантно не для всех компаний. На написание кейсов "так, чтобы его могла выполнить уборщица", уходит достаточно много времени и сил, и информация обычно избыточна для человека, который работает с приложением каждый день. Поэтому если команда обновляется реже, чем раз в полгода-год, будет дешевле обучить новичков, так сказать, вручную, а проверки писать высокоуровнево. Типа "Создать статью" вместо "Открыть страницу создания, нажать кнопку, ввести заголовок, бла-бла-бла"
Структура, содержание и процесс написания проверок