Menu

Wat is vroeg testen: vroeg testen, vaak testen, MAAR hoe? (Een praktische gids)

what is early testing

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is vroeg testen?

Het testen van software moet vroeg in de levenscyclus van softwareontwikkeling beginnen. Dit helpt bij het vastleggen en elimineren van defecten in de vroege stadia van SDLC, d.w.z. het verzamelen van vereisten en ontwerpfasen. Een vroege start van het testen helpt om het aantal defecten te verminderen en uiteindelijk de kosten voor nabewerking.

De verschillende aspecten van Vroege testen die de QA-managers en -leiders zouden kunnen helpen bij het ontwikkelen of opstellen van het teststrategiedocument in SDLC, worden hier uitgelegd.

Het toepassen van Early Test zal enorm resulteren in de succesvolle levering van een kwaliteitsproduct.

vroege testen (1)

Aan het einde van deze tutorial hebben de lezers, QA-managers, leads en testers een behoorlijke kennis van de onderstaande concepten:

beste programma's om de cpu-temperatuur te bewaken
  • Waarom vroeg testen in SDLC (project of softwarerelease)?
  • Scoping van inspanningen voor vroege tests
    • Wat moet je vroeg testen?
    • Start en sluit af
  • Voors en tegens

Laten we nu de nuances in detail onderzoeken !!

Wat je leert:

Principes van testen

Figuur 1 - Vereenvoudigde weergave van de principes van testen

1. principes van testen

Voor een bepaalde software- of systeem- of productrelease in SDLC zijn er verschillende goed gedefinieerde methodologieën of strategieën voor de meeste van de volgende testprincipes.

  • Wat is testen?
  • Waarom testen?
  • Wat te testen?
  • Hoe te testen?

