Тестировщик банковских продуктов что такое

Обновлено: 28.03.2024

Профессия в сфере IT гарантирует стабильную работу, высокую оплату труда, перспективу карьерного роста. Но что, если вы считаете, что программирование — не ваша стезя?

Есть множество других перспективных IT-профессий. Одна из самых востребованных — тестировщик программного обеспечения. Её может освоить каждый — неважно, есть ли вам восемнадцать, или вы перешагнули за пятидесятилетний рубеж.

Это специалист, который проводит анализ программного обеспечения, разработанного программистами.

Есть тестировщики, которые проверяют работоспособность готового продукта: сайта, приложения, компютерной игры и т.д. А есть инженеры QA, от английского «quality assurance», что в переводе означает «обеспечение качества». Эти специалисты тестируют софт на этапе разработки, внося правки в процессе.

Тестировщики подразделяются на много разновидностей в зависимости от уровня скиллов, которыми владеет специалист. Есть те, кто владеет автоматизированными способами тестирования, есть аналитики, разработчики-тестировщики и т.д.

Потому что бизнес хочет продавать качественный продукт, удобный в использовании, получать положительные отзывы и рост продаж. А не негатив в Сети и падение рейтинга компании из-за обилия ошибок в софте.

· собрать требуемый спектр данных о проекте;

· протестировать программу по заданному регламенту, смоделировать вероятные ситуации, которые могут произойти при использовании ПО;

· проверить ПО на работоспособность;

· выявить все баги и системные ошибки, приводящие к сбою софта;

· описать проблемы, чтобы разработчики могли внести правки;

· провести повторное тестирование после внесения правок.

Всё работает? Тогда готово! Не работает? Всё заново.

Цель работы тестировщика – цифровой продукт, который не будет выдавать ошибок, что бы ни делал пользователь. Здесь есть и элемент психологии: тестировщику нужно уметь думать, как пользователь, далёкий от IT, ставить себя на его место. Поэтому в компаниях ценят новичков: они замечают такие детали, которые профессионалы не видят с высоты опыта.

Чтобы стать тестировщиком, не обязательно тратить 4-6 лет на вуз. Получить актуальное образование можно самостоятельно, находя информацию в гугле, или на специализированных курсах, что значительно быстрее и удобнее. Обучение с преподавателем займёт примерно 1 год.

Работодателю не важно, сколько вам лет, и по какой специальности вы работали раньше. Главное — ваш профессионализм и практические навыки.

Будет отлично, если вам удастся устроиться на старте в IT-компанию, где вы наберётесь опыта под руководством наставников. Это даст мощный толчок в развитии.

Среди списка плюсов специальности выделим пятерку самых-самых:

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

2. Стать тестировщиком проще, чем научиться программированию.

3. Можно работать как в штате, так и на фрилансе.

4. Перспектива высокой оплаты труда уже в скором времени после окончания учёбы.

5. Профессия точно будет актуальной ближайшие 10-20 лет.

6. Быстрое продвижение по карьерной лестнице: у тестировщика есть все возможности вырасти до бизнес-аналитика, менеджера проектов или руководителя команды.

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

8. Одна из самых востребованных профессий в России и за границей. На сайтах вакансий постоянно публикуются новые объявления о поиске сотрудника.

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

1. Часть работы – рутина и монотонные действия. Впрочем, это касается любого интеллектуального труда.

2. Программисты зарабатывают больше.

3. Если вас интересуют зарубежные проекты, придётся выучить английский язык.

Заманчивый и доказанный факт: если вы сегодня начнете работать тестировщиком, то уже через 5 лет сможете смело назвать себя представителем среднего класса даже по европейским меркам.

Это подтверждают средние з/п тестировщиков в Москве:

● начинающие специалисты — $1200;

● профессионалы более чем с 5-летним опытом — $2500-3500.

В регионах зарплаты меньше. Специалист с минимальным опытом зарабатывает от 40000 рублей.

Фрилансерам выгоднее работать с западными компаниями удалённо. Здесь заработки варьируются от 10 до 30$ в час.

Интересные комментарии какие

Отличный комментарий! Ждем такой же, только про проггеров! Для новичков - самое то!

Спасибо за комментарий

Ну, не обманешь - не продашь. Если же вернуться к реальности, то получится вот что:
- в первый год-полтора тестер без опыта больше 50к рублей не получит. И не важно, с курсами он или только Савина осилил. Так что не тратьте деньги и время. И будьте готовы к тому, что этот год проведёте, без конца гоняя унылые тест кейсы вида "нажми на кнопку-проверь результат", потому что что-то более сложное вам вряд ли доверят.
- дальше можно подумать о какой-нибудь специализации (автоматизация или что-нибудь специфическое в зависимости от проектов) и просить 70-80к. Про 3500 долларов после 5 лет работы тестером - ну это даже не смешно.
- стать программистом, возможно, и будет проще, чем совсем с нуля. Но только за счёт того, что у любого нормального тестировщика вырабатывается общее понимание процесса разработки и архитектуры типового проекта. Никаких специальных скиллов программиста тестировщик не приобретает.
- про быстрое продвижение в аналитики или лиды забудьте, это бред.

ну вот зачем обламывать всех такой точкой зрениЯ? ты же понимаешь что у всех разные способности навыки и тд, твоя оценка среднего по больнице вообще ни о чем не говорит. На самом деле возможностей дофига 3500 это не потолок и реально можно иметь эту зп и с опытом 3 года. А тебе это кажется не смешно. Просто ты не совсем в теме существующего рынка труда и предложений который есть. Зайти в телеграм каналы посмотри как много вакансий там для тестировщика с зп в 4000$.

Сейчас некоторые уже пишут «минимум 3 месяца опыта», и зарплату от 80к.

Спасибо за мнение! Мы не продаем на VC. Не нужно искать рекламу там, где ее нет. На данной площадки мы делаем акцент только на информативный и полезный контент.

