28.10.2024
Стефан Антов, QA Automation Team Lead, е двигателят зад тест автоматизацията в TINQIN. С дългогодишен опит в тестването и силен фокус върху изграждането на скалируеми системи, той създава стратегии за автоматизация, които поставят бизнес ефекта на първо място. От frameworks, базирани на Selenium, до персонализирани слоеве за валидация по API и frontend, екипът на Стефан подхожда към автоматизацията с необходимата сериозност. Неговата цел е ясна: да даде на всеки QA инженер увереност, скорост и прецизност при доставянето на качествен софтуер.
Когато се присъединих към TINQIN преди няколко години, реално стартирахме от нулата по отношение на автоматизацията на тестовете. Бях първият QA automation инженер, а визията беше ясна: искаме автоматизацията да стане естествена част от delivery процесите, а не странична задача. Това, разбира се, не се случва с няколко скрипта в Git. Изисква се цялостен подход, който включва изграждане на доверие в екипите, обяснение на ползите и адаптиране на tooling спрямо реалната нужда на продукта.
Днес автоматизацията вече е вкоренена, като неотменна част от работата ни. QA екипът расте, портфолиото със софтуерни проекти също. И моята роля вече не е само техническа. От мен се очаква да мисля стратегически, да подготвям хората, да структурирам процесите, така че автоматизацията да помага, а не да пречи.
Истината е, че не гоня модата. Избирам технологии, които пасват на реалностите в компанията и на пазара. Основен принцип при нас е тестовете да говорят на същия език като приложението. Например, ако backend-ът е на Java, няма смисъл автоматизацията да е на Python. Става по-бавно, по-сложно и по-рисково.
Selenium си остава основа за UI автоматизацията. Да, не е ново, но е battle-tested. За REST API тестване ползваме REST Assured, а за orchestration, TestNG. Обичаме да сме близо до стандартите, защото това ни дава достъп до по-голяма QA общност, по-добра документация и бързо решение на проблемите.
Избягваме „екзотични“ frameworks, освен ако нямаме реална причина. Преди да внедрим нещо, си задаваме въпроса: това ще ускори ли обратната връзка? Ще вдигне ли стабилността? Ще намали ли поддръжката?
Върви към задължителност. Просто е. Приложенията стават все по-сложни – microservices, мобилни клиенти с offline sync, ML модели, които взимат решения. Ръчно тестване вече не може да покрие това без сериозен риск или огромни разходи.
Автоматизацията вече не е в категория „nice to have“. Но подхода към нея трябва да бъде интелигентен. Не просто записване на действия като кликвания, а стабилна архитектура, която валидира бизнес логика през API, UI и данни. Неща като контекстно осъзнати проверки, data-driven сценарии и добра поддръжка в CI/CD са задължителни.
Първо и основно, ние търсим хора, които искат да растат. QA automation екипите не са подходящи за хора, които търсят комфорт и рутинни задачи. Технологиите се менят, продуктите също. В нашата област бързо изоставаш, ако не учиш бързо и не прилагаш най-новото в истински софтуерни решения.
На второ място даваме приоритет на хора, които могат да комуникират добре, както с колеги инженери, така и с мениджмънт роли. Работим в крос-функционални екипи. QA не е изолиран – всеки ден се говори с софтуерни инженери и продуктови мениджъри, дизайн и т.н. Ако не можеш да обясниш ясно един проблем, бъг, или риск, ти блокираш целия процес.
Трето и последно, предпочитаме прагматични инженери. Не ни трябват хора, които искат да започнат с написване на фреймуърк от нулата, само защото могат. Търсим хора, които могат да адаптират реално работещо решение според процеса, а не обратното. Напоследък имаме много продуктови решения, които изграждаме от нулата, но е невъзможно всеки нов QA инженер да работи по такъв проект като първо задание.
Ако някой гори за автоматизацията, има интерес към tooling и разбира защо тестваме, останалото можем да го научим заедно.
Освен QA като част от ежедневната разработка, TINQIN разполага с специализиран QA Център, който предоставя както вградени услуги за проектови или продуктови екипи, така и а-ла-карт QA услуги за клиенти, които модернизират остарели уеб системи или искат външна валидация на код, създаден от други доставчици, включително AI-генериран код (Copilot). Това включва неща като изграждане на цялостна automation стратегия, анализ на регресии с помощта на Selenium, внедряване на QA tooling в съществуващи DevOps потоци и провеждане на независими code audits. QA Центърът е правилното място, ако търсите гаранция за качество преди рилийз или искате да сравните вътрешния си прогрес с най-добрите практики