Enkele van de meest aanslepende vragen die veel lezers, testers, leads en QA-managers zouden stellen of die er meer duidelijkheid over zouden willen krijgen, zijn onder meer (grijs gebied in Figuur 1 ​

  • Wanneer moet u beginnen met testen in een softwareversie of wanneer moet u beginnen met testen in een project?
  • Wanneer moet u beginnen met testen en wanneer moet u stoppen met testen?
  • Waarom zou het testen vroeg in SDLC moeten beginnen?
  • Wat is een vroege test in softwareontwikkeling?

Om het publiek gemakkelijk te begrijpen, heb ik alle ‘grijze gebieden’ -vragen onder één noemer gebracht Vroege testen.

Waarom vroeg testen in SDLC?

Laten we enkele evenementen en activiteiten bespreken die deel uitmaken van testen.

Gewoonlijk wijst het programmamanagementteam een ​​programmamanager (PM) toe aan een bepaalde softwarerelease of een project. De PM stelt in samenwerking met alle stakeholders waaronder Marketing, Development, QA en Support teams een Release Schedule op

In deze tutorial heb ik gekozen Schema voor driemaandelijkse releases gebruik makend van het Watervalmodel om de Vroege testconcepten in detail.

Testschema voor softwarerelease

De meeste organisaties volgen nog steeds het traditionele Tijdgebaseerde release (TBR) -modellen waarbij de software- of productreleases gepland zijn voor levering per kwartaal, halfjaarlijks of jaarlijks.

Voor het uitvoeren van dergelijke softwareversies wordt voornamelijk het Waterfall-model gebruikt. In sommige gevallen wordt voor een kortere releasecyclus het Agile / Scrum-model aangenomen.

Figuur 2 ​ Typisch schema voor het testen van de driemaandelijkse release (niet voor het algehele project of het schema voor release)

Schema voor driemaandelijkse vrijgavetests

Gevolgen van kritieke of zeer ernstige defecten

figuur 3 ​ Typische gevolgen van kritieke defecten

Typische impact van kritieke defecten

Hoofdzakelijk , tijdens het testen, wordt dat verwacht

  • Kritieke of zeer ernstige defecten worden geïdentificeerd en geregistreerd door testers.
  • Ontwikkelaars zullen deze defecten moeten herstellen.
  • Vervolgens moeten testers de fixes verifiëren.

ten tweede wordt algemeen erkend door veel product- en software-engineeringorganisaties dat het oplossen en verifiëren van zeer ernstige of kritieke bugs bij een zeer groot aantal

  • Tijdrovend
  • Resource hogging (mens + machine)
  • Het oplossen van kritieke bugs is vatbaar voor onderpand en raakt meestal een groot deel van de code, inclusief de kruispunten.

Ten slotte , als een groot aantal van de kritieke bugs wordt gevonden aan het einde van een bepaalde release, dan vinden een of meer van de volgende negatieve ontwikkelingen plaats.

  • Grote kans dat de testcyclus wordt verlengd.
  • Grote kans dat de releasedatum wordt gemist.
  • Een bepaald kenmerk met een groot aantal defecten moet mogelijk allemaal uit die specifieke release worden gehaald.
  • Verplichtingen van klanten worden niet nagekomen.

Hoe zit het met de andere defecten?

Er zijn defecten met gemiddelde en lage prioriteit die door de testers worden geïdentificeerd en geregistreerd. Deze moeten ook op de juiste manier worden afgehandeld door het Development en het QA-team. Het is dus over het algemeen een omvangrijke oefening.

Er is geen Silver Bullet

Het is een bekend feit dat geen enkele hoeveelheid testen elk defect van een softwareproduct of het systeem kan blootleggen. Dit betekent praktisch dat er geen einde komt aan het testen, noch dat het product defect is.

Echter, van de ‘ Onderhoudsgemak Vanuit het standpunt van een Competitive and Time To Market (TTM) -model is het nodig om de typische mindset te doorbreken om maximale defecten vroeg in een Release-cyclus op te sporen, met name de identificatie van kritieke en zeer ernstige defecten.

Al het bovenstaande heeft een negatieve invloed op de zaken van de organisatie. In deze context ‘ Vroege testen 'Heb een afzonderlijke testactiviteit zal gunstig zijn voor het algehele beheer van SDLC voor een bepaald project of release.

De reikwijdte van vroege testinspanningen

Het doel van testen vroeg in het vorige gedeelte met de titel ' Waarom vroeg testen? ’, Laten we nu de‘ Reikwijdte van vroege testinspanningen ' in detail.

Aangezien we Testen vroeg introduceren als een nieuwe activiteit die uitsluitend moet worden gevolgd tijdens de uitvoering van het testen, wordt aanbevolen om de reikwijdte van de testinspanning te oefenen, zoals hieronder wordt uitgelegd

Veronderstelling:

  • Het volledige project of softwarereleaseschema wordt goedgekeurd en beschikbaar gesteld aan alle belanghebbenden.
  • Het algemene teststrategiedocument wordt ontwikkeld, beoordeeld en goedgekeurd door alle belanghebbenden.
  • Te testen kenmerken met hoge, gemiddelde en lage prioriteit zijn goed gedocumenteerd.
  • Testplannen en testcases voor alle functies worden ontwikkeld, beoordeeld en goedgekeurd door alle belanghebbenden.
  • Alle testplannen en testcases worden geüpload naar een centrale opslagplaats voor het volgen van de testuitvoering.
  • Alle human resources, infrastructuurapparatuur en tools zijn beschikbaar voor het opzetten van de testbank (en) en het uitvoeren van testplannen.

Wat moet je vroeg testen?

Figuur 4 ​ Algemene benadering van de reikwijdte van vroeg testen

4.Wat te testen bij vroege testen

Nadering

  • Laten we een Voorbeeld van Release XYZ met 3 functies met hoge prioriteit A, B en C, 10 functies met gemiddelde prioriteit en 15 functies met lage prioriteit (of lage prioriteit).
  • Functies met hoge prioriteit zijn functies die hoge inkomsten genereren en / of voldoen aan de normen en / of een inhaalslag van de concurrent en / of een concurrentievermogen en al deze zaken.
  • Functies met hoge prioriteit omvatten meestal een complexe codering, een groot aantal nieuwe regels code toegevoegd.
  • Een groot aantal nieuwe regels code kan ook een grote kans op kruispunten betekenen.
  • Gewoonlijk zijn functies met een hoge prioriteit en / of functies met een groot aantal nieuwe regels code de beste kandidaten voor vroeg testen.
  • Er hoeft geen apart testplan te zijn ontwikkeld voor vroege testactiviteiten.
  • QA-leads of testers moeten samen met de ontwikkelingsleiders of het MKB (subject-materiedeskundigen) de Code / Testing-dekking voor deze testactiviteit bespreken en overeenkomen.
  • Identificeer geschikte testcases met hoge prioriteit en zelfs enkele testcases met gemiddelde prioriteit als u denkt dat dit nodig is uit elk van de functietestplannen A, B en C.
  • Zodra de juiste functies en subset van testcases zijn geïdentificeerd, moet u ervoor zorgen dat ze worden gevolgd met behulp van de testtrackingstool die door de organisatie is aangenomen.

Hint: samenwerking is de sleutel! Tijdens de Early Test-activiteit moeten zowel het Development- als het QA-team nauw samenwerken om ervoor te zorgen dat de gestelde doelen worden bereikt met kwaliteitsresultaten.

Start en sluit af bij vroege test

Het is belangrijk dat zowel het Development- als het QA-team brainstormen en akkoord gaan met alle benaderingen van de gehele Early Test-activiteit, inclusief de start- en einddatums, zodat ze allemaal op dezelfde pagina staan.

Toegangscriteria voor Start

  • Percentage voltooide integratietests
  • Aantal openstaande bugs
  • Geen blokkers om Early Test te starten

Activiteitsfase

  • Voortgang bijhouden
  • Het aantal codes dat tijdens deze test wegvalt
  • Bugfixerende aanpak
  • Bugverificatie aanpak
  • Noteer deze testresultaten

Criteria afsluiten

  • Overdracht van activiteiten naar de volgende testfase (meestal Feature Testing).
  • Oplossing van onopgeloste bugs gevonden tijdens Early Test.
  • Oplossing van eventuele blokkers voor de volgende testfase.
  • Publiceer vroege testresultaten.

Voors en tegens

Elk nieuw initiatief of activiteit heeft zijn eigen verdiensten en nadelen.

Laten we de voor- en nadelen van deze testaanpak onderzoeken.

Voordelen

  • Uitermate geschikt voor het Waterval-model.
  • Helpt kritieke bugs vroeg in de testcyclus op te sporen.
  • Identificatie van kritieke bugs vroeg in een releasecyclus.
  • Helpt het ontwikkelteam om de code vroegtijdig te stabiliseren.
  • Helpt het onderpand te minimaliseren door bugfixes.
  • Helpt het ontwikkelteam vroeg in de releasecyclus in detail kwetsbaarheden op kruispunten te identificeren.
  • Het managementteam kan passende zakelijke beslissingen nemen met de nodige zorgvuldigheid over onopgeloste kritieke bugs in die specifieke release of een project.
  • Helpt bij het verlengen test dekking en effectief fietsen.
  • Helpt bij het efficiënt en effectief distribueren van ontwikkelings- en testmiddelen.

Nadelen

  • Niet bij uitstek geschikt voor Agile / Scrum-model. Dergelijke modellen kunnen echter Early Test in Sprints toepassen met de juiste aanpassingen.
  • Er is een kans op verkleining Integratietesten door het Development Team.

Gevolgtrekking

Klanten of eindgebruikers kopen of nemen een onderhoudsproduct of een systeem of oplossing over. Het valideren van software die op een dergelijk systeem of dergelijke producten wordt uitgevoerd, is de eerste vereiste

Sleutelcomponenten van testprincipes, zoals Waarom testen? Wat is testen? Wat te testen? Hoe te testen? zijn meestal goed gedefinieerd en begrepen. Er zijn echter enkele slepende vragen die in de geest van de lezers, testers, leads en managers blijven steken over concepten als Early Testing.

Het aannemen van vroege tests als een integrale activiteit van het algemene testschema voor een bepaald softwareproject of een release heeft enorme voordelen voor de organisatie om een ​​robuust gekwalificeerd product of een systeem te leveren.

Heb je je ooit gerealiseerd hoe belangrijk Early Testing in je carrière is? Deel gerust uw mening en ervaringen in de comments hieronder !!

Aanbevolen literatuur

^