CIKK · DYNAMICS 365 · TESZTAUTOMATIZÁLÁS

Tesztautomatizálás Dynamics 365-re: miért romlik el a testreszabás a release wave-nél?

A Microsoft évente kétszer, áprilisban és októberben frissíti a Dynamics 365-öt, és a frissítés az éles környezetre is megérkezik. A szabványos funkciók ritkán romlanak el; a saját testreszabások — JavaScript, pluginok, régi űrlapvezérlők, elavult API-k, PCF-komponensek, Power Automate-folyamatok és integrációk — viszont igen. A megoldás egy 30–50 tesztesetes, kockázatalapú automatizált regressziós készlet, amely a hullám korai hozzáférésű (early access) változatán, a sandboxban fut le, hetekkel az éles frissítés előtt.

Kapcsolatfelvétel Tesztautomatizálás →

Mi az a release wave, és mikor jön?

A release wave a Microsoft félévenkénti frissítési hulláma a Dynamics 365-höz és a Power Platformhoz. Az 1. hullám áprilisban, a 2. hullám októberben kezd élesedni, és a következő hónapokban szakaszosan jut el minden bérlőhöz. A tartalmát a Microsoft előre közzéteszi a kiadási tervekben (release plans), a kivezetéseket pedig a megszűnő funkciók listáján jelenti be.

Az élesítés előtt nagyjából két hónappal a hullám korai hozzáféréssel (early access) bekapcsolható egy sandbox környezetben. Ez az a hat-nyolc hét, amikor a hibát még a tesztkörnyezetben lehet megtalálni és kijavítani. Aki ezt kihagyja, az az éles frissítés reggelén tudja meg, mi romlott el — a felhasználóitól.

A frissítés nem halasztható a végtelenségig: a hullám kötelező, a bérlő ütemezett frissítési időpontjában az éles környezetre is megérkezik. A kérdés nem az, hogy jön-e, hanem hogy előtte lefutott-e a teszt.

Miért a testreszabás romlik el, és miért nem a szabványos funkció?

A szabványos funkciókat a Microsoft maga teszteli a hullám előtt. A saját fejlesztéseket viszont senki nem ismeri a Microsoftnál: azt a JavaScriptet, amely egy űrlapmező betöltésére vár, azt a plugint, amely egy bizonyos üzenetsorrendre épít, azt a Power Automate-folyamatot, amely egy mező régi értékét figyeli. A hullám ezek környezetét változtatja meg, és ők ettől romlanak el — gyakran hibaüzenet nélkül.

Elem	Mi a kockázat	Mit tesztelünk
Saját JavaScript az űrlapokon	nem támogatott DOM-hozzáférés, elavult Xrm.Page-hívások, időzítésre építő kód; a felület változásakor csendben leáll	mezők elrejtése, alapértékek, kötelező mezők, gombok az űrlapon
Pluginok és egyedi munkafolyamat-tevékenységek	megváltozott üzenetsorrend vagy platformviselkedés, elavult SDK-hívások, időtúllépés	a mentéskor, státuszváltáskor lefutó üzleti logika eredménye
Régi űrlapvezérlők és régi felületi elemek	a Microsoft kivezeti őket; a funkció eltűnik vagy másképp viselkedik	az érintett űrlapok megjelenése és működése
Elavult (deprecated) API-k	a bejelentett kivezetés egy későbbi hullámban élesedik	integrációk, szkriptek, riportok, amelyek a régi végpontot hívják
PCF-komponensek	a keretrendszer vagy a hozzá tartozó könyvtár verzióváltása	az egyedi vezérlő betöltése, adatkezelése, mentése
Power Automate-folyamatok	csatlakozó- vagy triggerváltozás, megváltozott mezőérték	jóváhagyás, értesítés, dokumentumgenerálás végponttól végpontig
Integrációk (ERP, számlázó, webshop)	a CRM-oldali változás a másik rendszerben okoz hibát	adatátadás mezőről mezőre, a felület alatt is (API-teszt)
Szabványos funkciók	ritkán romlanak el; a Microsoft maga teszteli őket	csak a saját folyamataink részeként, külön nem

A közös pont: minél több a testreszabás és az integráció, annál nagyobb a kockázat, és annál drágább minden hullám előtt kézzel végigkattintani a rendszert. Ezért a release wave a tesztautomatizálás legerősebb érve a Dynamics 365-ben.

Hogyan néz ki egy release wave regressziós folyamat?

1
Kockázatalapú tesztkészlet
Nem mindent automatizálunk. Az üzletkritikus és testreszabott folyamatokat rangsoroljuk — lead → ajánlat → rendelés, ügy → SLA → lezárás, ERP-átadás —, ebből lesz az első 30–50 teszteset. Egy közepes rendszernél ennyi fedi a kockázat nagyjából 80 %-át.
2
Éjszakai futtatás CI-ben
A készlet minden éjjel és minden telepítés előtt lefut (Azure DevOps, GitHub Actions, Jenkins). Így a hullám előtt már tudjuk, hogy a jelenlegi verzión minden zöld — a későbbi piros tehát a frissítés miatt piros.
3
Early access a sandboxban
A hullám korai hozzáférését egy, az élesből frissített sandboxban kapcsoljuk be, és ott futtatjuk le a teljes regressziós készletet.
4
A bukott tesztek elemzése
Minden pirosnál eldöntjük: valódi hiba a rendszerben, vagy csak a felület változott (új elrendezés, átnevezett gomb)? Képernyőkép, napló és Plugin Trace Log alapján.
5
Javítás: a rendszer vagy a teszt
Valódi hibánál a testreszabást javítjuk (például a nem támogatott JavaScriptet kiváltjuk), felületváltozásnál a tesztet igazítjuk. Utána újrafuttatás, amíg minden zöld.
6
Kiadási döntés
Tesztösszesítő: mi futott, mi bukott, mi maradt nyitva. Ennek alapján engedjük a frissítést az élesbe.