Gray Matter понравился ваш коммент, подскажите мне как искать первую работу? Просить очного собеседования как советует Святослав Куликов? Что я знаю? Читал Савина в своё время имею представление что такое Баг репорт, Тест кейс, Тест дизайн,какие есть виды тестирования, SQL(планирую скачать SQL, поделать запросы простые) Прочитать Куликова( если там что то есть то что Савин упустил) пройти бесплатный курс Яндекс Практикум, Английский у меня на уровне чтения пока что не на уровне технической документации. Надеюсь прочтете мой коммент, заранее благодарен.

Посмотрите автора школы it-switcher. Оксана зовут. Она еще быстрее прошла путь, о котором написано в статье. У нее инстаграм есть, где она подробно рассказывает. Есть и ролики на ютюбе. Канал «в айти». Там 25-30- минутные ролики с героями , которые перешли в айти из других сфер. Все иначе, чем Вы написали.

Вообще в сша на позиции QA можно и 10к чистыми получать, и я знаю такие примеры, все обосрался?

Знакомые автотестеры на аутсорсе получают 90~ со стажем 2 года. В штате крупных компаний платят 100+ со стажем год (если брать по финтеху среди тех, с кем общаюсь).
На счёт скилов программиста тоже не согласен, опять же для автоматизации требуются знания языка и некоторых библиотек, разработчиком не станешь, но опыт релевантный.
В общем я более оптимистичен в оценке перспектив по зп и возможностей роста (основываясь на личном опыте и круге знакомых ~20 человек тестеров)

Маловато что-то. Даже мануальщикам с опытом от 100к предлагают

Так в статье написано про manual qa, а не qa automation. Автотестеру уже программировать надо уметь, а в статье про войти в айти без навыков программирования.

Еще один фактор полезный раскрывается - перспективы

Статья устарела на пару лет. Давно уже прошли те времена, когда нанимали десяток qa для ручной регрессии. Не сказал бы, что сейчас это такой просто вход в it. Давно уже вижу тренд на автоматизацию тестирования, сокращение позиций manual qa. На оставшиеся позиции тестировщиков без программирования конкуренция большая.

Намного проще выучить язык программирования и какой-нибудь selenium и зайти на junior qa automation.

Иван а б хотел с Мануала начать.Не получиться?

Тестировщик - это программист на пенсии.
Точно также, как строитель на пенсии становится охранником.

Но с более хорошей зарплатой, и в отличие от охранника, есть куда расти)

Когда программы будет писать AI, тестировщики всё ещё будут нужны

Интересная статья. Скажите пожалуйста, я правильно понимаю, что это скрытая реклама курсов по тестированию?

Вообще нет. Отсутствие ссылок, информации о курсах нигде нет и не будет. На VC мы даем только пользу, без рекламы.

Можно точно такую же статью только про программиста, пожалуйста?

конечно, сделаем, обязательно

Отличная статья, ждем такую же, но про прогеров

Неплохая профессия для новичков

довольно популярна для фриланса, поэтому для новичков самое то

верно, неплохой выбор

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

Вполне возможно, что и вы правы, мы берем в основу что-то среднее

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

Ну я например знаю таких, и что дальше? познакомить?

Я окончила онлайн курсы за 2,5 месяца. Первую работу искала 3,5 месяца. Стартовая ЗП тестировщика без опыта в Новосибирске в хорошей компании - 35 тысяч.

Раиса мы с вами соседи, я с Омска но у нас так и не смог стать тестировщиком, щас в Питере буду пробовать тут.

Раиса, где учились? Курсы понравились? Вы на рчного тестировщика на курсах учились и на автоматизированное уже на работе?

Спустя чуть меньше 2,5 лет ушла на новую работу с ЗП 60 тыс. Ушла бы раньше, но не было уверенности в своих силах. Для ИТ невысокая зарплата, но у меня всё впереди. По сравнивнению с прошлой работой в экологии после 6 лет магистратуры, сейчас я просто в шоколаде. Переучиться на тестировщика - это лучшее решение в моей жизни.

Раиса, а где вы учились?

Из тестирования не собираюсь уходить, здесь огромное поле для развития. Людям с критическим мышлением будет очень интересно.

Всем добрый день! Подскажите, пожалуйста, знающие люди. 1.Если конечная цель - разработка игр для пк, а хочется начать, наверное, как это часто бывает, с тестировщика, то обязательно ли сразу идти в компанию, которая пишет для пк или можно начать с тестирования мобильных игр? 2. Почти во всех вакансиях известного сайта по поиску работы требуется хотя бы полгода опыта (тестировщик). Где его взять?

Когда писалась статья? Это еще актуально? Просто поступил не туда и сейчас жалею, а тут наткнулся на эту статью и назрел вопрос: какие навыки надо иметь для работы? Обязательно ли уметь программировать хотя бы на базовом уровне?

Чем статья не устраивает. Фантастика у вас в головах, а не в статье. Люди разные, цены на их навыки разные, понимание у них разное и всё остальное тоже разное. Кто-то от кого совсем не ждали - выстрелил, а кто-то в кого верили - остался с минимумом. Никогда не знаешь. Так что делайте то что считаете нужным, то что САМИ считаете нужным, никого не слушайте. А если ошибаетесь, получите ценный опыт и пробуйте дальше то что считаете нужным. От этих попыток будет больше пользы чем от того что вы кого-то наслушаетесь . только линии жизни разные. Может быть у вас и получится, но не то что вам нужно.

Большая просьба дать рекомендацию по выбору курсов или преподавателя по тестированию. Неделю читаю в интернете про разные курсы и не могу определиться. Негативные отзывы есть по всем, про кого до настоящего времени прочел. Негатив касается важных для меня тем. Это:
1. На уроках одна вода или оч поверхностно дают материал.
2. После уроков дают задание, которое непонятно как выполнять.
3. Большую часть информации для понимания, как выполнить задание, приходится гуглить.
4. Обратную связь по ошибкам в задании приходится ждать несколько дней.
5. 20-летние учителя, которые даже на простую тему еле могут сформулировать мысль. Молчу про серьезные вещи по курсу.
6. Проблемы с возратом денег, если курс не отвечает заявленной программе.
В целом курсы сводятся просто к получению студентом корочки для того, чтобы при трудоустройстве ее показать. Или получить повышение.
Ни в одной школе мне не смогли четко объяснить , почему у них автоматизация преподается на java, python, javascript. Все, что услышал - это рекомендацию выбрать на java, так как большинство компаний в России работают именно на нем.
Мне нужны курсы онлайн формата, так как планирую их совмещать с основной работой из совершенно другой сферы, с гибким временем начала/просмотра уроков и общению с учителями онлайн, так как рабочий день ненормированный и в 6 часов встать и уйти я не могу.
Спасибо всем ответившим.

