Банковское обозрение

Финансовая сфера

  • Пять правил настройки тестирования банковских IT-продуктов
23.08.2019 Best-practice
Пять правил настройки тестирования банковских IT-продуктов

Чек-лист хирурга — контрольный перечень вопросов, на основании которых проверяется, правильно ли выполнена та или иная работа, — снижает вероятность послеоперационных осложнений и смертей почти на 5%


Екатерина Забродова
Директор по производству (CPO) компании Umbrella IT

IT-чек-лист — QA (Quality Assurance) — в финансовой сфере в теории решает схожие задачи — минимизирует влияние человеческого фактора, сокращает time to market банковских продуктов и повышает их безопасность и качество. Как эффективно настроить тестирование, за счет чего это сделать и к каким результатам это приведет? Представляю топ-лист «рецептов», проверенных Umbrella IT на практике

1. Привлекайте тестировщиков с сильной технической экспертизой и вовлекайте их в работу над продуктом.

Что делаем: 

  • повышаем техническую компетентность: слабая техническая подкованность тестировщика ведет к недостаточно глубокому тестированию из-за непонимания того, как реализована задача, как она взаимосвязана с остальными функциями продукта. Обнаруживаются только поверхностные ошибки, не проверяются кейсы, которые могут встретиться пользователям при определенных обстоятельствах. Например, не зная, как устроены cookie-файлы, можно пропустить ошибки, связанные с безопасностью, или не проверить случаи, когда срок жизни cookie-файла истек;

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

Что получаем: 

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

2. Пусть тестировщики осваивают специфику вашего сектора и становятся в нем экспертами.

Что делаем:

  • обучаем более глубокому пониманию отрасли: тестировщик, не имея глубокого понимания нюансов бизнес-процессов, работает исключительно по задачам и не может тестировать глубоко, то есть проверять не только очевидные пользовательские функции, но и неочевидные технические взаимосвязи между ними, не может дать рекомендации по улучшению функционала, предостеречь от ошибок конкурентов или «подсветить» их успех. Например, не понимая, что такое индивидуальный инвестиционный счет (ИИС), можно не заметить, что кнопка «Вывести денежные средства» активна, даже если счет открыт менее трех лет назад, хотя это невозможно.

Что получаем:

  • повышаются скорость и качество тестирования. Понимая, как устроены бизнес-процессы и что значит отраслевая терминология, тестировщик не тратит время на выяснение того, «что это» и «как это работает», и быстрее находит взаимосвязи между модулями. Кроме того, появляется возможность проверить большее количество конкретных кейсов и заметить такие несоответствия, как в примере с ИИС.

3. Не экономьте на тестировщиках и оборудовании

Что делаем:

  • набираем достаточное количество специалистов QA: если у вас один тестировщик на пятнадцать разработчиков, не ждите чуда. Один человек может справиться с таким потоком задач, только проверяя поверхностно, для углубления ему банально не хватит времени. Оптимальное соотношение — один тестировщик на трех-четырех разработчиков, но в конечном счете все зависит от сложности продукта, уровня квалификации разработчиков и используемых подходов к тестированию;

  • вкладываемся в парк устройств: тестирование на эмуляторах уместно только до определенного момента. В реальной жизни с продуктом будут работать тысячи пользователей с самых разных устройств, и особенности этих устройств необходимо учитывать. Например, iPhone с его «бровью», Samsung S10 с его вырезом под фронтальную камеру или Samsung с процессором Exynos и процессором Qualcomm могут по-разному работать с приложением. Плюс нужна проверка кейсов взаимодействия с другими приложениями: что будет, например, если на смартфон позвонят, когда приложение открыто, или если сработает будильник. Нужно определить целевые устройства и проверять реальные пользовательские сценарии на реальных, физических устройствах.

Что получаем: 

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

4. Не отделяйте процессы тестирования от процессов разработки

Что делаем:

  • включаем тестировщика в команду уже при постановке задачи. В этом случае тестировщики смогут обнаружить баги и несоответствия еще на этапе планирования, а ,эти ошибки — самые «дешевые», их устранение требует меньше всего средств. Кроме того, тестировщики смогут вносить ценные предложения на этапе планирования, а не на этапе тестирования. И если предложение будет стоящим и его возьмут в работу, не придется переделывать всю задачу. Если тестировщики не взаимодействуют с разработчиками и не понимают, как «сделана» задача, им приходится дольше разбираться, чем в случае, когда есть кому задать все интересующие вопросы. Тестировщику сложно быстро отреагировать, быстро решить, баг это или не баг. Например, разработчик может подсказать, что у подключенного API имеется ограничение на пять запросов в минуту и, если на шестой раз появится ошибка, это не баг. Если это не пояснить заранее, задача может пролежать в списке возвращенных на доработку после тестирования несколько дней, прежде чем разработчик обоснует ошибку.

Что получаем: 

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

5. Внедрите стандарты тестирования и следите за их соблюдением

Что делаем:

  • тестируем новый функционал параллельно разработке: уходим от схемы, когда 1) производится релизная сборка и только затем — тестирование всего релиза в целом с последующим устранением выявленных багов; 2) в тестовой среде одновременно залито много нестабильных, нетестированных задач, и это усложняет локализацию багов;

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

  • автоматизируем не просто «для галочки»: автоматизация должна быть эффективной, ее должно быть удобно использовать. Если ее может настроить и запустить лишь узкий круг людей, такое «бутылочное горлышко» замедляет все процессы;

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

Что получаем: 

  • сокращается время на исправление багов и увеличивается объем функционала, который тестируется в рамках одного спринта, в итоге ускоряется вывод продукта на рынок. 




Читайте также

Сейчас на главной