Публикувано на: 31 август, 2023*Текстът е предоставен от VSG Bulgaria
„Има ли как да автоматизираме тези репорти?“ – попита ме бизнес анализаторът. Нямах никаква представа какво да направя, но като човек, който изключително много разчита на аналитичното мислене, без грам колебание отговорих, че има как.
Казвам се Емил Бибиновски, QA Senior Manager & Vice President във VSG Bulgaria. Ние сме екип от опитни професионалисти, готови винаги да предоставят най-доброто решение на нашите клиенти и да разрешат и най-сложните проблеми. А проектът, по който работим вече доста години за един от нашите клиенти представлява софтуер за анализ на риска при теглене на кредити, или според колегите ни от САЩ – Loan Origination System. Ако се придържаме към модерния подход за изразяване, бих казал, че продуктът е космос. Изключително сериозен и сложен – с голям брой пластове на бизнес логика.
Когато започвах работа във VSG аз бях новият, млад амбициозен QA, готов да автоматизира всичко. Как обаче, автоматизираш нещо, за което няма написан нито един тест кейс? Така започна моето приключение, което продължава вече 6 години. Време, в което направихме качеството измеримо, а работата – добре разпределена между колегите.
Започнахме съвсем от 0 като документираме всяко нещо, което можем да намерим като спецификация, разделихме им системата на домейни и постепенно се сдобихме с колекция тест кейсове, достойни за похвала. Тя стана и основа за regression и smoke сесиите, които започнахме да правим.
Изградихме фреймуърк над Selenium, сменихме работното темпо с такова на още по-бързи обороти и започнахме да наваксваме. И точно когато ни стана спокойно, че сме описали всичко, автоматизирали сме го, се наложи да го преправяме, вследствие на редизайн. Тук искам да изразя специални благодарности на Владимир Кисьов. Влади, който не показа капка умора през целия този изключително тежък процес!
На един от най-големите ни релийзи имахме значителни промени по всички нива на проекта – почти основен редизайн, преминаване от .NET framework 4.6 към .NET 6. Пренаписахме front-end частта на проекта, която комбинираше различни технологии като преминахме на React с Typescript.
Мина regression-a и до голяма степен оправихме всичко намерено. Дойде време за release, който също мина гладко и имахме един спокоен месец. Случвало ли ви се е да ви стане много напрегнато, защото в проекта е съмнително спокойно? Хората, които са в бранша биха разбрали, сигурен съм 🙂
Точно тогава получих покана за разговор с дама от отдела за бизнес анализ и в този момент онова съмнително спокойствие свърши:
„Емил, имаме сериозен и негативен отзвук от няколко клиента, че репортите, които генерират, имат сериозни разминавания с истината!“.
В банковата система всичко се свежда до репорт. Като компания, която прави банков софтуер, поддържаме около 1600 различни видове репорти.
Как се генерира репорт? Банковия служител отива на страницата за репорти, избира името му и натиска Print. Какво става обаче на background?
За да верифицираме, че един репорт работи, трябва да прочетем и анализираме около 20 форми с над 30 полета, да имаме детайлна информация за всички сторнати процедури, back-end трансформации и front-end логика, които участват при генерирането му. Това доста често е около 3-4 страници pdf или xls.
Loading …
Пловдив
През цялата продължителност на разговора само се надявах да не ми зададе въпроса, който не исках да чувам, до момента, в който не го зададе – „има ли как да автоматизираме тези репорти?“
Разбира се, че има, как иначе ще се развиваме, ако не се предизвикваме.
Прехвърлих всякакви варианти – кой от кой по-труден – и накрая прозрях много просто решение: Какво прави manual QA-a, докато тества репорт? Проверява си input-a, прилага логика и верифицира output-a. Това е. Ако гарантираме, че входящите данни не са се променили, няма промени по бизнес логиката, то и репорта също не би трябвало да се е променил. Даваме гаранция, че той работи по очаквания начин.
Как да гарантираме входящата информация, при положение, че в нея влизат 8 форми, по 30 полета, част от които са дропдауни, радиобутони, мултиселекти и всичко, което може да ви дойде наум като уеб елементи? Пак обмисляхме варианта със Selenium и пак отговора беше същия. Да взимаме информация от базата данни и да я сравняваме някак? Не.
Както доста често се случва в живота извън работа, така и тук – отговорът беше пред очите ни. Нужен ни беше допълнителен “чифт очи”, не нашите, които да виждат, че няма промени и всичко е както трябва да бъде. След много главоблъскане стигнахме до Visual Testing.
Това е сравнително нов метод, който позволява “заснемане” на т.нар. Snapshots, който системата взима за основа и използва за всички бъдещи сравнения, и прави следваща проверка на ниво пиксели – pixel comparison. Т.е. всеки ден, някой вместо нас заснема целия input и ни казва, че той не се е променил. След това заснема и готовия репорт и ни казва, че той изглежда по стария начин!
Ето ги нашия “чифт очи”, които буквално виждат, че с еднакви входящи данни и без промяна на бизнес логиката, ние получаваме еднакакъв Output под формата на репорт! Voila!
Още има неща, които ме изненадват и тук ми направи впечатление, че сравнението намираше разлика от 1px. Разбира се, в настройките на фреймуърка има опция за толеранс. Възползвахме се максимално от предимствата на системата като включихме всички сложни гридове и таблици.
Премахнахме от тест кейс мениджмънт системата тест кейсовете, с които верифицираме колони в таблици и гридове. За първи път имахме опция да тестваме дизайн, без да използваме абстракция за уебелементи – такава, която използват UI testing frameworks.
В процеса на работа по visual testing-a покрихме голяма област от несъздадени тестове с изцяло нов леър, с което подобрихме проекта значително. Момент за благодарности, но този път към Денислав Димов – той прие много присърце изграждането на visual testing фреймуърка, който ползваме на база playwright js. С днешна дата вече имаме над два часа visual comparison run, а в цялото приключение успяхме да привлечем и още трима junior QA.
В света на автоматизирането всичко е много динамично, увличаме се, защото имаме достъп до много ресурси, трупаме технология върху технология и в един момент се озоваваме в един излишно усложнен свят, само защото можем да го направим такъв. Запалени по иновациите и интегрирането на процеси с примери от интернет, които ни звучат добре, в един момент забравяме, че с по-семпли действия и подходящия инструмент, често можем да постигнем много повече.