Я согласен с тем, что для вката в ит это наверное лушчий выбор. Сфера развивается, специалистов много требуется

Мануальщики востребованыв Москве?

Привет!С чего начать начинающему тестировщику который вообще полный 0? (НО! есть огромное желание, свободное время для обучения, открытость ко всему новому и терпение) Благодарю за добросовестный ответ!)

В преддверии запуска нового курса «Тестировщик» мы пообщались с его авторами — специалистами из Альфа-Банка о том, как выстроена система тестирования в их компании и какие требования предъявляются к кандидатам, а также расспросили о пути в профессию и сложностях в работе.

Александр Долинский, руководитель группы тестирования в Альфа-Банке и автор программы курса «Тестировщик» в Нетологии:



«В Альфа-Банке продуктовая разработка ведется по Scrum, поэтому тестирование тоже строится по Scrum, т. е. в тестировании принимает участие вся команда, но каждый на своем уровне экспертизы в соответствии с пирамидой тестирования.

Разработчики пишут unit-тесты и компонентные тесты, тестировщики пишут E2E-тесты, UI-тесты и интеграционные тесты. За счет этого удается держать оптимальный баланс времени на проведение тестов. На web проектах в тестировании используется подход BDD, по мобильному направлению у нас применяется некий микс BDD-подхода с собственными наработками. Все тестировщики распределены по Scrum командам, поэтому 80% времени они уделяют задачам команды и 20% времени отводят на технические долги по проекту или задачи комьюнити, через которые они прокачивают свои навыки в автоматизации, процессах CI/CD.

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

Кого берут в Альфа-Банк

«Альфа-Банк в лидерах по надежности и технологичности предоставляемых сервисов уже много лет — поэтому крайне важно, чтобы сотрудники компании были неравнодушны к процессам, старались постоянно совершенствовать их и совершенствоваться сами.

В первую очередь мы смотрим на человека, а уже потом на его бэкграунд.
Безусловно большой плюс — наличие технического образования, хотя в целом это не критичное требование. Нередки случаи, когда люди попадали к нам в команду совершенно из другой области без опыта и нужных знаний. Они набирали экспертизу серьезного уровня уже в процессе выполнения задач.

Из soft skills нам важно, чтобы человек умел общаться и грамотно выражать свои мысли (мы же в командах работаем), чтобы был любопытным и умел задавать вопросы и работать с ответами. Например, на собеседованиях мы даем задачи на рассуждение про тестирование робота, который должен подъезжать к клиенту и наливать кофе в стакан. Правильного ответа нет, но интересно наблюдать, как человек пытается протестировать этот случай.

В наш отдел тестирования точно не подойдет кандидат, который пришел только за деньгами, без тематических увлечений и интересов. Такой человек не захочет развиваться внутри команды, а для нас это важно.

В Альфа-Банке частый случай, когда специалист приходит на начальную позицию и через какое-то время развивается до тимлида по тестированию или вообще переключается на разработку. Много примеров, когда ребята из IT становятся успешными Product Owner. Мы за то, чтобы каждый мог попробовать себя в разных направлениях и выбрать для развития то, где ему наиболее комфортно и где он может раскрыть свой потенциал».


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

Как пришел в тестирование

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

Самостоятельно изучал JAVA как базу, иногда читал статьи на Хабре, но не делал акцент на каком-то конкретном направлении. Я находил интересным практически любое из них, и было сложно выбрать что-то одно, сделать первый шаг. А вдруг ошибусь в выборе? Ведь пока не окажешься внутри сферы, не поймешь, как на самом деле она устроена. В процессе обучения все материалы, которые я находил, оказывались чаще всего поверхностными. А если рассматривал курсы, то не мог поверить, что после них смогу устроиться на работу хотя бы наполовину уверенным в своей компетентности.

О профессии тестировщика я никогда не задумывался, не находил ее впечатляющей.
В Альфа-Банк я проходил собеседование на должность менеджера инфраструктуры. У меня были общие представления об обязанностях и требованиях, поэтому я выбрал именно эту специальность как точку входа в IT. На собеседовании мне предложили попробовать себя в роли тестировщика, описав эту должность, как одну из лучших для людей желающих прикоснуться к IT.

Некоторое время я потратил на то, чтобы понять, чем же действительно занимаются тестировщики. Не давал покоя вопрос, не буду ли я просто сидеть и бездумно нажимать какие-то кнопки без какой-либо перспективы развития.

Но в итоге решил попробовать. Могу сказать, что очень сильно ошибался: не было ни дня, чтобы я заскучал или ощутил, что нахожусь в каком-то застое. Задач море».

О трудностях в адаптации к новой сфере

«Не бывает такого, что ты пришел и все работало как по маслу. Меняя сферу, нужно оставить практически все ключевые навыки, которые приобрел ранее, и открыться новым знаниям. Первые две недели я не понимал, о чем идет речь на встречах. Всё, что не спрашивал сразу, записывал, запоминал и озвучивал уже после встреч.

В первый же день работы ко мне поставили наставника, который вводил меня в курс происходящего, терпеливо показывал и рассказывал все, чего я не понимал. В Альфа-Банке так принято. Помимо наставника есть целая команда тестировщиков, каждый из которых тебе всегда готов помочь. Если они это прочитают, то пусть знают, что я им очень благодарен за их отзывчивость и понимание!

Адаптировался я быстро, а вот обучаюсь до сих пор, и, наверное, никогда не перестану, как и каждый из людей, работающих в тестировании. Все-таки сфера постоянно развивается».

