Публикувано на: 5 октомври, 2022*Текстът е предоставен от SEEBURGER
Business Cloud Apps QA е отбор, специализиран в GUI тестване и пряко работещ с Development екипите, с цел осигуряване на максимално качество на продукта.
Екипът ни е сформиран преди повече от 15 години като немалко колеги са част от него от ден първи.
В стаята на QA-ите цар е смехът. Дали заради някой бъг, дали заради някоя интересна имплементация – настроението в нашата стая винаги е позитивно и денят ни е лишен от скука.
В екипа сме приятели и често излизаме за по бира след работа. Именно това ни прави стабилен екип с дългогодишни членове.
Как минава един ден като QA Automation Developer в Business Apps QA екипа на SEEBURGER?
Отварям очи и навън е прекрасен ден… първа стъпка, разбира се – кафе. Мисля, че няма IT специалист, който да не започва деня си с голяма доза кофеин. Второ – инвестигиране на нощен билд: най-вълнуващата част от деня. Не се знае каква изненада ще откриеш оставена от програмистите. Чувства се като „treasure hunt“ – голяма забава. Трета стъпка „малко сълзи по падналите тестове“. Четвърто – подготвяне на бъг репорт. Следващата и най-милата част от деня – „развеселяване на някой DEV“ или по друг начин казано – разговор последван от отваряне на заветния бъг. Шеста стъпка – създаване на допълнителни автоматизирани тестови сценарии, които съдържат в себе си и имплементиране на необходимите за определените ни цели помощни тестови функционалности.
И сега малко детайли за различните етапи от деня ни:
Инвестигиране на нощния билд: това определено е важен момент от ежедневието на един QA Automation Developer. Анализирането на състоянието на голямото количество автоматизирани тестове, които се изпълняват всяка нощ, е в основата на работата ни. Разнообразието от възможни проблеми и препятствия, които може да бъдат срещнати в различните фейлнали тестове, прави работата ни вълнуваща, и определено доста далеч от еднообразна.
„Малко сълзи по падналите тестове“: дали ще са малко или повече зависи от деня, но по-важното в случая е, че това е моментът, в който трябва да вземем експертно решение и да определим каква е причината за неуспешното изпълнение на тестването. То по своята същност определя сериозността и отговорността на работата, която вършат хората, изпълняващи тази роля в разработката на даден продукт. За решаването на тези проблеми се изисква аналитично мислене, умения за решаване на проблеми в стресови ситуации и фокус към детайла, които са и основните качества на един добър QA Automation Developer.
„Развеселяване на някой DEV“: хумористично казано и обвързано с всички стереотипи за взаимоотношенията между програмисти и тестери, това е моментът, в който съвместно с програмистите се локализира конкретния фрагмент код и конкретната промяна, предизвикали съответния проблем. Това е стъпката, в която се взема съвместно решение как и кога ще бъдат направени промените, и се финализира описанието на бъг-а в съответната платформа за менажиране на проекти.
Loading …
София
Най-интересният етап и най-вариращият по големина такъв е именно времето, което отделяме в писане на нови тестове с цел по-добър обхват на тестването (т.нар. coverage). Това е и частта, която е свързана с Developer думичката, съдържаща се в работната ни роля.
В този момент влизаме в обувките на програмисти, чиято цел е създаването на достатъчно добър тест проект, който да бъде достатъчно абстрактен, структуриран коректно и документиран изцяло. По това време от ежедневието обръщаме внимание на общата среда за създаване и поддържане на тестовите системи, които използваме. Също така това е и времето, когато допълваме с методи или коригираме/оптимизираме стари такива в общия ни UI Test framework – там са имплементирани всички необходими методи за интеракция с елементите на дадена Web страница. Този framework е създаден, поддържа се и се развива от екипа, като вътрешен много важен продукт-инструмент, чрез който работата е по-бърза, централизирана и предотвратяваща многократното повторение на редове код.
Тестваме или програмираме?
След като си обяснихме как минава един ден в моя екип смятам, че е правилният момент да си отговорим на основния въпрос, поставен в статията, а именно какво прави един QA Automation Developer: тества или програмира?
Ако все още има някой от вас, драги читатели, който не е успял да си отговори на този въпрос, ето моя поглед:
На въпроса „тестваме ли?“ – отговорът , разбира се, е „Да!“.
Проследяването на коректната работа на функционалностите на софтуера и осигуряването на начини за това проследяване, е именно тестването. Всекидневните ни опити да счупим всяка възможна част на прекрасния ни продукт или както ние си го наричаме „BIS-a“ (BIS: Business Integration Suite) смятам, че заслужават признанието, че сме тестери. Тестери на нервите на програмистите, на качеството на BIS-а и най-вече на джагите и билярда в панорамния последен етаж на офиса ни с гледка към Витоша.
А на въпроса „програмираме ли?“ – отговорът, противно на този на един програмист преди рилийз, е отново „Да!“.
Автоматизираното тестване изисква изграждането, поддържането и непрекъснатото разширяване на една тестова среда. Това изправя т.нар. „тестер“ пред задачата да пише код, да създава сложно свързани и заплетени алгоритми, осигуряващи последващо реализиране на тестови сценарии. А ако това не е програмиране, какво друго?
Така виждам аз работата си, по този начин виждам себе си и колегите си в Business Apps QA – като едни тестващи програмисти, спартанците на SEEBURGER.
