tgoop.com/QA_with_a_spoon/10
Last Update:
Контроль качества в FinTech - 4
Технологии: когда-нибудь (но это не точно) я принесу сюда красивую картинку с логотипами технологий/подходов, которые используются конкретно в нашей компании. Но, если честно, мне самой не кажется, что это самое важное.
Картинка очень красивая и производит впечатление, но без тест-анализа этими технологиями можно будет подтереться эти технологии помогут примерно никак.
Приведу максимально простой пример.
Допустим, есть окошко продажи чего-то там, ну не знаю, яблок.
Пользователь может поставить цену, по которой он хочет продать свои яблоки пакетами по 10 шт.
Правило валидации цены такое: Market price - D ≤ Price ≤ Market price + D
Где Market price - текущая рыночная цена пакета яблок (котировка)
D - некая дистанция.
То есть пользователь может поставить цену продажи в пределах текущей котировки +/- D.
Все это выглядит как задача с курсов для начинающих тестировщиков) Классы эквивалентности, анализ граничных значений, вот это все.
Действительно, задача тут сводится к применению простейших техник тест дизайна. Но с нюансами:
- котировки постоянно меняются, то есть нужно проверить валидацию цены при условии, что критерии валидации в каждый момент времени разные
- на коридор допустимых значений цены влияет параметр D, который приходит с бэкенда
- …а на наш бэкенд этот параметр приходит из двух разных источников (внешних интеграций)
Это в целом простая задача. Она покрывается тестами часа за 3-4 более-менее сфокусированной работы и тестируется примерно за такое же время. Еще пару часов я обычно накидываю на проверку багфиксов. Тем не менее, даже тут есть моменты, об которые можно споткнуться. Примеры:
- Не задать вопрос “что конкретно сделано” и неправильно оценить скоуп тестирования. Представим, что были обновлены контракты для обеих двух интеграций, а протестирован только UI для одной интеграций. Или наоборот - было маленькое изменение на фронтенде, а протестированы обе интеграционные цепочки
- Не захотеть возиться с проверкой точных граничных значений. Проверить валидацию на глазок, вместо того, чтобы задать вопрос “а не могу ли я как-нибудь так остановить котировки или/или посылать нужные значения котировок?”
Если эти вопросы не были дожаты до конца, может оказаться, что протестировано совсем не то, что нужно.
Мораль:
- Технологии это хорошо, но недостаточно. Нужны суперсилы в области тест-анализа
- Сдвиг влево и анализ рисков при планировании регресса - наши друзья
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Share with your friend now:
tgoop.com/QA_with_a_spoon/10