Советы специалистам, которые хотят в тестирование

«Если ищите настоящую точку входа в IT, то это она — скучно точно не будет. Мысли о том, что «немного посижу, потестирую, а потому буду пилить приложения», исчезают со временем сами собой.

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

Место для творчества всегда имеется, а идеи командой только поддерживаются.

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

От редакции

Мы в Нетологии запускаем новый курс по профессии «Тестировщик», программа которого подготовлена совместно с Альфа-Банком.

За 5 месяцев обучения разберемся с ручными и автотестами, проведем unit-тестирование приложения, решим более 40 задач на Java, поработаем с Selenium Webdriver и другими инструментами тестирования, а лучших выпускников Альфа-Банк пригласит на собеседование.

Также 21 мая приглашаем на открытое занятие «Тестировщик: требования и перспективы работы в Альфа-Банке», которое проведет Александр Долинский, руководитель группы тестирования в Альфа-Банке и автор курса.

Не всегда, приходя на крупный новый или старый проект, новый тестировщик знает с какой стороны подойти к началу процесса тестирования. Иногда нет куратора, иногда не настроен процесс коммуникации. И вы можете хоть сто раз плюнуть в компанию и пойти искать новую, благо рынок сейчас в дефиците. Но гораздо интереснее будет получить бесценный опыт становления вас как самостоятельного и понимающего члена команды. Данная статья будет посвящена теории тестирования реализаций системы антифрод в одном из крупнейших банков РФ. О чем мы поговорим в этой статье? Об особенностях архитектуры enterprise. Про основной инструментарий и про советы тем, кто захочет прийти в сферу интеграционного тестирования бэкэнда в крупную компанию.

Примеры будут браться из работ по интеграции антифрод-системы.

Инструментарий для тестирования

На собеседованиях на данную позицию кроме основных обязательных знаний по теории тестирования и работы с базовым инструментарием тестировщика также требуется набор знаний, нужных для понимания работы протоколов по которому это взаимодействие происходит. А также набор инструментов. Что в этот набор входит:

REST (часть взаимодействий идет через OpenAPI), JSON;

SoapUI и Postman (по желанию, какой инструмент удобен, тем и пользовались). Из практики, если очередь работает с XML - используем SoapUI. Если основа REST - Postman. Было замечено, что SoapUI не всегда корректно отрабатывает ошибки RestAPI.

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

SQL на уровне простых запросов до join. Теория реляционных БД желательно. Умение работать с любой РСУБД - MS SQL Developer, PL\SQL Developer. Второй даже поддерживает Test Runner для простых проверок;

Понимание клиент-серверной архитектуры и OSI на базовом уровне.

Архитектура

Встречается различный подход к документации на проектах. Кто-то требует документировать свою работу, кто-то работает по гибким методологиям и не ставит составление документации в приоритет. В общем, документация может быть, а может и не быть. И если вы не уточнили про наличие оной на собеседовании, то не удивляйтесь. Найдите сотрудника (PM, Тимлид, Техлид), который может обрисовать технологический стек и постарайтесь накидать для себя схему архитектуры сами. Потом, показывая картинку, легче понимать передвижение потоков данных и разговаривать с остальными членами команды на одном языке.


Пример состава тестового контура:

Шина данных. Очень часто в корпоративном секторе используется какой-то сервис очередей - tibco, kafka, RabbitMQ.

Ядро антифрод системы (+ web интерфейс к ней для настройки политик).

БД с данными транзакций, клиентов и другими, для корректных расчетов системы антифрод и применения политик скоринга.

Остальные смежные системы, требуемые для тестирования

Смежные системы общаются с шиной посредством коннекторов. Для каждого коннектора на шине пишется отдельный сервис, который конвертирует данные из формата, понятного системе-источнику, в формат понятный шине. Чаще всего это xml.

После этого документ помещается в очередь, из которой шина отправляет данные в систему-приемник. В нашем частном случае это была антифрод-система.

Для приема и корректной обработки данных из каждой системы-источника на стороне сервера антифрод пишется отдельный микросервис. Микросервисы выполняют атомарные функции доставки данных в ядро и передачу скоринговых баллов из ядра с вердиктом антифрода обратно в шину. Также могу валидировать входящие и исходящие данные в соответствии с ТЗ. При этом результаты опционально, по согласованию с заказчиком, логируются в базу данных для последующего анализа.

Процессы тестирования

Процессы тестирования делятся на два вида - отдельно тестирование нового микросервиса и end-2-end тестирование. Каждый из этих видов включает несколько этапов со стороны команды тестирования.

Тестирование нового микросервиса включает в себя следующие этапы:

Анализ технического задания на микросервис (разрабатывается заказчиком совместно с аналитиком);

Декомпозиция требований и составление матрицы соответствия требований;

Написание тест-плана для согласования с заказчиком. Можно найти шаблон в интернет-пространстве, если такового не имеется в наличие;

Написание тест-кейсов согласно матрице. Используется любая система управления тестированием. В корпоративном секторе сейчас распространена TFS(Azure DevOps Server)

Собственно, прохождение тест-кейсов и заведение дефектов;

Отчетность по результатам тестирования - протоколы, артефакты и т.п. (опционально по согласованию с заказчиком)

В корпоративном секторе роль заказчика часто принадлежит внутреннему бизнес-подразделению и лицом принимающим решение со стороны бизнеса является его руководитель. Он же ставит бизнес-задачу на разработку интеграционного взаимодействия. Например, руководитель департамента МСБ (малый-средний бизнес). Тестовые данные в данном случае могут предоставлять сотрудники подразделения-заказчика.

Бизнес-задачи для системы антифрод может звучать так:

“Требуется, чтобы все платежи от юридических лиц проверялись в системе и отправлялись на ручную проверку\блокировались при значении скорингового балла более 60”.

“Требуется блокировать все запросы от ИП с просрочкой более 1 месяца”

