Waarom QA-consulting een holistische technische visie nodig heeft?

“Hoe heeft QA dit gemist?”

Traditioneel komt deze vraag uit elk kwartaal wanneer er een probleem is met de productkwaliteit na release.

Een inefficiënt QA-proces is echter niet vaak de enige reden.

Het probleem kan zelfs complexer zijn dan dat en is mogelijk begonnen voordat het product zelfs maar werd uitgebracht.

Laten we een voorbeeld bekijken:

Laten we met de vinger wijzen naar QA!

Is het van toepassing in dit scenario?

Nee!

Een succesvolle release vereist coördinatie tussen verschillende teams, waaronder ontwerp, ontwikkeling, QA en andere. When these teams aren’t aligned on what they’re trying to accomplish, it can lead to pesky defects in your product development cycle—which means defective software and unhappy users!

Hier is een recente ramp met consultancy: Accenture heeft een rechtszaak aangespannen voor $ 32 miljoen wegens herontwerp van de website van Hertz

En daarom willen we vandaag via deze blog delen: waarom kwaliteit moet worden bekeken vanuit een holistische technische lens, een les die we hebben geleerd uit onze ervaring met het werken met klanten over de hele wereld en van verschillende groottes.

Waarom daalt de productkwaliteit?

Waarom melden onze gebruikers kritieke defecten?

Waarom kan onze QA defecten niet eerder opsporen?

…Dit zijn de vragen die we vaak te horen krijgen van onze klanten.

Hoewel deze “Waarom’s” helpen om te ontdekken wat er mis is gegaan met betrekking tot de productkwaliteit, denken we dat het slechts het topje van de ijsberg is en dat er een diepe duik in de technische processen moet worden genomen om veel belangrijkere componenten aan het licht te brengen die direct of indirect gerelateerd aan softwarekwaliteit.

Waarom denken we dat dit niet is gemaakt als standaardbenadering om naar productkwaliteit te kijken? Hoewel er vele redenen kunnen zijn, komt het allemaal neer op één kernprobleem: technologieleiders hanteren een geïsoleerde benadering van kwaliteit en onderzoeken het probleem/de kwaliteit niet vanuit een holistisch technisch oogpunt.

Bij Zuci begrijpen we dat kwaliteit een continu proces is. En daarom hebben we onze QA-adviesaanpak gebouwd met ZORG (Controleren, Handelen, Verfijnen, Evolueren) om problemen bij de wortel te identificeren en ze te helpen oplossen.

Onze president, Vasudevan Swaminathan, geeft uitleg over “Holistische benadering van kwaliteit” in deze video van 2 minuten. Bekijken

Ideaal QA-advies

“Kwaliteit is ieders verantwoordelijkheid.”

Goede softwarekwaliteit gaat niet alleen over testen, maar omvat ook andere software-engineeringpraktijken, zoals duidelijkheid in vereisten, schattingen, codekwaliteit, documentatie, software-onderhoud, individuele vaardigheden, teamcompetenties en andere aanverwante gebieden. – Z-ingenieurs

De kenmerken van QA-adviesoefeningen zijn uniek. Laten we de kenmerken van consulting doornemen aan de hand van de vijf belangrijkste aspecten: technologie, product, mensen, proces en cultuur.

Dit is de benadering die Zuci hanteert om de vijf belangrijkste aspecten te begrijpen.

Terwijl,

1. Technische praktijken

1. Kernproduct

1. Uitgaven van klanten

1. Testtechniek & QA

Technologie

Het belangrijkste doel hier is om de technologie en mogelijkheden van de klant te beoordelen op basis van de volgende premissen:

• De kwaliteit van het softwareproduct komt voort uit de kwaliteit van het proces dat is gebruikt om het te maken.
• Technologie die de kwaliteit van het softwareproces ondersteunt.
• Technologieniveau dat wordt gebruikt bij de ontwikkeling van software-engineeringproducten.
• Software engineering proces volwassenheid.

