Регрессионное тестирование, как лучше производить учет тестов?

общие вопросы
, , , ,
#1

У нас есть автотесты (java + selenium) для регрессионного тестирования продукта, который написала наша компания.
Есть перечень страниц. Для каждой страницы решили составить перечень действий для примерного представления покрытия тестами функционала.
Прошлись по существующим тестам и прописали, какие действия проверяет каждый тест.
Решили занести эти данные в БД: страницы-действия-тесты.
Есть мысль написать приложение для работы с этой БД, к примеру: при добавлении новой страницы мы через приложение описываем действия, которые на этой странице можно произвести и пишем какие тесты проверяют эти действия.

Вопросы в моей голове:

  1. Вообще целесообразно ли делать проверку всего функционала автотестами? Сейчас проверяется даже меньше половины и то тесты идут пару часов.
  2. Есть ли смысл делать подобное приложение-справочник? Какие вы плюсы-минусы видите? Есть ли что-то подобное уже?
#2

А почему бы не воспользоваться готовыми системами типа testlink.

#3
  1. Только Вы можете оветить на вопрос целесообразно ли тестировать весь функционал в вашем приложение.
    Например ничего страшного если не покрыт функционал который не используется и не меняется,
    но … если он используется и меняется это уже риск и наверное плохо (стоит задуматся о покрытии).
  2. Такие функциональные карты/ матрицы покрытия часто делают.
    В самом простом случае это страничка на вики. confluence или табличка в экселе.
    Почти все тест менеджмент тулы поддерживают создание таких Functional Map / Requirement Traceability Matrix

Из плюсов

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

Из минусов

  • такая таблица по сути альтернативное представление приложения и она настолько хороша насколько её хорошо составили (может не отображать реальный функционал, реальную картинку покрытия)
  • кто то должен её поддерживать актуальной - может утяжелить процесс
1 лайк
#4

1 При “проверяется даже меньше половины” неплохо учитывать еще и критичность функционала. По опыту редко когда детальная автоматизация всего подряд дает реальный профит. А вот затраты на поддержку фреймворка значительно возрастают, как и время прогонов.
2 И как было сказано выше вместо написания велосипедов лучше использовать готовые решения систем тестМенеджмента
3 Очень часто после пары релизов на подобную документацию-справочники кладут болт)

1 лайк