End-2-end тестирование отличается тем, что к обычному процессу добавляется этап согласования тест-плана не только с заказчиком, но и с командой тестирования сервиса-источника. А также в процессе прохождения тест-кейсов все тестовые данные(запросы) генерируются ролями в системах-источниках. У каждой информационной банковской системы есть своя команда(внутренняя или внешний интегратор), разрабатывающая новые функции, и также имеет своих разработчиков и тестировщиков. E2E проводится совместно с ними.

Например: Тестировщик Диасофт от роли “Оператор” отправляет платеж по карте мир от одного юрлица к другому.


Команда взаимодействия

Тестировщики системы взаимодействуют в работе со следующими ключевыми сотрудниками:

Менеджер технологической инфраструктуры (возможно DevOps)

Аналитик со стороны разработки

Аналитик со стороны заказчика (опционально)

Разработчик со стороны сервиса-источника

Разработчик со стороны антифрод

Разработчик со стороны шины

Автотестировщик, Архитектор, Поддержка, Скрам-мастер и прочие невиданные звери - опционально, но скорее нет.

Набор ролей соответствует стандартному набору ролей в жизненном цикле ПО по любой методологии.

Базовый сценарий тестирования

После того, как заказчик прислал требования и набор политик для антифрод, аналитики или служба поддержки настраивают их на тестовом контуре в веб-интерфейсе.

В обязанности команды тестирования входит подготовка тестовых данных согласно требованиям и политикам, и создание проекта SoapUI для пересылки этих данных в соответствующий микросервис. После написания каждого нового микросервиса заново выгружается wsdl файл, который потом грузится в SoapUI.

Под тестовыми данными я подразумеваю xml-файлы, набор полей в которых соответствовал требованиям, при которых политики срабатывали корректно или отдавали соответствующий код ответа, согласно документации.

Пример: При осуществлении платежа от ИП Васечкин к ИП Петечкину платеж должен быть не более 1 млн.руб. Если больше, то антифрод возвращает ответ DECLINE и транзакция блокируется.

Код ответа может меняться, так же, как и состав политик.

Позитивные сценарии.

Для всех позитивных сценариев составляются xml с нужными данными по клиенту(id, наименование, инн) и нужной суммой в теле запроса. Запрос отправляется в микросервис и в SoapUI создаются ассерты для проверки корректности ответа.

Привел его для примера. Тестировщику желательно знать ключевые элементы схемы XML

Негативные сценарии.

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

После отправки запроса в микросервис, и проверки корректности ответа с помощью ассертов также надо проверить корректность логирования в базе антифрода и отправку ответа в шину.

Логирование работы каждого сервиса всегда происходит в отдельную таблицу БД антифрода, если заказчик не указал иное. Проверка происходит ручным составлением запроса в БД или добавлением проверки данных из БД с помощью SoapUI - JDBC request.

интерфейс создания подключения к БД в Postman

интерфейс создания подключения к БД в Postman

Вывод

Антифрод-система в банках сейчас является одним из важнейших модулей в инфраструктуре и некорректная работа данной системы может сильно повлиять на надежность и безопасность обслуживания. Тестирование данной системы также имеет высокий приоритет для департамента финансового мониторинга. Спецификой работы над таким проектом является глубокое погружение команды тестирования в предметную область банковских операций. Взаимодействие с множеством сотрудников различных систем-источников требуют высоких аналитических навыков, ведь время погружение в задачу и предметную область диктуется релизными рамками.

Гид по профессии тестировщик: чем занимается специалист в сфере QA, сколько з. главное изображение

Позиция тестировщика считается одним из самых простых способов быстро войти в отрасль информационных технологий. Ходят слухи, что эту профессию легко освоить, работа у тестировщика — не бей лежачего, да и платят специалисту по тестированию программного обеспечения почти как программисту. Насколько эта информация достоверна? Давайте разбираться.

Кто такой тестировщик, за что отвечает и чем занимается

Тестировщик программного обеспечения планирует и выполняет тестирование приложений, отлаживает код, улучшает юзабилити программ. Часто к названию профессии добавляют латинские буквы q и a: qa тестировщик. Также употребляют название qa-инженер. В латинских буквах спрятана суть деятельности тестировщика. Подробности ниже.

За что отвечает тестировщик

QA произошло от английских слов quality assurance — обеспечение качества. Это часть разработки, которая управляет качеством продукта. QA — широкое понятие, а работа над обеспечением качества начинается задолго до написания первой строки кода будущего приложения. В идеальном мире инженер по качеству работает над продуктом если не на этапе генерации идей, то на этапе исследования рынка и изучения потребностей целевой аудитории.

Хекслет для начинающих: Попробовать обучение на Хекслете вы можете на Подготовительном курсе по основам Python. Теория и практика в браузере, вебинары, лайвкодинг, помощь наставника

В широкое понятие QA входит ещё одно направление деятельности: QC, quality control или контроль качества. Инженеры QC контролируют продукт на этапе разработки и поддержки. Тестирование программного обеспечения — один из инструментов контроля качества. То есть тестировщик проверяет приложение в рамках мероприятий по контролю качества (QC), которые входят в комплекс работ по обеспечению качества (QA).

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

Чем занимается тестировщик

Есть ручное и автоматизированное тестирование ПО. Соответственно, специалисты по ручному тестированию проверяют приложения вручную, а специалисты по автоматизированному тестированию работают с помощью программ.

Ручной тестировщик по сути вручную имитирует действия пользователя приложения. Специалист убеждается, что программа работает как ожидается в разных сценариях взаимодействия. Ручное тестирование иногда называют поведенческим или тестированием методом чёрного ящика. Но автоматические тесты тоже чаще всего проводятся с использованием стратегии чёрного ящика.

Стратегией чёрного ящика называется подход, при котором объект тестируется без использования знаний о его внутреннем устройстве.

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

Ручное тестирование — самый простой способ оценки качества приложения. Тестировать приложение вручную — «дорогая» операция, так как скорость и точность проверок ограничена возможностями тестировщиков.

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

