Agile-methodologie bij het testen van software

Agile methodologie

Wat is Agile-methodologie bij testen?

Agile Methodologie betekent een praktijk die promotes continue iteratie van ontwikkeling en testen gedurende de gehele levenscyclus van de softwareontwikkeling van het project. In het Agile-model bij het testen van software vinden zowel ontwikkelings- als testactiviteiten gelijktijdig plaats, in tegenstelling tot het Waterval-model.

Agile methodologie
Agile methodologie

Wat is agile softwareontwikkeling?

Het Agile softwareontwikkeling methodologie is een van de eenvoudigste en effectiefste processen om een ​​visie voor een bedrijfsbehoefte om te zetten in softwareoplossingen. Agile is een term die wordt gebruikt om softwareontwikkelingsbenaderingen te beschrijven die gebruik maken van voortdurende planning, leren, verbeteren, teamsamenwerking, evolutionaire ontwikkeling en vroege levering. Het moedigt flexibele reacties op veranderingen aan.

De agile softwareontwikkeling legt de nadruk op vier kernwaarden.

  1. Individuele en teaminteracties over processen en hulpmiddelen
  2. Werkende software via uitgebreide documentatie
  3. Samenwerking met klanten boven contractonderhandelingen
  4. Reageren op verandering via following een plan

Agile model versus watervalmodel

Agile en Waterfall-model zijn twee verschillende methoden voor het softwareontwikkelingsproces. Hoewel ze verschillend zijn in hun aanpak, zijn beide methoden soms nuttig, afhankelijk van de vereisten en het type project.

Agile model Waterval model
Agile-methodologie bij het testen van software: Agile-methodologieën stellen een incrementele en iteratieve benadering van softwareontwerp voor Watervalmodel: De ontwikkeling van de software verloopt opeenvolgend van beginpunt tot eindpunt.
Het Agile proces bij het testen van software wordt opgesplitst in individuele modellen waaraan ontwerpers werken Het ontwerpproces is niet opgedeeld in individuele modellen
De klant heeft vroegtijdige en frequente mogelijkheden om naar het product te kijken en beslissingen te nemen en wijzigingen in het project aan te brengen Pas aan het einde van het project kan de klant het product zien
Het Agile-model bij testen wordt als ongestructureerd beschouwd in vergelijking met het watervalmodel Het watervalmodel is veiliger omdat ze zo planmatig zijn
Kleine projecten kunnen zeer snel worden uitgevoerd. Bij grote projecten is het moeilijk de ontwikkeltijd in te schatten. Allerlei soorten projecten kunnen worden geschat en voltooid.
Fouten kunnen halverwege het project worden verholpen. Pas aan het einde wordt het hele product getest. Als de vereiste fout wordt gevonden of als er wijzigingen moeten worden aangebracht, moet het project vanaf het begin beginnen
Het ontwikkelingsproces is iteratief en het project wordt uitgevoerd in iteraties van korte (2-4) weken. Plannen is heel weinig. Het ontwikkelingsproces is gefaseerd en de fase is veel groter dan iteratie. Elke fase eindigt met de gedetailleerde beschrijving van de volgende fase.
Documentatie heeft minder prioriteit dan software development Documentatie heeft de hoogste prioriteit en kan zelfs worden gebruikt voor het trainen van personeel en het upgraden van de software met een ander team
Elke iteratie kent zijn eigen testfase. Het maakt het mogelijk om regressietests te implementeren telkens wanneer nieuwe functies of logica worden vrijgegeven. Pas na de ontwikkelfase wordt de testfase uitgevoerd omdat losse onderdelen nog niet volledig functioneel zijn.
Bij agile testen worden, wanneer een iteratie eindigt, verzendbare functies van het product aan de klant geleverd. Nieuwe functies zijn direct na verzending bruikbaar. Het is handig als je goed contact hebt met klanten. Alle ontwikkelde features worden na de lange implementatiefase in één keer opgeleverd.
Testers en ontwikkelaars werken samen Testers werken gescheiden van ontwikkelaars
Aan het einde van elke sprint, wordt gebruikersacceptatie uitgevoerd Gebruikersacceptatie is uitgevoerd aan het einde van het project.
Het vereist nauwe communicatie met ontwikkelaars en samen de vereisten en planning analyseren De ontwikkelaar is niet betrokken bij het vereisten- en planningsproces. Meestal zijn er tijdsvertragingen tussen tests en codering

Controleer ook: - Agile versus waterval: ken het verschil tussen methodologieën

Agile proces

Controleer het onderstaande Agile methodologie proces om snel succesvolle systemen te leveren.

Agile procesmodel
Agile procesmodel

Er zijn verschillende Agile methoden aanwezig in agile testen, en deze worden hieronder vermeld:

Worsteling om de bal

SCRUM is een agile ontwikkelmethode die zich specifiek richt op het beheren van taken binnen een teamgebaseerde ontwikkelomgeving. Kortom, Scrum is afgeleid van de activiteit die plaatsvindt tijdens een rugbywedstrijd. Scrum gelooft in het versterken van het ontwikkelteam en pleit voor het werken in kleine teams (bijvoorbeeld 7 tot 9 leden). Agile en Scrum bestaan ​​uit drie rollen, waarvan de verantwoordelijkheden als volgt worden uitgelegd:

Scrum-methode
Scrum-methode
  • Scrum Master
    • Scrum Master is verantwoordelijk voor het opzetten van het team, sprint ontmoeten en obstakels voor vooruitgang wegnemen
  • Product eigenaar
    • De Product Owner creëert product backlog, prioriteert de backlog en is verantwoordelijk voor het leveren van de functionaliteit bij elke iteratie
  • Scrum-team
    • Het team beheert zijn eigen werk en organiseert het werk om het project te voltooien sprint of cyclus

Productachterstand

Dit is een repository waar vereisten worden bijgehouden met details over het aantal vereisten (user stories) dat voor elke release moet worden ingevuld. Het moet worden onderhouden en geprioriteerd door de Product Owner, en moet worden gedistribueerd naar het scrumteam. Het team kan ook verzoeken om een ​​nieuwe vereistetoevoeging, wijziging of verwijdering

Scrum-praktijken

De praktijken worden gedetailleerd beschreven:

Scrum-praktijken
Scrum-praktijken

Processtroom van Scrum-methodologieën:

Processtroom van scrum-testen is als volgt:

  • Elke iteratie van een scrum staat bekend als Sprint
  • Product backlog is een lijst waar alle details worden ingevoerd om het eindproduct te verkrijgen
  • tijdens elke Sprint, worden de beste gebruikersverhalen van Product backlog geselecteerd en omgezet Sprint achterstand
  • Team werkt aan het gedefinieerde sprint achterstand
  • Teamcontroles voor de dagelijkse werkzaamheden
  • Aan het einde van de sprint, team levert productfunctionaliteit

Extreem programmeren (XP)

De Extreme Programming-techniek is erg handig als er voortdurend veranderende eisen of eisen zijn van de klanten of als ze niet zeker zijn over de functionaliteit van het systeem. Het pleit voor frequente “releases” van het product in korte ontwikkelingscycli, wat de productiviteit van het systeem inherent verbetert en ook een controlepunt introduceert waar eventuele klantvereisten eenvoudig kunnen worden geïmplementeerd. De XP ontwikkelt software die de klant binnen het doel houdt.

Extreem programmeren
Extreem programmeren

Bedrijfsbehoeften worden verzameld in termen van verhalen. Al die verhalen worden opgeslagen op een plek die de parkeerplaats wordt genoemd.

In dit type methodologie zijn releases gebaseerd op de kortere cycli, iteraties genaamd, met een tijdsperiode van 14 dagen. Elke iteratie omvat fasen zoals coderen, testen van eenheden en systeemtesten, waarbij in elke fase een kleine of grote functionaliteit in de applicatie wordt ingebouwd.

Fasen van eXtreme-programmering:

Er zijn 6 fasen beschikbaar in de Agile XP-methode, en deze worden als volgt uitgelegd:

Planning

  • Identificatie van belanghebbenden en sponsors
  • Infrastructuurvereisten
  • Security gerelateerde informatie en verzameling
  • Service Level Agreements en de voorwaarden daarvan

Analyse

  • Verhalen vastleggen op de parkeerplaats
  • Geef prioriteit aan verhalen op de parkeerplaats
  • Schrobben van verhalen voor schatting
  • Iteratiespanne (tijd) definiëren
  • Resourceplanning voor zowel ontwikkelings- als QA-teams

Design

  • Uitsplitsing van taken
  • Voorbereiding van testscenario's voor elke taak
  • Regressie-automatiseringsframework

Uitvoering

  • codering
  • Uitvoeren van handmatige testscenario's
  • Foutrapport genereren
  • Conversie van handmatige naar automatiseringsregressietestgevallen
  • Mid-iteratie beoordeling
  • Einde van de iteratiebeoordeling

Omhulsel

  • Kleine uitgaven
  • Demo's en recensies
  • Ontwikkel nieuwe verhalen op basis van de behoefte
  • Procesverbeteringen op basis van opmerkingen aan het einde van de iteratiebeoordeling

Closure

  • Pilot lancering
  • Trainingen
  • Productie lancering
  • SLA-garantiegarantie
  • SOA-strategie herzien
  • Production Support

Er zijn twee storyboards beschikbaar om het werk dagelijks te volgen, en deze worden hieronder ter referentie vermeld.

  • Verhaalkarton
    • Dit is een traditionele manier om alle verhalen op een bord te verzamelen in de vorm van notities om de dagelijkse XP-activiteiten bij te houden. Omdat deze handmatige activiteit meer moeite en tijd kost, kunt u beter overstappen op een online formulier.
  • Online storyboard
    • Online tool Storyboard kan gebruikt worden om de verhalen op te slaan. Meerdere teams kunnen er gebruik van maken voor verschillende doeleinden.

Crystal Methodologieën