Adviseurs moeten deze oefeningen in de vroege stadia van het overleg uitvoeren en zo veel mogelijk details verzamelen en deze observaties documenteren die kunnen helpen bij de volgende stappen van het overleg.

Product

Consultants moeten een volledig begrip van het product krijgen. Het kan worden gedaan door middel van een reeks vergaderingen, whiteboard, brainstormsessies en het bekijken van verschillende delen vande applicatiesuite van de klant in projectmanagementtools; niet alleen vanuit het oogpunt van QA, maar ook vanuit het perspectief van software-engineeringprocessen, door hun architectuur, code, infrastructuur, technische schuld en andere relevante gebieden in vogelvlucht te bekijken.

De beoordeling van het kernproduct moet het volgende bevatten:

• Productdefecten en patroonanalyse
• Sprintplanning en leveringsbeoordeling
• Beoordeling van handmatige en geautomatiseerde tests
• API-integraties – Tools, Testaanpak
• Hardware, software en externe integraties
• Praktijken voor beheer van productveranderingen
• Integratie van productbeheer en productieondersteuning

Als je diep in het product duikt, kun je de bijbehorende ‘Technische Schuld’ niet missen.

Technische schuld is een uitdrukking die oorspronkelijk is bedacht door softwareontwikkelaar Ward Cunningham, die het omschrijft als:

“Met geleend geld kun je sneller iets doen dan anders, maar totdat je dat geld terugbetaalt, betaal je rente. Ik dacht dat geld lenen een goed idee was, ik dacht dat het een goed idee was om software de deur uit te haasten om er wat ervaring mee op te doen, maar dat je natuurlijk uiteindelijk terug zou gaan en als je dingen over die software leerde, zou je dat terugbetalen lening door het programma te herstructureren om uw ervaring weer te geven zoals u die hebt opgedaan.

Dit kan u interesseren

Technische schuld – Hoe gaat HORUS ermee om?

Mensen

Ingenieurs die bijdragen aan de verschillende levenscyclusfasen van het bouwen van producten beschikken niet alleen over diepgaande technische vaardigheden, maar ook over een ‘Product Quality Engineering Mindset’. Een effectieve praktijk voor kwaliteitsborging (QA) moet gebaseerd zijn op de mentaliteit van productkwaliteitsengineering.

Deze mentaliteit is een unieke set principes, methodologieën en praktijken die bestaat uit zelfleren, samenwerking, teamwerk, voortdurend experimenteren, verkennen, nauwkeurige vragen stellen en antwoorden zoeken, toewijding en focus.

Als we het hebben over mensen en samenwerking, kan het belang van het empoweren van mensen door middel van trainings- en ontwikkelingsprogramma’s niet worden benadrukt. Dit dient als kennisbasis en is cruciaal wanneer er geografisch verspreide teams samenwerken.

Het is essentieel om de rol van QA-consultants hierin te erkennen om een sterke basis te leggen voor elke organisatie. De sleutel is om iedereen op dezelfde pagina te krijgen, zodat ze begrijpen hoe elk onderdeel van hun werk past in het hele plaatje bij het bouwen van kwaliteitsapplicaties.

Geïnteresseerd in een oplossing die een duidelijk beeld geeft van de kwaliteit van het product voor mensen in de hele organisatie?

Welke voordelen biedt HORUS voor elke belanghebbende in de technische organisatie?

Proces

Meestal volgen adviesteams processen van eigen bodem of lichtgewichtprocessen. Velen van hen volgen op Agile of Lean gebaseerde methodieken.

Het hoofddoel van de procesbeoordeling is het beoordelen van de software-engineeringpraktijken die de klant volgt. Het vereist voornamelijk dat consultants beschikken over:

• Gesprekken met Productmanagement
• Discussies met engineeringteam(s)
• Gesprekken met het Professional Services-team
• Gesprekken met klantgerichte teams
• Samenwerking tussen Product Management, Engineering, Solutions & Productieondersteuningsteams
• Productieondersteuningspraktijken

Zuci’s manier om naar ‘proces’ te kijken is door drie kerngebieden te beoordelen die een overzicht geven van de algemene technische processen en effectiviteit, waaronder:

Bent u niet zeker van de volwassenheid van uw QA-proces? We hebben gedetailleerd besproken over QA-volwassenheid en heeft een weg uitgezet om dit te bereiken en meer. Haal het allemaal hier.

Cultuur

De softwarekwaliteit is enorm. Het kan een bedrijf maken of breken. Het is zeer agressief en boordevol actie.

Sommige bedrijven geven er de voorkeur aan vanaf het begin kwaliteit in hun producten in te bouwen, terwijl andere zich richten op het oplossen van bugs nadat het product is gelanceerd. Sommige bedrijven verdienen geld door hoogwaardige producten te bouwen; anderen verdienen geld door problemen op te lossen nadat een product is verzonden.

Het komt allemaal neer op de ‘cultuur’ van het bedrijf.

De rol van een consultant hier is om een shift-left-cultuur mogelijk te maken die de silo’s elimineert en helpt de samenwerking tussen het team te verbeteren

Sleutelelementen van Shift-links

• Betrek testers in een vroeg stadium: Maak QA onderdeel van het SCRUM-team. QA moet de gebruikersverhalen doornemen en samenwerken met de productmanagers om dit te begrijpen en opheldering te krijgen. QA definieert vervolgens acceptatiecriteria samen met de productmanagers en analisten. QA zal beslissen over de handmatige tests die gedaan moeten worden voor de start van de Sprint.
• Breng ontwikkelaars naar testactiviteiten: breng meer unit-, integratie- en statische code-analyse in voor hun code voordat deze naar de hoofdtak wordt gepusht; de samengevoegde code is schoner en minder foutgevoelig. Individuele code-eenheden zijn gemakkelijker te testen omdat ze kleiner en beter navigeerbaar zijn.
• Laat testers kennismaken met coderen: QA werkt samen met de ontwikkelaars om de acceptatietests te automatiseren op basis van de acceptatiecriteria.
• Houd testbaarheid in gedachten tijdens het coderen: Succesvol Shift Left Testen vereist ook een teaminspanning. Bij het schrijven van code moeten ontwikkelaars zich afvragen: “Hoe maak ik het testbaarder?” Dit kan betekenen dat je een hook blootlegt of een unieke ID voor een element maakt
• Vind een mogelijkheid om elk herhaalbaar proces te automatiseren: automatisering moet unit-/integratie-/acceptatietests omvatten, waaronder applicatiefunctionaliteiten, integraties, configuraties, implementaties, prestatie-, capaciteits- en beveiligingstests.
• Vul geautomatiseerde tests aan met exploratory testing en usability testing.

Wij bij Zuci genieten met volle teugen van elke QA-adviesoefening en hopen dat u er ook met plezier over zult lezen.

Laatste gedachten

Het is belangrijk om een holistisch technisch beeld van het product te hebben. Soms wijst het “grotere plaatje” ons in de richting van wat er mis is met een deel van het product; andere tijden; het helpt ons gewoon om potentiële verbetermogelijkheden op meerdere gebieden te identificeren.

Om verbeterpunten te ontdekken, kunt u eenvoudig beginnen met een scorekaart voor productkwaliteit of zelfs een QA-volwassenheidsquiz doen die de naald in uw productlevenscyclusproces zal verplaatsen.

Dus wat onderscheidt een product? Het antwoord is eenvoudig maar niet eenvoudig: kwaliteit.

Kwaliteit is gebaseerd op de kernvaardigheden voor het schrijven van code van de ontwikkelaars. Geweldige producten zullen geen stapel technische schulden bevatten. Ze hebben duidelijke documentatie voor elk van de teams en maken het gemakkelijker om samen te werken. Ze houden rekening met de ervaringen van eindgebruikers. En het laat de kwaliteit niet aan het toeval over.

Wilt u een gratis exemplaar van het adviesrapport dat we hebben gemaakt voor een F500 e-commerce gigant?

Schrijf ons op sales@zucisystems.com en we nemen binnen een dag contact met u op.