Вот примерное описание работы эксперта по автоматизированному тестированию. В первую очередь он выбирает тест-кейсы или функции приложения, которые нужно проверить. Обычно для автотестов выбирают критичные для работы ПО функции, например, обработку платежей, сохранение пользовательских данных. Автотестирование подходит, когда тесты повторяются неоднократно или для проверки функции приложения нужно использовать большие объёмы данных.

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

Автоматизация тестов экономит ресурсы организации. Она позволяет с минимальными усилиями повторно тестировать приложения, требует меньше времени по сравнению с ручными тестами, сокращает количество ошибок.

Промежуточный итог: тестировщики контролируют качество программного обеспечения. Эта деятельность входит в комплекс работ по QA — обеспечению качества приложений. Тестирование бывает ручным и автоматизированным. Ручное тестирование предполагает проверку приложений вручную, а для автоматических тестов специалисты используют программы.

Работа тестировщиком: где работают QA-инженеры, сколько зарабатывают, какие вакансии есть на рынке

Тестировщики трудятся в командах, которые занимаются разработкой программного обеспечения. Это скорее средние и крупные компании, которые делают собственный продукт или работают по модели аутсорсинга.

QA-инженеров и QC-тестировщиков часто привлекают команды, которые используют DevOps. В таких командах разработка, тестирование и поддержка ПО выполняется циклически с использованием подходов Agile или Scrum.

Сколько зарабатывают тестировщики

По данным QA-инженера Антона Якутовича, на рынке есть несколько уровней тестировщиков: новички, специалисты среднего уровня, опытные специалисты и эксперты по автоматизации тестирования. Зарплаты на каждом уровне отличаются от предыдущего примерно в 1,5 раза.

Большая часть вакансий открыта в Москве и Санкт-Петербурге, но такие специалисты требуются и в других регионах. Например, в Новосибирской области открыто 188 вакансии по тестированию, в Татарстане — 193 вакансий, в Свердловской области — 185 вакансий.

Как стать тестировщиком: что надо знать и где учиться

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

Что должен знать и уметь тестировщик, какие софт-скилы нужны этому специалисту

В первую очередь специалист должен изучить основы тестирования. Классификация тестирования, методы и инструменты, создание сценариев тестирования, — вот базовый набор знаний, с которого будущие QA-тестеры начинают знакомство с профессией.

Тестировщик должен уметь работать с командной строкой, знать браузеры и инструменты разработчиков. Также понадобится умение работать с инструментами автоматического тестирования, например, HP-UFT (бывший QTP), Selenium, Sahi и так далее.

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

Где учиться тестированию

Профессии «Тестировщик» на Хекслете пока нет. Тем не менее у нас есть полезные для будущих тестировщиков курсы и интенсивы. Вот некоторые из них:

Также вы можете посмотреть программы обучения в других школах. Например, курсы для будущих специалистов в области QA есть в «Тинькофф Образование», «Нетологии», GeekBrains, Skillbox и в других русскоязычных школах. А если вы владеете английским языком, можете пройти курсы на известных англоязычных площадках, включая Udacity, edX, Udemy, Coursera и так далее.

Промежуточный итог: чтобы работать тестировщиком, нужны специальные знания, включая основы тестирования, основы программирования, системы контроля версий, инструменты автоматизации и так далее. Часть знаний будущие тестировщики могут получить на Хекслете.

Профессия глазами профессионалов: комментарии экспертов о работе тестировщиков, перспективах и обучении

Мы обратились к опытным специалистам в сфере QA, чтобы узнать о нюансах профессии тестировщик. Они ответили на несколько вопросов о профессии.

Константин Виноградов: после курсов программистов можно смело становиться тестировщиком

Виноградов

Дмитрий Дементий: Чем работа тестировщика отличается от работы программиста? И что есть общего в работе тестировщика и программиста?

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

Конечно, есть отдельные специализации, такие, как специалист по автоматизации тестирования (test automation engineer) или разработчик в тестировании (software development engineer in tests), чья работа почти идентична работе программиста. Она предполагает написание кода автоматических тестов и тестовых фреймворков.

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

Валидация продукта требует от тестировщика достаточно большого кругозора, так как приходится смотреть на продукт глазами пользователя, понимать его потребности. Надо уметь «быть пользователем» и знать его потребности, что непросто, если речь идет о специализированных решениях. Надо знать отраслевые стандарты, которым должно соответствовать решение, и уметь это соответствие проверить. Надо уметь находить способы тестирования совместимости с конкурентными решениями.

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

Еще раз повторюсь: мы не рассматриваем автоматизаторов и разработчиков в тестировании, потому что они, на мой взгляд, всё же разработчики, а не тестировщики.

Д. Д.: Кем проще стать: разработчиком или тестировщиком?

К. В.: Тестировщиком. Но не потому, что им быть проще. Просто порог входа ниже. Карьера разработчика начинается с позиции junior software developer, которая требует наличия минимальных знаний: язык программирования, основные алгоритмов и структур данных, знакомство с фреймворками и так далее. Чтобы стать джуном, ты уже должен быть разработчиком.

Карьера тестировщика начинается с уровня специалиста по ручному тестированию (manual testing): есть описание тестов, делай руками, вноси результаты в отчет. Очевидно, что начинать во втором случае проще.

Д. Д.: С финансовой точки зрения к чему выгоднее стремиться: к позиции тестировщика или программиста?

К. В.: С финансовой — к позиции программиста. Вот только смотри пункт про образ мышления. Есть мнение, что тот, кто рожден быть хорошим тестировщиком, будет паршивым программистом. И наоборот.

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

Д. Д.: Чтобы проверять написанные программистами приложения, тестировщик должен разбираться в коде лучше программистов. Этот тезис верный или нет?

К. В.: Это очень сильно зависит от подхода к тестированию в конкретной компании. Часто бывают случаи, что тестировщику вообще не приходится заглядывать в код. Особенно это может касаться различных embedded решений или прошивок устройств. Но знать, как разрабатывается продукт, как он работает, и почему сделано именно так, тестировщик должен.

Д. Д.: Можно ли рассматривать позицию тестировщика как один из простых способов войти в IT?