Melyik eszköz: Tricentis Tosca, Katalon vagy Playwright?

Tricentis ToscaModellalapú, kód nélküli eszköz dedikált Dynamics 365-támogatással. A felületet modellként szkenneli, a változásnál egy helyen kell javítani — nagy, üzletkritikus, gyakran frissülő rendszernél hosszú távon ez a legkönnyebben karbantartható.

Katalon StudioHibrid eszköz (felvevő + szkript): webet, API-t és mobilt egy eszközben kezel, gyorsan és kisebb költséggel indul. Dynamics-felületen működik, de több kézi karbantartással jár.

PlaywrightNyílt forráskódú, licenszdíj nélküli kódalapú keretrendszer a Microsofttól. A webes felületen stabilan fut, de a Dynamics-vezérlőkhöz (rácsok, keresőmezők, lapfülek, párbeszédablakok) saját segédfüggvények kellenek — ezeket mi adjuk.

Részletes összehasonlítás: Tricentis Tosca, Katalon vagy Playwright? A felület alatti integrációkat mindhárom mellett API-teszttel is ellenőrizzük (Postman, Newman a CI-ben).

Mit tesztelünk kézzel, és mit automatizáltan?

Az automatizálás a régit védi, nem az újat teszteli. A hullám új funkcióit és a megváltozott felületet kézzel nézzük át, mert ott emberi ítélet kell: kell-e az új funkció, zavarja-e a felhasználókat, be kell-e kapcsolni.

Automatizáltana stabil, üzletkritikus, testreszabott folyamatok regressziója; integrációk API-szinten; adatvezérelt esetek (árlista, pénznem, ország).

Kézzelaz új funkciók feltáró tesztje; a kiadási tervben bejelentett kivezetések hatásának ellenőrzése; a ritka, változékony vagy egyszeri esetek; a kulcsfelhasználók rövid átvételi köre.

Hogy hol húzódik a határ, és mikor térül meg az automatizálás, azt egy számpéldán mutatjuk be: manuális vagy automatizált tesztelés — mikor éri meg?

Hogyan csináljuk ezt a support-keretben?

A havidíjas Dynamics 365 support keretében a release wave felkészítés a szolgáltatás része, nem külön projekt:

A tesztkészlet a rendszerrel együtt élMinden módosításunkkal együtt frissítjük a teszteket is; a készlet így a hullám idejére naprakész.

Éjszakai futás egész évbenNem csak hullám előtt: minden telepítés előtt is lefut, így a saját módosításaink sem rontanak el semmit.

Early access-ablakA korai hozzáférés megnyílásakor bekapcsoljuk a sandboxban, lefuttatjuk a készletet, a hibákat a kiadási terv szerint ütemezve javítjuk.

Írásos összesítőA hullám előtt rövid jelentés a vezetésnek: mi változik, mi romlott el, mit javítottunk, mit érdemes bekapcsolni.

Más partner rendszere isHa a rendszert más vezette be, átvételi audittal indulunk, és az első lépés pont ez a regressziós készlet — ez védi az első módosításainkat és a következő hullámot.

A szolgáltatás részletei és eszközei: szoftvertesztelés és tesztautomatizálás.

Miért számít, hogy CRM-tanácsadó és tesztmérnök egy csapatban van?

Egy release wave-nél a bukott teszt csak a kérdés fele. A másik fele: miért bukott, és hogyan kell javítani — a JavaScriptet, a plugint, a folyamatot vagy a tesztet? Ha a tesztelő és a Dynamics-tanácsadó két külön cégnél ül, ez a kérdés jegyeken és heteken át pattog. Nálunk ugyanaz a csapat építi a testreszabást, írja a tesztet és elemzi a hibát; a Dynamics CRM-vizsgák (MB2-704, MB2-707, MB5-705) és a Tricentis Tosca-tanúsítványok ugyanannál a csapatnál vannak.

Gyakori kérdések

Mikor jelenik meg a Dynamics 365 release wave?

Évente kétszer: az 1. hullám áprilisban, a 2. hullám októberben kezd élesedni, és a következő hónapokban szakaszosan ér el minden bérlőhöz. Korai hozzáféréssel (early access) nagyjából két hónappal korábban sandboxban kipróbálható.

Elhalasztható a release wave?

Nem véglegesen. A frissítés kötelező, és a bérlő ütemezett frissítési időpontjában az éles környezetre is megérkezik. Ezért kell a tesztet a korai hozzáférés idején, a sandboxban lefuttatni.

Hány tesztesetet érdemes automatizálni?

Egy közepes rendszernél 30–50 kockázatalapon kiválasztott teszteset fedi a kockázat nagyjából 80 %-át. Nem a darabszám a cél, hanem az üzletkritikus és testreszabott folyamatok lefedése.

Milyen gyorsan van működő regressziós készlet?

Az első kör a legkritikusabb folyamatok automatizált tesztje, és ez már CI-ben fut; onnantól a készlet folyamatosan bővül.

Kell külön tesztkörnyezet?

Igen, a teszteket soha nem az élesben futtatjuk. Egy sandbox kell, amelyet az élesből frissítünk, és amelyen a hullám korai hozzáférése bekapcsolható.

Beszéljünk a projektjéről.

Vegye fel velünk a kapcsolatot, és néhány napon belül jelentkezünk Önnél!

Kapcsolatfelvétel