RISICOBEHEERBEDRIJF OP DE WERKPLEK GAAT ZUCI BENADEREN VOOR TESTAUTOMATISERING EN QA PROCESS CONSULTING
CASESTUDY
Industrie – Software
Locatie – Engeland, VK
Aangeboden diensten – QA-consult
QA-OVERLEG
CASESTUDY
Met Zuci’s QA-adviesdiensten realiseert het 44-jarige bedrijf met toonaangevende compliance- en risicobeheeroplossingen de verbeterpunten in hun QA-functies in combinatie met aanbevelingen.
QA RAADPLEGING CASE STUDY
Met Zuci’s QA-adviesdiensten realiseert het 44-jarige bedrijf met toonaangevende compliance- en risicobeheeroplossingen de verbeterpunten in hun QA-functies in combinatie met aanbevelingen.
Onze klant is een toonaangevende leverancier van risicobeheeroplossingen in het Verenigd Koninkrijk met een wereldwijd bereik en bedient meer dan 45.000 klanten.
Het bedrijf was toegewijd aan zijn missie om veiligere en betere werkplekken te creëren door gebruik te maken van hun goed geïnformeerde teams en geavanceerde technologie. Hun doel was ambitieus, ze wilden tegen het jaar 2025 vijf miljoen werknemers in Noord-Amerika beschermen tegen incidenten op de werkplek. Omdat ze uitdagingen op het gebied van softwarekwaliteit tegenkwamen, wilden ze hun QA-proces optimaliseren en mogelijke zwakke punten identificeren.
Toen werden de consultingspecialisten van Zuci benaderd om de kwaliteit van het QA-proces van het bedrijf te evalueren, de tekortkomingen ervan op te sporen, het testautomatiseringskader te auditeren en met aanbevelingen voor verbetering te komen.
OVER KLANT
OVER KLANT
Onze klant is een toonaangevende leverancier van risicobeheeroplossingen in het Verenigd Koninkrijk met een wereldwijd bereik en bedient meer dan 45.000 klanten.
Het bedrijf was toegewijd aan zijn missie om veiligere en betere werkplekken te creëren door gebruik te maken van hun goed geïnformeerde teams en geavanceerde technologie. Hun doel was ambitieus, ze wilden tegen het jaar 2025 vijf miljoen werknemers in Noord-Amerika beschermen tegen incidenten op de werkplek. Omdat ze uitdagingen op het gebied van softwarekwaliteit tegenkwamen, wilden ze hun QA-proces optimaliseren en mogelijke zwakke punten identificeren.
Toen werden de consultingspecialisten van Zuci benaderd om de kwaliteit van het QA-proces van het bedrijf te evalueren, de tekortkomingen ervan op te sporen, het testautomatiseringskader te auditeren en met aanbevelingen voor verbetering te komen.
HOE ZUCI HEEFT GEHOLPEN
De QA-consultants van Zuci stonden te popelen om de uitdaging aan te gaan en het bedrijf te helpen bij het bereiken van zijn doel om betere werkplekken te creëren.
Als onderdeel van de beoordeling heeft ons team interviews gehouden en de QA-teamleden van de klant ondervraagd en alle QA-artefacten grondig geanalyseerd: codebasis, Cypress-automatiseringsframework, Azure-pijplijn en QA-processen.
HOE ZUCI HEEFT GEHOLPEN
De QA-consultants van Zuci stonden te popelen om de uitdaging aan te gaan en het bedrijf te helpen bij het bereiken van zijn doel om betere werkplekken te creëren.
Als onderdeel van de beoordeling heeft ons team interviews gehouden en de QA-teamleden van de klant ondervraagd en alle QA-artefacten grondig geanalyseerd: codebasis, Cypress-automatiseringsframework, Azure-pijplijn en QA-processen.
Er is een uitgebreid rapport opgesteld met alle resultaten, suggesties voor verbetering en een plan om de voorstellen uit te voeren.
De adviseurs van Zuci definieerden enkele van de probleemgebieden en dienden voorstellen in, waaronder de volgende:
Kader voor testautomatisering:
De automatiseringstestsuite van de klant was geschreven in Cypress versie 9.4.1, waarin enkele van de nieuwste mogelijkheden ontbraken. De QA-consultants stelden voor dat de klant zou migreren naar Cypress versie 10, omdat dit verschillende voordelen zou bieden, waaronder:
- De mogelijkheid om te integreren met het Cypress Dashboard voor eenvoudigere analyses
- Geavanceerde foutopsporingsmogelijkheden met de Command Console
HOE ZUCI HEEFT GEHOLPEN
HOE ZUCI HEEFT GEHOLPEN
Er is een uitgebreid rapport opgesteld met alle resultaten, suggesties voor verbetering en een plan om de voorstellen uit te voeren.
De adviseurs van Zuci definieerden enkele van de probleemgebieden en dienden voorstellen in, waaronder de volgende:
Kader voor testautomatisering:
De automatiseringstestsuite van de klant was geschreven in Cypress versie 9.4.1, waarin enkele van de nieuwste mogelijkheden ontbraken. De QA-consultants stelden voor dat de klant zou migreren naar Cypress versie 10, omdat dit verschillende voordelen zou opleveren, waaronder:
- De mogelijkheid om te integreren met het Cypress Dashboard voor eenvoudigere analyses
- Geavanceerde foutopsporingsmogelijkheden met de Command Console
HOE ZUCI HEEFT GEHOLPEN
- Eenvoudige integratie met rapportagetools zoals het Mochawesome-rapport en het Allure-rapport
- De mogelijkheid om testgevallen te groeperen en de gegroepeerde testgevallen uit te voeren
- De mogelijkheid om tags toe te voegen aan testcases
- De integratie van het Mochawesome-rapport voor eenvoudige analyse en analyse van testcases
De consultants merkten ook op dat het huidige testframework geen ondersteuning bood voor lokalisatie en raadden aan om taalspecifieke json-bestanden toe te voegen voor het testen van meerdere talen.
Bovendien merkten ze op dat het testraamwerk op drie niveaus was geïmplementeerd (pagina’s, bronnen en functionaliteiten), wat het begrijpen van de testgevallen vervelend maakte. Als gevolg hiervan adviseerden ze om het raamwerk te vernieuwen om het pagina-objectmodel op twee niveaus (pagina’s en tests) over te nemen voor meer duidelijkheid.
HOE ZUCI HEEFT GEHOLPEN
- Eenvoudige integratie met rapportagetools zoals het Mochawesome-rapport en het Allure-rapport
- De mogelijkheid om testgevallen te groeperen en de gegroepeerde testgevallen uit te voeren
- De mogelijkheid om tags toe te voegen aan testcases
- De integratie van het Mochawesome-rapport voor eenvoudige analyse en analyse van testcases
De consultants merkten ook op dat het huidige testframework geen ondersteuning bood voor lokalisatie en raadden aan om taalspecifieke json-bestanden toe te voegen voor het testen van meerdere talen.
Bovendien merkten ze op dat het testraamwerk op drie niveaus was geïmplementeerd (pagina’s, bronnen en functionaliteiten), wat het begrijpen van de testgevallen vervelend maakte. Als gevolg hiervan adviseerden ze om het raamwerk te vernieuwen om het pagina-objectmodel op twee niveaus (pagina’s en tests) over te nemen voor meer duidelijkheid.
Voorgesteld om een nieuwe pijplijn te maken en vooraf gedefinieerde afbeeldingen te gebruiken, aangezien dit ongeveer. 50 minuten uitvoeringstijd
Voorgesteld om twee pijpleidingen te hebben
- Build Pipeline: Gebruikt voor het uitvoeren van tests zonder te hoeven implementeren
- Pipeline implementeren: wordt gebruikt om wijzigingen in de opgegeven omgeving te implementeren
De adviseurs adviseerden ook implementatiemaatregelen om problemen met buildfouten te voorkomen. Stelde bijvoorbeeld voor om een incrementele database te gebruiken om verschillende fouten bij het laden van cypress-gegevens te voorkomen
Aanbevolen om Allure-rapporten te integreren in de pijplijnfase, omdat dit diepere analyses in verschillende formaten zou opleveren.
AZURE PIJPLEIDING
AZURE PIJPLEIDING
Voorgesteld om een nieuwe pijplijn te maken en vooraf gedefinieerde afbeeldingen te gebruiken, aangezien dit ongeveer. 50 minuten uitvoeringstijd
Voorgesteld om twee pijpleidingen te hebben
- Build Pipeline: Gebruikt voor het uitvoeren van tests zonder te hoeven implementeren
- Pipeline implementeren: wordt gebruikt om wijzigingen in de opgegeven omgeving te implementeren
De adviseurs adviseerden ook implementatiemaatregelen om problemen met buildfouten te voorkomen. Stelde bijvoorbeeld voor om een incrementele database te gebruiken om verschillende fouten bij het laden van cypress-gegevens te voorkomen
Aanbevolen om Allure-rapporten te integreren in de pijplijnfase, omdat dit diepere analyses in verschillende formaten zou opleveren.
AZURE PIJPLEIDING
Dit is hoe onze voorgestelde build-pijplijn eruit ziet:
Zo ziet onze voorgestelde implementatiepijplijn eruit:
AZURE PIJPLEIDING
Dit is hoe onze voorgestelde build-pijplijn eruit ziet:
Zo ziet onze voorgestelde implementatiepijplijn eruit:
Consultants stelden voor om de optie ‘Uitgesteld’ toe te voegen aan de vervolgkeuzelijst Automatiseringsstatus, waardoor classificatie van testgevallen die worden uitgesteld voor automatisering eenvoudiger wordt
Aanbevolen groepering van testgevallen op labels zoals rook, regressie, enz
Voorgestelde invulling van de labelvelden met impactgebieden – wat handig zou zijn bij het vinden van gebieden met een hogere defectdichtheid
Aanbevolen om defecten te categoriseren op:
- Fase van detectie
- Fase van injectie
- Bedrijfscomponent/functionaliteit – Om de automatiseringsdekking in die module te verbeteren en meer focus op testen te geven
- Type repareren
QA-PROCES
QA-PROCES
Consultants stelden voor om de optie ‘Uitgesteld’ toe te voegen aan de vervolgkeuzelijst Automatiseringsstatus, waardoor classificatie van testgevallen die worden uitgesteld voor automatisering eenvoudiger wordt
Aanbevolen groepering van testgevallen op labels zoals rook, regressie, enz
Voorgestelde invulling van de labelvelden met impactgebieden – wat handig zou zijn bij het vinden van gebieden met een hogere defectdichtheid
Aanbevolen om defecten te categoriseren op:
- Fase van detectie
- Fase van injectie
- Bedrijfscomponent/functionaliteit – Om de automatiseringsdekking in die module te verbeteren en meer focus op testen te geven
- Type repareren
QA-PROCES
Voorgestelde vastlegging van kwaliteitsstatistieken zoals:
- Testdekking (handmatig/automatisering)
- Efficiëntie van het verwijderen van defecten (zou 0 moeten zijn voor kritieke vrijgave)
Geadviseerd om root cause analysis uit te voeren voor alle post release defecten
Voorgestelde definitie van oorzaak-gevolgmatrix om:
- Maak het kiezen van de juiste set regressiegevallen mogelijk, op basis van impactgebied
- Om de automatiseringsdekking te verbeteren
- Om meer focus te geven op testen
Voorgestelde aanbevelingen om de API-testdekking te verbeteren
QA-PROCES
Voorgestelde vastlegging van kwaliteitsstatistieken zoals:
- Testdekking (handmatig/automatisering)
- Efficiëntie van het verwijderen van defecten (zou 0 moeten zijn voor kritieke vrijgave)
Geadviseerd om root cause analysis uit te voeren voor alle post release defecten
Voorgestelde definitie van oorzaak-gevolgmatrix om:
- Maak het kiezen van de juiste set regressiegevallen mogelijk, op basis van impactgebied
- Om de automatiseringsdekking te verbeteren
- Om meer focus te geven op testen
Voorgestelde aanbevelingen om de API-testdekking te verbeteren
Een momentopname van defectdetails
QA root causes | Dev root causes | Fix type | Defect type/category | Defect status |
---|---|---|---|---|
Configuration | Enhancement | Code fix | Automation data issue | Deferred |
Deployment issue | Exists in release checklist. Deployment issue | Data issue | Automation framework/API issue | Fix in progress |
Missed Requirement In FRD | Gap in understanding | Deployment | Automation script issue | FRD Update Pending |
QA-PROCES
QA-PROCES
Een momentopname van defectdetails
QA root causes | Dev root causes | Fix type | Defect type/category | Defect status |
---|---|---|---|---|
Configuration | Enhancement | Code fix | Automation data issue | Deferred |
Deployment issue | Exists in release checklist. Deployment issue | Data issue | Automation framework/API issue | Fix in progress |
Missed Requirement In FRD | Gap in understanding | Deployment | Automation script issue | FRD Update Pending |