Д. Д.: Какими инструментами пользуются тестировщики: окружение, редакторы и IDE, библиотеки и фреймворки?

Все зависит от продуктового стека и того, чем автоматизируется тестирование. У меня:

  • Linux/macos;
  • VScode;
  • Pytest;
  • Jenkins;
  • Gitlab.

Д. Д.: Где можно научиться тестировать ПО? Можно ли стать тестировщиком после курсов программирования?

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

Станислав Урюпин: тестированию можно научиться только на практике

alt_text

Станислав Урюпин, QA-инженер, руководитель волонтёрского образовательного проекта Sciberia

Дмитрий Дементий: Чем работа тестировщика отличается от работы программиста? И что есть общего в работе тестировщика и программиста?

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

Д. Д.: Кем проще стать: разработчиком или тестировщиком?

С. У.: Начать карьеру в IT проще тестировщиком, чем разработчиком. Но за последние годы сложность разрабатываемых программ и предъявляемых требований сильно возросли. Данные изменения не могли не отразиться на работе тестировщика. В связи с этим повысился порог вхождения в профессию.

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

Д. Д.: С финансовой точки зрения к чему выгоднее стремиться: к позиции тестировщика или программиста?

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

Д. Д.: Чтобы проверять написанные программистами приложения, тестировщик должен разбираться в коде лучше программистов. Этот тезис верный или нет?

С. У.: Этот тезис не является верным. Лучше самих программистов в коде не может и не должен разбираться кто-либо ещё. Тестировщики работают чаще всего по стратегии черного ящика, когда непосредственный доступ к коду закрыт для анализа. Зато тестировщику доступны различные способы и инструменты для определения работоспособности программ.

Д. Д.: Можно ли рассматривать позицию тестировщика как один из простых способов войти в IT?

С. У.: Можно, но лишь отчасти. Всё зависит от конкретных целей. Например, часто новички работу в тестировании рассматривают как промежуточный этап перед переходом в разработку. Тестирование и разработка — это разные области деятельности. В каждой из них найдутся характерные особенности, без которых продуктивная работа невозможна. Потому неизбежно придётся тратить ресурсы на погружение в предметную область.

Если цель — пройти в разработчики или иные направления работы в IT, такие, как DevOps или аналитика, стоит отдельно изучать эти направления. Но получится ли это делать без падения продуктивности работы в тестировании, вопрос открытый.

Д. Д.: Какими инструментами пользуются тестировщики: окружение, редакторы и IDE, библиотеки и фреймворки?

С. У.: Область тестирования обширна, и в ней много направлений, в которых найдутся свои инструменты. Есть инструменты, которыми пользуются тестировщики независимо от направления. Например, cистемы управления тестированием или системы отслеживания ошибок.

Д. Д.: Где можно научиться тестировать ПО? Можно ли стать тестировщиком после курсов программирования?

С. У.: Тестированию, как и многому другому, можно научиться только на практике. Если нет опыта, с которым можно начать карьеру, стоит изучить теорию и воспользоваться готовыми решениями для практики. Например, выбрать сайт или мобильное приложение и попробовать научиться составлять тест-кейсы или изучить на предмет возможных ошибок.

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

Заключение: работодателям нужны тестировщики, а соискателям нужно учиться и практиковаться

Тестировщик — не человек с улицы, а квалифицированный специалист, который должен много знать и уметь, постоянно практиковаться и развиваться. Работодатели готовы платить достойные зарплаты специалистам по автоматизированному тестированию. Чтобы стать тестировщиком, нужно учиться самостоятельно или на курсах. По мнению экспертов, позицию тестировщика можно считать одним из простых способов войти в отрасль информационных технологий.

Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях

От банковского приложения пользователи ждут высокой безопасности и корректной работы в первую очередь. Ведь именно ему мы доверяем сокровенное — работу с нашими деньгами. Популярность мобильных банкингов, а с ними и нагрузка на приложения банков растёт. По оценкам Statista, в 2020 году число их пользователей во всём мире достигло 1,9 миллиардов человек, а к 2024 оно вырастет до 2,5 миллиардов. Ещё один важный факт: банковские приложения работают с конфиденциальными данными, а значит, представляют собой мишень для кибератак. По данным отчёта “VMware Carbon Black”, только за три месяца 2020 года (февраль, март, апрель) число атак на финансовый сектор выросло на 238%.

Очевидно, что банки крайне заинтересованы в стабильной и корректной работе своих сервисов. А как можно проверить своё приложение и избежать багов и угроз? Наш ответ: тестировать! Тестирование поможет обеспечить плавную и надёжную работу приложения и проверить защищённость его данных.

Мы в Surf более 10 лет работаем с финтехом, фудтехом, ecommerce и создаём приложения, которыми пользуются миллионы. Среди наших клиентов-банков — Росбанк, Промсвязьбанк, банк Зенит.

💼 Рассказываем об этом в наших кейсах.

📱 Недавно мы запустили канал в Telegram, в котором делимся своим продуктовым видением. Подписывайтесь!

В этой статье мы расскажем, как тестируем банковские приложения и какие лучшие практики сформировали за 10 лет работы с крупными банками.

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

Приложение интегрировано с множеством сторонних систем. Например, чтобы предзаполнить ваши данные для кредитной заявки, мобильное приложение, как правило, берёт данные из внутренних справочных систем банка. А чтобы сделать быстрый перевод денег через СБП, нужно сделать запрос к внешней базе данных на список всех банков получателя и подтвердить его данные.

Всё это усложняет работу QA инженера, так как ему нужно чётко представлять и понимать, как работает каждая функция, из какой системы приходит ответ на каждый запрос, как обрабатывается информация. И конечно, проверить все возможные пользовательские сценарии, связанные с запросами к этим системам.

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

Приведём простой пример из проекта с банком Зенит: вот у нас есть экран подтверждения операции при помощи SMS. Код из SMS может подставляться полностью автоматически, в этом случае пользователь не совершает никаких действий, даже не подтверждает операцию. Это удобно для пользователя, но не удовлетворяет требованиям безопасности.