Crystal Methodology is gebaseerd op drie concepten

  1. charteren: Verschillende activiteiten die in deze fase betrokken zijn, zijn het samenstellen van een ontwikkelteam, het uitvoeren van een voorlopige haalbaarheidsanalyse, het ontwikkelen van een eerste plan en het verfijnen van de ontwikkelingsmethodologie.
  2. Cyclische levering: De hoofdontwikkelingsfase bestaat uit twee of meer opleveringscycli, waarin de
    1. Het team werkt het releaseplan bij en verfijnt het
    2. Implementeert een subset van de vereisten via een of meer programmatestintegratie-iteraties
    3. Geïntegreerd product wordt geleverd aan echte gebruikers
    4. Review van het projectplan en vastgestelde ontwikkelmethodiek
  3. Afronden: De activiteiten die in deze fase worden uitgevoerd zijn de implementatie in de gebruikersomgeving, beoordelingen na de implementatie en reflecties.

Dynamische softwareontwikkelingsmethode (DSDM)

DSDM is een Snelle applicatieontwikkeling (RAD) benadering van softwareontwikkeling en biedt een agile raamwerk voor projectoplevering. Het belangrijke aspect van DSDM is dat de gebruikers actief betrokken moeten worden en dat de teams de macht krijgen om beslissingen te nemen. Frequente levering van producten wordt de actieve focus bij DSDM. De technieken die in DSDM worden gebruikt zijn

  1. Tijd BoxING
  2. MoSCoW-regels
  3. Prototyping

Het DSDM-project bestaat uit 7 fases

  1. Voorproject
  2. Haalbaarheidsstudie
  3. Bedrijfsstudie
  4. Functionele modeliteratie
  5. Ontwerp en bouw iteratie
  6. Implementatie
  7. Post-project

Functiegestuurde ontwikkeling (FDD)

Deze methode is gericht op het “ontwerpen en bouwen” van functies. In tegenstelling tot andere Agile-methoden in software-engineering beschrijft FDD zeer specifieke en korte werkfasen die afzonderlijk per functie moeten worden uitgevoerd. Het omvat domeinrondleiding, ontwerpinspectie, promote bouwen, code-inspectie en ontwerp. FDD ontwikkelt producthoudfollowing dingen in het doel

  1. Domeinobjectmodellering
  2. Ontwikkeling per functie
  3. Component-/klasse-eigendom
  4. Functieteams
  5. Inspecties
  6. Configuration Management
  7. Regelmatige constructies
  8. Zichtbaarheid van voortgang en resultaten

Lean softwareontwikkeling

De lean softwareontwikkelingsmethode is gebaseerd op het principe ‘Just in time production’. Het is gericht op het verhogen van de snelheid van softwareontwikkeling en het verlagen van de kosten. Lean ontwikkeling kan worden samengevat in zeven stappen.

  1. Afval elimineren
  2. Het versterken van het leren
  3. Afspraak uitstellen (zo laat mogelijk beslissen)
  4. Vroege levering
  5. Het team sterker maken
  6. Integriteit opbouwen
  7. Optimaliseer het geheel

Kanban

Kanban oorspronkelijk voortgekomen uit het Japanse woord dat een kaart betekent met alle informatie die in elke fase van het pad naar voltooiing aan het product moet worden gedaan. Dit raamwerk of deze methode wordt behoorlijk overgenomen in de softwaretestmethode, vooral in Agile-concepten.

Scrum versus Kanban

Worsteling om de bal Kanban
Bij scrumtechniek moeten de tests worden opgesplitst, zodat ze in één keer kunnen worden voltooid sprint Er is geen specifieke artikelgrootte voorgeschreven
Schrijft een geprioriteerde productbacklog voor Prioritering is optioneel
Het Scrumteam verplicht zich tot een bepaalde hoeveelheid werk voor de iteratie Toezegging is optioneel
Burndown-grafiek wordt voorgeschreven Er is geen specifieke artikelgrootte voorgeschreven
Tussen elk sprint, wordt een scrumbord gereset Een Kanban-bord is persistent. Het beperkt het aantal items in de workflowstatus
Er kunnen geen items worden toegevoegd aan de lopende iteratie Het kan items toevoegen wanneer er capaciteit beschikbaar is
WIP indirect beperkt WIP direct beperkt
Tijdboxed iteraties voorgeschreven Tijdboxed iteraties optioneel

Controleer ook: - Kanban versus. Scrum: wat is het verschil?

Agile-statistieken

Metrieken die kunnen worden verzameld voor effectief gebruik van Agile zijn:

  • weerstandsfactor
    • Inspanning in uren die niet bijdragen aan sprint doel
    • De belemmeringsfactor kan worden verbeterd door het aantal gedeelde bronnen te verminderen, waardoor de hoeveelheid niet-bijdragend werk wordt verminderd
    • Nieuwe schattingen kunnen worden verhoogd met het percentage sleepfactor -Nieuwe schatting = (oude schatting+sleepfactor)
  • Snelheid
    • Hoeveelheid backlog (user stories) geconverteerd naar leverbare functionaliteit van sprint
  • Aantal eenheidstests toegevoegd
  • Tijdsinterval dat nodig is om de dagelijkse build te voltooien
  • Bugs gedetecteerd in een iteratie of in eerdere iteraties
  • Lekkage bij productiefouten