Articles

Wat Is de levenscyclus van de Software die test? Een complete gids

die een perfect product aan de klant presenteert, is het einddoel van elke organisatie. Maar wist je dat er een tijd was dat testen niet eens een onderdeel was van de software development life cycle (SDLC)?

niets zet klanten meer af dan een gebruikerservaring vol fouten. Dus toen bedrijven zich dit realiseerden, begonnen ze testen op te nemen als een verplicht onderdeel van de SDLC. Sindsdien is testen een integraal onderdeel van elke organisatie geworden.

de competentie van het testen is in de afgelopen decennia geëvolueerd. Momenteel, testen is niet over het rapporteren van bugs aan de ontwikkelaar. Het heeft een breed toepassingsgebied en is een verplichte fase om uit te voeren vanaf de eerste fasen van een project.

met agile werd de testcyclus van een toepassing meer procesgericht en veelzijdig. Meestal is de volledige focus van een onderneming op de SDLC alleen. Ze overwegen een deel van dat proces te testen. Maar het is hoog tijd dat bedrijven zich realiseren dat software testen een eigen levenscyclus heeft.

in dit artikel gaan we de rol van de software testing life style (STLC) en de fasen ervan in detail bekijken. Dus laten we er meteen in duiken!

Wat Is de levenscyclus van Software die wordt getest?

laten we eerst de term levenscyclus begrijpen voordat we in alle details treden. Een levenscyclus is de opeenvolging van veranderingen die een entiteit doorloopt van de ene vorm naar de andere. Veel concrete en obscure entiteiten gaan door een reeks veranderingen van begin tot eind.

wanneer we het hebben over de software die de levenscyclus test, is de software een entiteit. De software testing life cycle is het proces van het uitvoeren van verschillende activiteiten tijdens het testen.

deze activiteiten omvatten het controleren van de ontwikkelde software om te zien of deze voldoet aan specifieke vereisten. Als er gebreken in het product, testers werken met het ontwikkelteam. In sommige gevallen moeten ze contact opnemen met de stakeholder om inzicht te krijgen in verschillende productspecificaties. Validatie en verificatie van een product zijn ook belangrijke processen van de STLC.

SDLC vs STLC

het volledige traject van een product vanaf het begin tot het eindproduct wordt verzorgd door SDLC. Onder de verschillende fasen van SDLC, is het testen één van de belangrijkste. Software testen is een onderdeel van SDLC. En dit deel heeft zijn eigen levenscyclus-STLC.

dus hoe verschilt SDLC van STLC?

SDLC

  • Focus op het bouwen van een product
  • Een bovenliggende proces
  • het Begrijpen van de gebruiker vereist en het bouwen van een product dat is handig voor gebruikers
  • SDLC fasen zijn afgerond voordat het testen
  • Eind doel is het implementeren van een product van hoge kwaliteit dat gebruikers kunnen gebruik maken

STLC

  • Focus op het testen van een product
  • Een kind van SDLC proces
  • Inzicht in de ontwikkeling vereisten en te zorgen dat het product werkt zoals verwacht
  • STLC fasen start na de fasen van de SDLC zijn ingevuld
  • Eind doel is het vinden van bugs in het product en verslag naar het ontwikkelteam voor bugfix

Dit zijn de basisverschillen tussen SDLC en STLC. Nu, laten we begrijpen STLC in de diepte.

Wat Is de rol van STLC?

nu we de kern hebben van wat de software testing life cycle is, laten we eens kijken waarom het essentieel is. Zelfs als een bedrijf de beste programmeurs en ontwikkelaars heeft, zijn ze gebonden om fouten te maken. De belangrijkste rol van STLC is om die fouten te vinden en ze vast te krijgen. Het belangrijkste doel van het uitvoeren van een STLC is om de kwaliteit van het product te behouden.

voorbij zijn de dagen dat middelmatige tests de trend waren. In de wereld van vandaag, bedrijven nodig hebben om gedetailleerde testen uit te voeren.

van planning en onderzoek tot uitvoering en onderhoud speelt elke fase een cruciale rol bij het testen van een product.

SDLC draait om het waarborgen van de kwaliteit van het product. Elke toepassing heeft verschillende kenmerken, zoals betrouwbaarheid, functionaliteit en prestaties. En STLC helpt bij het verbeteren van deze attributen en vergemakkelijkt de levering van een ideaal eindproduct.

een product van hoge kwaliteit resulteert op lange termijn in lagere onderhoudskosten. De stabiliteit van een applicatie of software is een must om nieuwe gebruikers te verleiden. Daarnaast helpen consequent betrouwbare producten ook om bestaande klanten te behouden. Voor een product om te blijven in het domein van het bedrijfsleven, is het belangrijk om zich te concentreren op elke fase van de STLC.

fases of Software Testing Life Cycle

valideren van elke module software of toepassing is een must om product precisie en nauwkeurigheid te garanderen. Aangezien software testen zelf een uitgebreid proces is, voeren testers het uit in fasen. Complexiteiten kunnen pop-up als het testen ontbreekt organisatie. De complexiteit kan bestaan uit onopgeloste bugs, onopgemerkt regressie bugs, of in het ergste geval, een module die het testen overgeslagen omdat de deadline dichterbij kwam.