Мы предложили гибридное решение. Если код подставляется из SMS автоматически, пользователю нужно подтвердить его кнопкой. Если пользователь вводит код вручную, дополнительных подтверждений не нужно, кнопку подтверждения мы от него скрываем, а код сразу же отправляется. Таким решением мы удовлетворили требования службы безопасности банка и сохранили интерактивный элемент для удобства пользователей. А задачу специалиста по тестированию усложнили: ведь ему нужно проверить оба сценария.

Функциональность банковских приложений постоянно растёт и усложняется. Только-только все банки внедрили СБП, как нужно добавлять новые возможности вроде me2me. Банки гонятся одновременно за лидерами отрасли, растущими потребностями пользователей и меняющимся законодательством. Поэтому приложения регулярно обновляются и расширяются, а вместе с ними и число задач для тестирования.

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

Мы не будем перечислять тут все возможные виды тестирования. Введём только пару понятий, которые понадобятся нам дальше.

Итак, тестирование бывает:

  • ручное — оно проводится без дополнительных программных средств, собственно, «вручную»;
  • автоматизированное — в нём используются программные средства.

И для тестирования банковского приложения не обойтись без обоих видов.

Тестирование банковского приложения (да и любого другого) всегда начинается с ручных проверок. Все фичи мы сперва проверяем руками и только после ручного тестирования можно переходить к автоматизации. Автоматизация проверок в приложении в основном делается для так называемого регрессионного тестирования.

Регрессионное тестирование — это повторное выполнение тестов, которое помогает проверить, что ранее разработанное и протестированное программное обеспечение корректно работает после изменения.

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

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

Постепенно проект достигнет точки, когда тестирование проводится по правилу Парето: вы проводите те 20% важных тестов, где высока вероятность найти 80% багов. Поэтому в долгосрочных проектах не обойтись без тестов, которые с меньшими затратами времени покроют бОльшую часть приложения — автоматизированных.

Преимущества автотестов

  • Они отлично справляются со сложной логикой и повторяющимися действиями, которых обычно много в банковских приложениях.
  • Способны обеспечить качество и скорость тестирования, которые невозможны при ручном тестировании.
  • Не зависят от численности команды QA, выполняются быстро и регулярно. Если добавить в команду одного человека, который будет писать автотесты, покрытие проекта тестами увеличится в разы.

Но есть и некоторые нюансы. На сопровождение автотестов каждый год уходит около 30% времени, относительно потраченного на их написание. Арифметика такая: чтобы покрыть одну фичу автотестами, требуется 100 часов. Затем на сопровождение этого теста будет уходить 2,5 часа в месяц. Но это касается только отлаженных фич. Если происходят серьезные изменения, автотесты придётся полностью актуализировать и затраты времени возрастут.

Отдельно остановимся на автотестах для приложений, разработанных с использованием кроссплатформенной технологии Flutter, так как спрос на неё растёт. А так как технология относительно новая — 2017 года — процесс тестирования вызывает много вопросов.

Мы реализовали на Flutter проекты для двух крупных российских банков и вывели для себя некоторые правила.

Flutter предоставляет возможность писать нативные автотесты на Dart и покрывает все необходимые виды тестов. Во Flutter доступны несколько видов автотестов и они решают разные задачи:

— UNIT-тесты. С их помощью проверяют конкретную часть системы, например, можно убедиться, что контроллер компонента устанавливает нужное состояние. Здесь не нужно эмулировать работы приложения. В Surf UNIT-тесты пишут разработчики, так как они больше вовлечены в описание внутренней логики приложения.

А QA-инженеры пишут тесты двух других типов: виджет-тесты и E2E тесты. Они гораздо больше связаны с работой готового приложения и проверкой пользовательских сценариев.

— Виджет-тесты находятся уровнем выше UNIT-тестов. Они позволяют эмулировать виджеты и выполнять с их помощью необходимые тесты. Для Flutter это особенно актуально, ведь приложения на Flutter полностью состоят из виджетов. Для виджет тестов мы эмулируем виджеты различных типов и проверяем, как они работают. Это может быть целый экран или отдельные его элементы: поля для ввода данных, кнопки и т.д.

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

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

— E2E (End-to-End) тесты проверяют работу приложения целиком и симуляцию пользовательских действий (свайпы, нажатие кнопок, заполнение форм) в реальной инфраструктуре с реальными сервисами, API и всем остальным. На Flutter такие тесты называются интеграционными. Такие тесты проводят перед каждой сборкой и перед релизом — времени они занимают немало, но позволяют тщательно проверить качество приложения.

Для одного из наших банков-клиентов мы реализовали в приложении автотесты, которые покрывают 65% требований, и инфраструктуру для них, чтобы банк мог развивать их и тестировать приложение сам.

Нельзя не упомянуть об еще одном виде тестирования, очень важном именно для приложений банков, — это пентесты.

Пентест (penetration test, пенетрейшн тест) — это тестирование на проникновение и безопасность, анализ системы на наличие уязвимостей. Оценивает безопасность системы, моделируя атаку злоумышленников.

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

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

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

Разработка приложения у нас начинается с того, что команда QA-инженеров проверяет технические требования на полноту, точность и последовательность. Одновременно мы проверяем дизайн, чтобы убедиться, что он учитывает все состояния приложения и не противоречит требованиям. Как известно, чем раньше обнаружен баг, тем меньше затрат требуется, чтобы его найти и пофиксить.

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

У каждого из этих видов проверок есть своя структура, при этом она единая для всех сценариев или для всех чек-листов. Такой унифицированный подход помогает ускорить и усовершенствовать тестирование, а также не упустить ничего из важных моментов. А ещё так проще знакомить новых сотрудников с проектом. Даже когда специалист подключается на отдельных этапах проекта или переходит с проекта на проект, он понимает, что уже написано и как должна выглядеть реализация.

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

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

Чтобы тестирование проходило быстро, безболезненно и охватывало максимум, мы вывели для себя несколько лучших практик:

Автор статьи

Куприянов Денис Юрьевич

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

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