Я инженер по автоматическому тестированию и называю это профессиональным риском. Я продолжаю думать о том, чтобы сделать автоматизированное тестирование эффективным и легким.
Пару недель назад я подумал, на самом деле просто удивлялся, можем ли мыпредставить новый процесс, в котором я заставляю дизайнеров / разработчиков предоставлять мне каркас для каждого отдельного или уникального экрана в веб-приложении.Пример: в гипотетическом веб-приложении, если домашняя страница отображается по-разному для разных профилей, таких как сотрудники, утверждающие, аудиторы и менеджеры, я хочу использовать каркас для каждого из этих профилей.Но если в организации есть 2 менеджера (комбинации данных), я не ожидаю, что для этих 2 менеджеров будет каркас, поскольку меняются только данные, и структура останется такой же с точки зрения автоматического тестирования.
Это помогает в автоматизацииследующим образом:
Скажите, что начинается спринт, и решено, что в этом спринте должны быть разработаны 2 новые функции.
Каркасы для этих2 новых функции должны быть предоставлены всей команде в начале выступления спринта на совещании по планированию спринта.
Используя эти каркасы, я автоматизирую свои тестовые случаи и когда будут развернуты действительные экраныЯ бы просто запустил свои автоматизированные тесты.Конечно, они потерпят неудачу из-за некоторых незначительных проблем, но их будет легко исправить.Это гораздо лучше, чем не запускать автоматизацию до тех пор, пока не будет развернут фактический экран.
Если такой подход возможен, позже я буду требовать свойства идентификатора и имени пользовательских элементов управления (например, ссылки, кнопки, редактировать поля, флажки, переключатели и т. д.) вместе с каркасами.Мне известно, что некоторые группы уже совместно используют команду идентификаторов и имен пользовательских элементов управления с их группой автоматического тестирования, чтобы они могли автоматизировать тестовые сценарии даже до развертывания реальных экранов.Вы могли бы сказать, что моя идея - немного улучшенная версия этого.
Это звучало непрактично, поэтому я перестал думать об этом, но позже почувствовал, что должен спросить сообщество, возможно ли это?если да, то какие накладные расходы стоят на общей команде разработчиков / проектировщиков.
Некоторые разработчики, читающие это, могут подумать, что, пффхххх ... у нас уже полно материалов, и это было бы излишним.Но поверь мне.Раннее сотрудничество с тестировщиками и автоматизаторами-тестерами действительно помогло бы качеству приложения.Поэтому, если накладные расходы находятся в допустимых пределах, мы могли бы подумать о внедрении этого процесса.
Пожалуйста, дайте мне знать ваши взгляды.