t.me/atinfo_chat Telegram группа по автоматизации тестирования

Стратегия e2e автоматизации для десктоп wpf

Теги: #<Tag:0x00007f748be52a70> #<Tag:0x00007f748be52980> #<Tag:0x00007f748be528b8>

Люди добрые, подскажите пожалуйста стратегии автоматизации e2e на селениум и аналогах.

У нас есть много описанных ручных сценариев, были старые тесты на основе eggplant (работали по image recognition). От них отказались, но тупо брать и переписывать старые тесты смысла особого не вижу, так как они были не понятны команде и редко находили баги.

Писать автотесты, повторяющие 1-в-1 ручные сценарии тоже кажется не дальновидно.

1 длинный воркфлоу тест уже есть, покрывающий основной и самый главный сценарии приложения.

Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню).

Что дальше? Как приоритизировать сценарии?

Очень не хочется разводить e2e тестов длительностью более 2-3 часов… Но это трудно избежать, API у приложения нет совсем (это десктоп wpf)

Находить баги для автотестов - не основная задача. Основная - дать вам уверенность в несломанном функционале после нового релиза.

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

Итог для вас скорее всего будет такой:

  1. Взять ручные тесты, составить из них сьюты под смок тестирование. Реализовать смоки.
  2. Выбрать сценарии для регрессионного тестирования, приоритезировать и реализовать в коде.
  3. Оставшееся время, если оно у вас останется, потратьте на рефакторинг предыдущих реализованных тестов, а также на составление е2е сценариев.

Думаю добавить тесты на каждый экран приложения (просто проверить наличие элементов и возможно, открытие внутренних попапов/меню)

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

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