elke fase van de STLC heeft een specifiek doel en deliverables. Het omvat de initiatie, uitvoering en beëindiging van het testproces.

laten we de verschillende fasen van de levenscyclus van de software testen in detail bekijken.

Requirement Analysis

uw waardevolle software testers moeten de beschikbare specificaties en vereisten bekijken, bestuderen en analyseren. Bepaalde vereisten leiden tot resultaten door ze te voeden met inputgegevens. Deze eisen zijn testbare eisen. Testers bestuderen zowel functionele als niet-functionele eisen. Daarna, ze moeten kiezen uit testbare eisen.

activiteiten in deze fase omvatten brainstormen voor vereisten analyse en het identificeren en prioriteren van testvereisten. Zij omvatten ook het uitkiezen van eisen voor zowel geautomatiseerde als handmatige tests.

er zijn een paar dingen die je hebt getest, zelfs als ze niet expliciet worden genoemd. Een klik op een actieve knop moet iets doen, een tekstveld voor telefoonnummer moet niet alfabetten ingediend accepteren. Deze dingen zijn universeel en moeten altijd worden getest. Maar in de fase van de vereiste analyse het over het kennen van meer specifieke details over het product. Je moet leren hoe het product in zijn ideale staat moet zijn.

om het samen te vatten:

  • begrijp de verwachte output van het product.
  • Identificeer eventuele lacunes in de specificaties.
  • Verzamel prioriteiten.
  • voer haalbaarheidscontroles voor automatisering uit.

Testplanning

de tweede stap is testplanning en het QA-team maakt dit plan na analyse van alle noodzakelijke testvereisten. Ze schetsen de reikwijdte en doelstellingen na het begrijpen van het productdomein. Het team analyseert vervolgens de betrokken risico ’s en definieert tijdschema’ s en testomgevingen om een strategie te creëren.

daarna maakt het management de tools af en wijst het rollen en verantwoordelijkheden toe aan individuen. Er wordt ook een geschatte tijdlijn gedefinieerd waarmee het testen van elke module moet worden voltooid.

om het samen te vatten:

  • documentatie van het testplan opstellen.
  • geschatte tijd en inspanningen.
  • afronden op tools en platform.
  • wijs taken toe aan teams en individuen.
  • Identificeer opleidingseisen

ontwerp en ontwikkeling van testcases

na ontwikkeling en planning is het tijd om de creatieve sappen te laten stromen! Op basis van het testplan ontwerpen en ontwikkelen testers testcases. Testcases moeten uitgebreid zijn en moeten bijna alle mogelijke gevallen bestrijken. Alle van toepassing zijnde permutaties en combinaties moeten worden verzameld. U kunt deze testgevallen prioriteren door te onderzoeken welke van hen het meest voorkomen of welke van hen het product het meest zou beïnvloeden.

vervolgens komt de verificatie en validatie van gespecificeerde vereisten in de documentatiefase. Ook het herzien, updaten en goedkeuren van automatiseringsscripts en testcases zijn essentiële processen van deze fase. Deze fase omvat ook het definiëren van verschillende testomstandigheden met inputgegevens en verwachte resultaten.

om het samen te vatten:

  • onderzoek en verzamel mogelijke acties op het product.
  • maak testcases aan.
  • prioriteit geven aan testgevallen.
  • maak geautomatiseerde scripts voor testcases.

testomgeving Setup

testactiviteiten hebben bepaalde omgevingsfactoren nodig—zoals servers, frameworks, hardware en software—voor het uitvoeren van ontwikkelde testcases. Software-en hardwareconfiguratie, samen met het instellen van testgegevens, zijn de belangrijkste componenten van deze fase. En het is verplicht om te testen en om uw testers uit te rusten met bug reporting tools.

in de ontwikkelaarsgemeenschap is het gebruikelijk om te horen “het liep op mijn systeem, maar het draait niet op het jouwe”. Daarom is het belangrijk dat uw testomgeving alle omgevingen bestrijkt die de gebruiker zou gebruiken.

bijvoorbeeld, een functie die werkt in Google Chrome werkt niet in Internet Explorer. De werking van functies verschilt ook op basis van software-en hardwarevereisten. Een functie werkt mogelijk soepel op 4 GB RAM, maar kan problemen veroorzaken met 1 GB RAM. Onderzoek naar omgevingen die door eindgebruikers worden gebruikt, zou u helpen prioriteiten te stellen aan uw testomgevingen.

Het is de taak van de QA manager die toezicht houdt op het team om te zorgen voor het opzetten van de testomgeving.

om het samen te vatten:

  • begrijp minimumvereisten
  • Toon software en hardware die nodig zijn voor verschillende prestatieniveaus.
  • prioriteer testomgevingen
  • Setup testomgevingen
  • rooktest de gebouwde omgevingen

uitvoering van de Test

