Был критический функционал, который необходимо покрыть в первую очередь. И который нужно было проверять от релиза к релизу.
Со стороны руководства и других членов команды (аналитики, внедренцы) был четко обозначен этот функционал + вещи на которые стоит обратить внимание при проверке (ПФ, лист согласования, корректность движения задач по процессу).
Как это все будет проверятся и в каком объеме — решала непосредственно QA-команда.
Если что-то пропустили или не учли, то уже на следующих итерациях это исправлялось. Например, нашли баг в функционале, который автотесты не покрывали. После его исправления добавили тест, который это момент проверяет.
Ваше предложение правильное. По крайней мере, я делал также.
Если нужно в одном файле проверять статические и динамические данные, то необходимо его разбивать на разные области. Верстка (статика) проверяется тем же самым скриншот тестированием. То есть либо вырезаем нужную нам область картинки и сохраняем для сравнения, либо сохраняем всю, а уже средствами, например, Yandex aShot игнорируем не интересующие нас области (динамика). Их как раз можно проверить через парсинг.
Возьмем ту же печатную форму со штампом. Ее можно разбить на 3 части:
1. Шапка документа – всегда статична. Мы ее обрезаем и сохраняем как картинку, в тесте проверяем через сравнение скриншотов.
2. Номер документа, дата – ее как раз можем проверить через сохранение файла и парсинг данных.
3. Штамп – почти статичен. Идем путем из п.1.
Данные в штампе зависят от ЭП. Но мы можем с уверенностью сказать, когда эта подпись изменится (срок действия) и поменять эталон изображения в тестах. Это происходит не так часто. Например, сейчас используем подпись, которая действительна 1 год. Не вижу в этом проблемы.
По поводу порогового значения при сравнении изображений. Я бы не советовал такой подход использовать. Был не очень положительный опыт, тесты становятся хрупкие и ненадежные. Лучше вырезать и игнорировать ненужные области на картинках.
Со стороны руководства и других членов команды (аналитики, внедренцы) был четко обозначен этот функционал + вещи на которые стоит обратить внимание при проверке (ПФ, лист согласования, корректность движения задач по процессу).
Как это все будет проверятся и в каком объеме — решала непосредственно QA-команда.
Если что-то пропустили или не учли, то уже на следующих итерациях это исправлялось. Например, нашли баг в функционале, который автотесты не покрывали. После его исправления добавили тест, который это момент проверяет.
Если нужно в одном файле проверять статические и динамические данные, то необходимо его разбивать на разные области. Верстка (статика) проверяется тем же самым скриншот тестированием. То есть либо вырезаем нужную нам область картинки и сохраняем для сравнения, либо сохраняем всю, а уже средствами, например, Yandex aShot игнорируем не интересующие нас области (динамика). Их как раз можно проверить через парсинг.
Возьмем ту же печатную форму со штампом. Ее можно разбить на 3 части:
1. Шапка документа – всегда статична. Мы ее обрезаем и сохраняем как картинку, в тесте проверяем через сравнение скриншотов.
2. Номер документа, дата – ее как раз можем проверить через сохранение файла и парсинг данных.
3. Штамп – почти статичен. Идем путем из п.1.
Данные в штампе зависят от ЭП. Но мы можем с уверенностью сказать, когда эта подпись изменится (срок действия) и поменять эталон изображения в тестах. Это происходит не так часто. Например, сейчас используем подпись, которая действительна 1 год. Не вижу в этом проблемы.
По поводу порогового значения при сравнении изображений. Я бы не советовал такой подход использовать. Был не очень положительный опыт, тесты становятся хрупкие и ненадежные. Лучше вырезать и игнорировать ненужные области на картинках.