Всем привет! Меня зовут Найля, я инженер по обеспечению качества в Т-Банке. В поисках полезного материала часто слушаю доклады с личными кейсами и разборами инструментов. Это помогает увидеть проблемы глазами других и почерпнуть что-то полезное для себя и своего проекта. На весенней конференции Heisenbug выступал мой коллега Александр Бодня — тоже инженер по качеству. Его доклад показался мне интересным, и я захотела им поделиться. 

Сегодня в ИТ-сообществе все чаще говорят про T-shaped-специалистов — людей, обладающих глубокими знаниями в своей области и широким кругозором в смежных. Обычно этот подход обсуждается в контексте QA и Dev. А сейчас предлагаю посмотреть в другую сторону и обсудить интеграцию с SRE. 

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

Именно о такой интеграции рассказал Александр, делая акцент на том, как QA-подход может и должен применяться в задачах эксплуатации сервисов.

Всем привет! Меня зовут Найля, и я инженер по обеспечению качества в Т-Банке на одном из внутренних сервисов. Занимаюсь ручным и автоматизированным тестированием на проекте. Расскажу о том, как мы написали API-тесты с использованием фейков, что это такое и когда стоит отдать предпочтение им, а не мокам.

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