een toepassing is klaar om te testen zodra het team alle voorgaande fasen heeft doorlopen. Volgens het testplan voeren de testers testcases uit. Ze identificeren, detecteren en loggen ook de defecten, waardoor ze de bugs rapporteren. Het team is ook verantwoordelijk voor het vergelijken van de verwachte resultaten met de werkelijke resultaten. Als er fouten worden gevonden, moeten ze worden gedocumenteerd om het door te geven aan het ontwikkelteam voor een oplossing.

zodra het ontwikkelteam een bug verwijdert, begint het regressieonderzoek. Regressie testen is om ervoor te zorgen dat de software of toepassing werkt, zelfs na het implementeren van een wijziging. Bij het testen na een bug fix, test het volledige product opnieuw. Omdat een fix voor een bug een bug kan maken op een ander deel van het product. En omdat dezelfde tests opnieuw en opnieuw moeten worden uitgevoerd na elke fix en implementatie, is het raadzaam om scripts of geautomatiseerde testtools te gebruiken.

om het samen te vatten:

  • testgevallen uitvoeren.
  • bepaal de afwijking van het verwachte gedrag van het product.
  • log mislukte gevallen met details
  • Test opnieuw na bugfixes.

Testsluiting

en dat brengt ons bij de laatste fase van de STLC: testsluiting.

het einde van de uitvoering van de test en de levering van het eindproduct markeert het begin van de sluitingsfase van de test. Het QA team controleert de testresultaten en bespreekt deze met andere teamleden. Enkele andere factoren die zij overwegen zijn productkwaliteit, test dekking, en projectkosten. Als er een afwijking is van de geschatte waarden, kunnen verdere analyses worden gedaan om te identificeren wat niet ging zoals verwacht.

Het is een essentiële praktijk voor testers om samen te komen en de conclusie na het testen te bespreken. Eventuele problemen tijdens het testen, fouten in strategieën kunnen hier worden besproken. U kunt ook werken aan het bedenken van een betere aanpak voor het testen op basis van de lessen tijdens het testen. Als u DevOps of canary release praktijk te volgen, testen is frequent. U kunt zelf bepalen hoe vaak u rapporten verzendt en welke gegevens u moet vermelden tijdens het verzenden van rapporten naar verschillende stakeholders.

afgezien daarvan houdt het team zich ook bezig met testmetrics, de vervulling van doelen en hun naleving van deadlines. Zodra ze een totaal begrip hebben van wat er gebeurd is, kunnen ze de hele teststrategie en het hele proces evalueren.

om het samen te vatten:

  • Controleer of alle tests zijn voltooid.
  • evalueer factoren zoals kwaliteit, testdekking, tijdlijn en kosten.
  • documenteer de conclusie.
  • bespreek het leren en ontdek of het testproces kan worden verbeterd.
  • Testafsluitingsverslag opstellen.

Wat zijn de in-en Uitstapcriteria voor tests?

alle zes fasen van een levenscyclus voor het testen van software hebben entry-of exitcriteria. Testers moeten de uitvoering van de testcases binnen een vaste tijd voltooien. Ook moeten ze de kwaliteit, functionaliteit en efficiëntie van het eindproduct te behouden. Daarom is het een must om inreis-en uitreiscriteria vast te stellen. Dat gaan we nu doen.

Entry Criteria

Entry criteria geef aan op welke eisen het team moet letten voordat de testprocedure wordt gestart. Voordat het testen begint, is het verplicht om alle vereisten te schrappen.

Er zijn enkele lopende activiteiten en omstandigheden die aanwezig moeten zijn voordat de test begint. Eerst heb je input nodig van het ontwikkelingsteam. U zult ook het testplan, testcases en gegevens, de testomgeving en uw code willen onderzoeken.

Exitcriteria

Exitcriteria vermeld de vereisten en acties die moeten worden uitgevoerd voordat de test wordt beëindigd. Met andere woorden, ze bevatten items om de takenlijst en processen te voltooien voordat het testen tot stilstand komt.

Exitcriteria omvatten de identificatie van defecten met hoge prioriteit. Die moet je meteen laten maken. Testers moeten verschillende testcases doorstaan en zorgen voor volledige functionele dekking.

conclusie

het eenvoudig identificeren van fouten in de laatste fase van een SDLC is geen efficiënte praktijk meer. Er zijn verschillende andere dagelijkse activiteiten van een bedrijf heeft om zich te concentreren op. Te veel van uw kostbare tijd besteden aan het testen en repareren van bugs kan de efficiëntie belemmeren. Immers, u zult meer tijd nemen om minder output te genereren.

om het testproces te vergemakkelijken, is het belangrijk om efficiënt gebruik te maken van tijd en middelen. Na een systematische STLC niet alleen resulteert in een snelle bug fixing, maar het verbetert ook de kwaliteit van het product. Door het verhogen van de klanttevredenheid, zult u genieten van een verhoogde ROI en verbeterde aanwezigheid van het merk.

Dit bericht is geschreven door Arnab Roy Chowdhury. Arnab is een UI ontwikkelaar van beroep en een blogging liefhebber. Hij heeft een sterke expertise in de laatste UI / UX trends, Project methodologieën, testen en scripting.

Wat moet ik nu lezen

Wat is shift Left Testing? Een gids voor het verbeteren van uw QA