QA в госсекторе: цифровые технологии, за которые не стыдно

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

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

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

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

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

Одна из самых интересных задач QA, с которой мы в Цифроматике постоянно работаем, — это контроль качества для госсектора. Это те самые госуслуги, межведомственный электронный документооборот, многофункциональные центры «Мои документы» и так далее. Их можно любить или ненавидеть, но они определенно делают жизнь миллионов человек удобнее.

Любой, кто сталкивался с европейскими госуслугами, скажет вам, что российские сервисы — просто феррари в этом автопарке машин на паровом генераторе. Как и в банковском секторе, это связано с тем, что в России эти технологии начали развиваться позже, но зато сразу на самых современных технологиях, в то время как другие страны предпочитали не менять то, что и так работает (даже если работает неудобно и медленно).

Есть ли разница с точки зрения обеспечения качества для крупной федеральной информационной системы (скажем, дисконтной системы федеральной сети супермаркетов) и для государственной системы — той же сети МФЦ? По масштабности они похожи, и там, и там — миллионы пользователей. А вот ответственность, безусловно, разная — потерять баллы в «Пятерочке» или пенсионные баллы в госуслугах.

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

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

Если вы не айтишник, то дальше можете не читать.

Итак, есть QA-процессы уникальные только для государственных проектов. Например, интеграции систем межведомственного электронного взаимодействия (СМЭВ) или авторизация через ЕСИА. В таких проектах большая часть внешних интеграций относительно сбора данных проходит через СМЭВ-шину, для которой настраиваются специальные тестовые среды, способные обеспечить полный цикл взаимодействия.

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

Как эти особенности видны изнутри? Разнообразие архитектур, стека, требований к высоконагруженным системам и реализуемых на проекте задач подразумевает наличие широкого спектра экспертиз для QA-инженера. Если вам кажется, что это страшно, то можем сказать, что скорее страшно интересно. Мы в Цифроматике отказались от разделения ручного и автоматического тестирования, все наши QA-специалисты — фулстек, которые знают и аналитику, и автотесты, и девопс, а потому могут обеспечить качество на всех этапах.

Для тех, кто хочет «войти в айти», мы собрали стек, без которого не обойтись при устройстве в отдел QA в нашей компании в 2023 году:

• Знание принципов и методик тестирования.
• Знание основ администрирования Windows и систем на базе Linux.
• Понимание общих принципов разработки ПО.
• Понимание принципов клиент-серверного взаимодействия.
• Опыт использования систем баг-трекинга.
• Базовое понимание теории тестирования и умение уместно применять ее.
• SQL, опыт написания SQL-запросов средней сложности (join, group by, having, агрегирующие операторы sum, count, приведение типов, понимание работы исполняемых процедур), работа с различными СУБД.
• REST API, понимание клиент-серверной архитектуры, работы интеграций.
• Git, GitLab CI/CD, понимание структуры, организации, настроек.
• Postman на уровне создания коллекций, покрывающих конкретную бизнес-логику.
• Apache JMeter, скриптинг (выстраивание логики взаимодействия операторов).
• Базовые навыки программирования — иметь представление о типах данных, основных операторах, как работают условия, циклы, общие представления об алгоритмах.