Nadeel van het ontbreken van een formeel feedbacksysteem voor defectanalyse
An INFJ personality wielding brevity in speech and writing.
Ons team maakte zich klaar om een 56 pagina’s tellend gap-consultingrapport te presenteren dat ons Engineering-team had opgesteld voor onze klant, een wereldwijde e-commerce retailer
Een klein achtergrondverhaal:
Deze klant was toevallig op onze site terechtgekomen, had de QA-volwassenheidsquiz gedaan en de contactgegevens achtergelaten zodat wij contact met hen konden opnemen. Uit hun antwoord op de quiz kregen we een goed inzicht in hun hiaten in de productkwaliteit in het systeem en de status van de testprocessen van hun geografisch verspreide teams.
Na de eerste ontmoetingen en sessies voor kennisoverdracht over productomvang pleitten consultants bij Zuci voor een holistische benadering van productkwaliteit. Met holistisch bedoelen we: productkwaliteit is niet beperkt tot QA-teams. Kwaliteit is een gedeelde verantwoordelijkheid en teams moeten het bouwen van producten, het schrijven van coderegels en andere activiteiten benaderen met een kwaliteitsmentaliteit.
Wanneer een dergelijke kwaliteitscultuur is ingesteld, wordt technische uitmuntendheid een gewoonte en geen handeling.
Dus in de eerste paar weken van het overleg beoordeelde een team van 5 leden met gemengde achtergronden de engineeringpraktijken, testengineeringprocessen en complicaties die QA-effectiviteit en foutloze releases in de weg staan.
Er zijn bevindingen, beoordelingen en aanbevelingen gedaan in de software-engineeringprocessen, zoals:
- Engineering agile proces
- Implementatie en gebruik van DevOps
- Verandermanagementpraktijken binnen de organisatie
Een snelle blik door het rapport vond ik de “afwezigheid van formeel feedbacksysteem voor defectanalyse” in de observatiesectie interessant. Ik wilde dit onderwerp kiezen met onze testleider, Madanika Rani, en zien wat zij over dit onderwerp te bieden heeft.
Ik vroeg haar: “Wat doet een feedbacksysteem voor defectanalyse?”
Madanika:Het analysesysteem voor defectfeedback helpt testteams defecten te analyseren, de oorzaak ervan te identificeren en ons te helpen maatregelen te nemen om deze defecten te minimaliseren of te stoppen.
Lekkage van defecten naar productie kan optreden vanwege een van de volgende redenen:
- Regressiedekking minimaliseren
- Randscenario’s verwaarlozen vanwege een aantal instellingen
- Belanghebbenden met een minimale of oppervlakkige kennis van de toepassing
- Minimaliseer de testdekking om deadlines te halen
Over de betrokkenheid van testers bij de STLC voor het identificeren van defecten, voegt ze eraan toe, moet het zoeken naar bugs vanaf de unit-testfase worden gedaan, waarbij de agile-methodologie aan het roer staat van softwareontwikkeling.
Een momentopname van een feedbacksysteem voor defectanalyse:
Dus, wat zijn de nadelen van het ontbreken van een formeel feedbacksysteem voor defectanalyse?
- Ontwikkelaars hebben meer moeite om de productkwaliteit te behouden, omdat ze geen expliciete kennis hebben over de gebieden die de defecten zullen beïnvloeden. Er is een kans dat ze een tijdelijke oplossing voor het probleem vinden die later terugkomt.
- Ontwikkelaars hebben geen enkele verwijzing naar eerdere problemen die zich hebben voorgedaan en de geboden oplossing om hetzelfde op te lossen.
- Ontwikkelaars kunnen niet voorkomen dat de andere delen van de applicatie een probleem of de impact ervan krijgen als de oorzaak/geschiedenis van het probleem niet wordt teruggekoppeld. Dit gebeurt wanneer een nieuw teamlid of iemand zonder diepgaande kennis over het product toetreedt.
- Het wordt een uitdaging om het opnieuw optreden van een probleem te verminderen. Probleemherhaling vindt alleen plaats als het niet eerder goed is geanalyseerd en er geen permanente oplossing voor het probleem is.
- Verhoogt het herwerk dat nodig is om elk probleem op te lossen. Wanneer een defect wordt geconstateerd, hebben we geen toegang tot de achtergrond van het weefsel, waardoor het probleem vanaf het begin moet worden geanalyseerd.
- Nabewerking vereist meer tijd om het defect te analyseren en op te lossen, en het kost ook enorm veel middelen.
- Miscommunicatie tussen ontwikkelingsteams, testteams en managers is onvermijdelijk als systemen voor feedbackanalyse niet aanwezig zijn.
- De totale levenscyclus van softwaretests (STLC) wordt verlengd omdat er veel tijd nodig is om defecten en hun herhaling op te lossen
- Ontwikkelaars en testers hebben moeite om bugs zo vroeg mogelijk in de ontwikkelingscyclus te vinden.
- Teams gebruiken meerdere tools voor het opsporen van defecten. Zonder een goed feedbacksysteem voor defecten wordt het migreren van platforms en het integreren met elkaar een enorme uitdaging. Dit leidt dus tot een verlies in de beschrijving/oplossing van problemen vanuit het perspectief van de ontwikkelaar/tester/bedrijfsweergave/opmerkingen van gebruikers.
- Het is niet zo eenvoudig om niet-technische problemen/milieuproblemen op te sporen zonder de juiste terugkoppelingssystemen.
- Bugs kunnen niet eenvoudig worden opgelost zonder een systeem dat details vastlegt over de eerdere geschiedenis van teamafhankelijkheden enz
- Bij gebrek aan een goed feedbacksysteem voor defecten, glippen we door enkele details van de activiteiten die in de hersenen van de teams zijn opgeslagen
- Teams lopen het risico van verminderde traceerbaarheid en het niet kunnen leveren van waardevolle statistieken
- Het feedbacksysteem voor defecten fungeert als een opslagplaats voor teamleden om problemen op te lossen. Wanneer ze ervan worden beroofd, ontwikkelaars
- Zonder een goede geschiedenis of de kennis van een probleem, wordt rapportage twijfelachtig
- Leerachterstand wanneer de ontwikkelaar/tester geen kans krijgt om de feedback van opgeloste defecten te beoordelen.
- Het project binnen het budget opleveren is moeilijk omdat we overtollige bugs hebben en een hoge resolutietijd.
- Klachten van eindgebruikers zullen hoog zijn en CX zal dalen
- Het handmatige proces van het verzamelen van gegevens wordt vermoeiend naast de dagelijkse taken
- Feedback/ideeën van automatisering zijn verspreid en teams zullen de overbodige problemen en problemen met meer prioriteit niet gemakkelijk kunnen oplossen.
- Het is onmogelijk om de achtergrond van een defect bij te houden en of iemand eraan heeft gewerkt, tenzij we het feedback-analysesysteem voor defecten hebben.
- Het is moeilijk om dichter bij het nul-defect of defect-minder doel te komen
- Het is lastig om defecten te categoriseren of traceerbaar te maken voor alle revisies
- Verhoogd RISICO wanneer de ontwikkelaar/tester een probleem afhandelt zonder voorafgaande geschiedenis van problemen of kennis erover.
- Verminderde zichtbaarheid voor anderen die in een team werken.
- Vertraagt de beslissing van ontwikkelaars om zich af te melden, omdat ze niet erg zeker zijn van de probleemoplossing die ze hebben geboden, wat eerder gebeurde totdat de klant de oplossing accepteerde
- Vertraagt het herstelproces van het terugroepen van producten omdat testers geen massale defectgeschiedenis hebben.
- Gebrek aan informatiecirculatie tussen teams/management.
- Minimaliseert maatregelen die zijn genomen om defecten te beheersen die een significante functionaliteit beïnvloeden.
Een efficiënt feedbacksysteem voor defectanalyse is belangrijker voor teams met aanzienlijke productiedefecten, ondanks eerlijke testpraktijken.
Ontwikkelaars/testers kunnen niet zoveel informatie over bugs in hun hoofd opslaan, en het helpt ook niet om al deze informatie in silo’s te hebben.
Dus, een checklist hebben voor defectanalyse, inclusief ‘Stappen om te reproduceren inbegrepen’, ‘Screenshots inbegrepen’, ‘Softwareversie toegevoegd’, ‘Geheugendump toegevoegd’, ‘Logboek toegevoegd’, ‘Gedetecteerd in release’, ‘Bronrelease’, ‘ Releaseversie’ etc. helpt bij defectbeheer en rapportage.
Wilt u het rapport van Gap Consulting lezen? Stuur ons een ‘hoi’ op sales@zucisystems.com