Я работаю в сфере обеспечения качества программного обеспечения с 2020 года — и за эти годы качество стало для меня не просто должностной обязанностью. Это ответственность, которую я беру на себя ежедневно: перед командой, продуктом и, в конечном итоге, конечным пользователем. Значительную часть своей карьеры я занимал должность руководителя отдела обеспечения качества в команде из 6-8 инженеров и был наставником для 8 стажеров, а также организовал и курировал программу стажировки для 10 студентов, изучающих обеспечение качества/тестирование. Я не просто проверял запросы на слияние — я создавал культуру: проводил индивидуальные встречи, обсуждал стратегии тестирования, помогал членам команды справляться со сложными сценариями и следил за тем, чтобы каждый член команды понимал не только «что тестировать», но и «почему это важно». Одним из структурных изменений, которые я внедрил, стала модель ответственности за функции: за каждую функцию релиза один назначенный инженер по обеспечению качества нес полную ответственность — от анализа требований и написания тестовых сценариев до выполнения первого прохода. Это позволило устранить разрозненность знаний, улучшить качество документации и значительно сократить количество случаев регрессионного сбоя, вызванных нечетким распределением ответственности. Я принимал окончательное решение о выпуске/отклонении релизов в производство. Это означало оценку покрытия тестами, проверку корректности критических путей, анализ известных рисков и утверждение готовности к выпуску перед менеджерами проектов и заинтересованными сторонами. Чтобы предотвратить узкие места и избежать динамики единой точки отказа, я ввел ротацию ответственности за релизы — каждый инженер по контролю качества по очереди брал на себя ответственность за релиз. Это повысило устойчивость всей команды и вовлеченность каждого в качество всего продукта, а не только в выполнение своих индивидуальных задач. Меня добавили во все каналы поддержки в качестве контактного лица по вопросам контроля качества для обратной связи по производственным процессам. Когда пользователи или команды поддержки сообщали о проблемах, я занимался их устранением: воспроизводил сценарий, оценивал серьезность и направлял соответствующих разработчиков к обсуждению. Я достаточно хорошо знал продукт, чтобы различать реальный дефект, крайний случай, неправильную конфигурацию и ошибку пользователя — и я четко доносил это как до технических, так и до нетехнических заинтересованных сторон. Каждую неделю я участвовал в совещаниях по статусу проекта, отчитываясь перед заинтересованными сторонами в структурированном формате: что команда QA выполнила, что находится в процессе и что запланировано. Четко, без лишних слов, с конкретными действиями. Что касается технической стороны, я являюсь соавтором автоматизированной системы тестирования, построенной на .NET, охватывающей как реализацию, так и текущее сопровождение автоматизированных наборов тестов. Я тестирую API с помощью Swagger, Postman, NUnit и RestSharp (автоматизированные тесты), а также тестирую пользовательский интерфейс как вручную, так и автоматизированными методами с использованием Selenium. Я также регулярно работаю с базами данных — пишу SQL-запросы и проверяю целостность данных в рамках сценариев тестирования бэкэнда. Я участвую в обязательных проверках планов тестирования для сложных функций — обеспечивая, чтобы до написания хотя бы одной строки тестового кода стратегия была обоснованной, а покрытие — хорошо продуманным.   Мне комфортно в условиях, где качество не является конечной точкой, а представляет собой общую ценность, заложенную в каждый спринт. Я умею одновременно работать с инженерами, менеджерами проектов и командами поддержки, не теряя при этом полезную информацию.