Menu

Praktische implementatie in 7 stappen van handmatige tests voordat de productie wordt vrijgegeven

7 step practical implementation manual testing before production release

Probeer Ons Instrument Voor Het Oplossen Van Problemen

In de vorige post van deze serie over handmatig testen, heb ik geprobeerd zoveel mogelijk licht te werpen op de basisprincipes van handmatig testen.

Als je het gemist hebt, je kunt het hier lezen ​

Ik hoop dat het erin is geslaagd u zo dicht mogelijk bij de antwoorden te brengen waarnaar u op zoek was.

Zou u in dat geval niet graag meer willen weten over de praktische implementatie van Manual Testing, hoe u er meer vertrouwd mee raakt en hoe u er daadwerkelijk een carrière in kunt beginnen?

Dit artikel belicht al deze aspecten.

Implementatie van handmatig testen

Laten we beginnen.

Wat je leert:

Handmatige testcyclus

Begrijpen Handmatige testcyclus of Software Test Life Cycle (STLC), allereerst moeten we de Software Development Life Cycle (SDLC) begrijpen, waarvan ik zeker weet dat u er al kennis van hebt.

Mensen verwijzen er afzonderlijk naar, maar weten niet zeker of ze echt naast elkaar kunnen bestaan. Ze zijn zo nauw met elkaar geïntegreerd. Welnu, zelfs van deze cycli zijn er zoveel versies gemaakt en zwevend in de internetruimte, ze variëren sterk op basis van het ontwikkelingsmodel dat wordt geselecteerd.

Zoals de meeste de wereld wordt Agile tegenwoordig houd ik mijn spullen vereenvoudigd rond Agile.

7 Praktische handmatige teststappen voordat de productie wordt vrijgegeven

Hier ga ik.

Onthoud dat ik het heb over zowel SDLC als STLC.

# 1) Verzamelen van vereisten

Vereiste Verzamelfase

Business Analist (Persoon / Team verantwoordelijk voor Requirement Gathering) documenteert de requirements. Ze documenteren de vereisten, dat is het hoogtepunt, u kunt de focus alleen daarop houden. Waar het is gedocumenteerd, doet er minder toe.

Mensen gebruiken alles om deze te documenteren dat bij hen past, maar niet beperkt tot traditionele platforms zoals MS Word Doc, moderne platforms zoals Jira / Rally en new age-tools zoals Trello.

# 2) Vereiste discussie / delen

Vereiste discussiefase

De bedrijfsanalist moet vervolgens de gedocumenteerde vereisten delen met het ontwikkelteam, het testteam en het UX-team (indien nodig). Dit gebeurt meestal via een formele vergadering waar SPOC's (Single Point Of Contacts of een heel team, het hangt ervan af) van alle drie de functies voldoen aan en de volledige vereiste begrijpen.

In een gezonde werkcultuur worden vereisten vanuit elke hoek besproken en kan elk lid van de vergadering vragen en twijfels stellen. Zodra alle vragen zijn beantwoord en de vereiste aanpassing in de vereiste is voltooid, kan deze fase als Gereed worden beschouwd. Nogmaals, wat men deze specifieke vergadering / stap en de documentatie ervan noemt, verschilt van bedrijf tot bedrijf.

Verder lezen​ SRS-document bekijken

Zodra alle vragen zijn beantwoord en de benodigde wijzigingen in de vereiste zijn doorgevoerd, kan deze fase worden beschouwd als Gedaan ​

Nogmaals, wat men deze specifieke vergadering / stap en de documentatie ervan noemt, verschilt van bedrijf tot bedrijf.

Bijvoorbeeld, de documentatie wordt genoemd of wordt afgebroken als SRS (System Requirement Specification), Requirement Document, Epic, User Story, Story point (mogelijk kleinste vereiste-eenheid), etc. Op dezelfde manier wordt deze meeting waarin de vereiste wordt gedeeld, genoemd als Vereiste Discussievergadering, Verzorging, Hole-punching-bijeenkomst, enz., Ik hoop dat u begrijpt wat ik bedoel?

Druk op deze terminologieën zodat u altijd het hoofdidee onthoudt, ongeacht de verschillende namen.

Na deze vergadering worden twee stappen tegelijkertijd geactiveerd, in willekeurige volgorde, verwijs de volgende twee stappen.

# 3) Ontwerpen

Het ontwikkelteam begint met het technische ontwerp zodra de vereisten zijn besproken en er geen grote hangende punten zijn. Wat er in deze fase gedaan wordt, verschilt weer van bedrijf tot bedrijf.

Deze fase kan de volgende taken omvatten, maar is niet beperkt tot:

  • Bepalen van de ontwikkelingsaanpak
  • Ontwerpdocument voorbereiden
  • Ontwerpen van de stroomschema's
  • De inspanningen inschatten
  • De impact van deze nieuwe vereiste op bestaande functionaliteit uitzoeken
  • Moet bestaande gegevens patchen, enz.

Het UX-team kan ook in deze fase worden betrokken wanneer er een UI-wijziging is of een nieuw scherm moet worden ontwikkeld. Het UX-team helpt het ontwikkelingsteam en het testteam met UI-prototype voor de functionaliteit / functie in de discussie. Dit kan een Photoshop-document, eenvoudige afbeelding, PowerPoint-presentatie of iets anders zijn waardoor het ontwikkelteam begrijpt hoe de schermen moeten worden ontwikkeld.

Notitie​ Idealiter worden deze schermen, of in ieder geval hun conceptversies, alleen weergegeven in de discussiesessie over vereisten om het team te helpen een beter begrip op te bouwen. Het wordt getagd naar de oorspronkelijke vereiste, zodat er op elk moment naar kan worden verwezen.

# 4) Testscenario / Testcase ontwerpen

Testscenario Ontwerpfase

Parallel aan de ontwerpfase begint het testteam met het bouwen van testscenario's en / of testcases op basis van besproken eisen. Of testscenario's altijd eerst worden geschreven en vervolgens in testcases worden onderverdeeld, is weer niet constant.

Naar mijn mening, of je nu de testscenario's documenteert of niet, ze zijn er altijd voor testgevallen. Testscenario is uw punt dat u kunt zeggen, ze begeleiden u om dingen verder te analyseren. Zodra het schrijven van de testcase is voltooid, kan deze worden gedeeld met het ontwikkelteam om hen een idee te geven van de testomvang en kunnen ze er ook voor zorgen dat de ontwikkeling die heeft plaatsgevonden of plaatsvindt, voldoet aan de schriftelijke testcases.

Zodra het schrijven van de testcase is voltooid, kan deze worden gedeeld met het ontwikkelteam om hen een idee te geven van de testomvang en kunnen ze er ook voor zorgen dat de ontwikkeling die heeft plaatsgevonden of plaatsvindt, voldoet aan de schriftelijke testcases.

Testcases die eenmaal zijn geschreven, worden idealiter beoordeeld door een testleider of collega vanuit verschillende invalshoeken, zoals:

  • Vereiste dekking
  • Spelling grammatica
  • Testcase-schrijfnormen (niets anders dan een sjabloon dat een team / bedrijf volgt)
  • Achterwaartse compatibiliteit
  • Platform compatibiliteit
  • Test gegevensreferenties
  • Soorten gerichte tests, enz.

Verder lezen​ Testcases schrijven vanuit SRS-document

Idealiter worden ze pas na beoordeling en noodzakelijke aanpassing doorgegeven aan het ontwikkelingsteam.

Toen ik zei ‘zodra het schrijven van testcases voorbij is’, bedoelde ik dat ‘alle testcases zijn geschreven op basis van volledige kennis van de gegeven vereisten en mogelijke testscenario's die tot die tijd zijn ontdekt’. Het is bijna onmogelijk om bij de eerste keer 100% dekking van de testcase te hebben.

Er zullen defecten zijn die u zult vinden in willekeurige (maar bedoelde) acties, in puur willekeurige acties (apen testen) en in sommige zeldzame scenario's. Er is een kans dat u enkele hiervan mist. En op een gegeven moment mis je misschien zelfs heel basale, je bent tenslotte een mens. Maar hier kan in ieder geval een goede testcase review en gestructureerde manier van testcase schrijven je redden.

Vaker wel dan niet, blijft een tester of testteam steeds meer testcases toevoegen aan het bestaande stuk, terwijl ze de waarheid ontdekken of meer nadenken over de vereisten.

Welnu, sommigen van jullie moeten nu twijfelen aan mijn kennis van Software Testing, aangezien een woord (dat een soort norm is geworden in Software Testing) nog niet door mij wordt gebruikt. Testplan toch?

Laat me hier iets over zeggen. Ik geloof sterk in de behoefte aan de meeste informatie die in het testplan wordt genoemd, maar ze allemaal op dezelfde plaats documenteren en absoluut verplicht stellen, vind ik betwistbaar.

Hoe dan ook, dat is helemaal een apart onderwerp om te bespreken. Het is moeilijk om hierover ‘voor iedereen’ informatie te delen, maar laat me het proberen.

Ofwel stelt u, u met uw test lead of uw test lead een testplan op of u documenteert de vereiste informatie op verschillende plaatsen.

Verder lezen​ Hoe een testplan-document te schrijven

Informatie die in dit stadium absoluut moet worden bevroren:

  • De reikwijdte van testen: Vereiste, achterwaartse compatibiliteit, platforms, apparaten, enz.
  • Persoon / Team die gaat testen
  • Testinspanning inschatten
  • Beperkingen: Eventuele aannames of beperkingen die vooraf zijn geaccepteerd.
  • Mensen documenteren bovendien toegangscriteria, exitcriteria, risico, enz. Waarvan ik denk dat ze niet echt apart moeten worden vermeld, omdat het eerder een normaal begrip zou moeten zijn.
    • Toelatingscriteria (Wanneer te beginnen met testen): Weinig start wanneer er een testbaar deel van de functionaliteit beschikbaar is om te testen. Weinigen wachten tot de volledige functionaliteit testbaar is. Zodra blijkt dat de basisstroom werkt, begint het testen.
    • Criteria afsluiten (Wanneer te stoppen): Als er geen blocker is, kunnen kritische en grote (onderhevig aan impact) defecten in open stage testen worden gestopt. Of halverwege, wanneer er veel te veel defecten zijn, kan het testen worden gestopt door de juiste belanghebbenden.
    • Risico : Bedrijfsrisico of functioneel risico als het testen niet gebeurt volgens het gedocumenteerde plan.

# 5) Ontwikkelingsfase

Software ontwikkelingsfase

Het ontwikkelteam begint na de ontwerpfase met de daadwerkelijke ontwikkeling en het testen van eenheden als en wanneer ze klaar zijn met de ontwikkeling van testbare vereiste brokken. Ze kunnen de functionaliteit voor testen in brokken doorgeven als en wanneer deze wordt geïmplementeerd, of ze kunnen de volledige functionaliteit in één keer doorgeven.

In een ideaal scenario vinden formele codebeoordeling en white box-testen plaats voordat de ontwikkelde functionaliteit wordt doorgegeven aan testen. Idealiter zou het ontwikkelingsteam naast de vereisten en ontwerpdocumenten ook moeten verwijzen naar testcases die door het testteam zijn verstrekt.

# 6) Testfase

Zoals eerder vermeld, verschilt de start van deze fase van bedrijf tot bedrijf, van team tot team.

Het testteam begint met testen wanneer testbaar (iets dat onafhankelijk kan worden getest) een deel van de volledige eis is ontwikkeld of wanneer de volledige eis is ontwikkeld.

Java-interviewcode vragen en antwoorden

Laat me verder in deze fase inzoomen en praten over de belangrijke taken:

  • Tester / Testteam start met testronde (verkennend testen en uitvoeren van schriftelijke testcases) en vastleggen van defecten
  • Het ontwikkelteam lost ze op volgens prioriteit.
  • Nieuwbouw (code) wordt gemaakt op de omgeving waarop wordt getest
  • Opgeloste defecten worden vervolgens geverifieerd door het tester / testteam en gemarkeerd als opgelost
  • Deze cyclus gaat door totdat het tijdsverloopcriterium is bereikt.
  • Houd er rekening mee dat defecten, indien nodig, ook worden gemarkeerd als ongeldig, duplicaat en ook kunnen worden gecategoriseerd als verbeteringen.

Een ander ding dat van bedrijf tot bedrijf verschilt, is het aantal testrondes dat moet worden gedaan. Zoals in sommige gevallen, vindt de eerste testronde plaats op kleine onderdelen zodra ze klaar zijn, gevolgd door een end-to-end testronde in een andere omgeving zodra alle vereisten zijn ontwikkeld. Maar nogmaals, ik heb ook gehoord dat mensen drie volledige testrondes deden en de vierde ronde als gezond verstand / rook.

De eerste agenda achter het doen van meerdere testrondes is het testen van de functionaliteit in verschillende omgevingen en ten tweede voor het uitvoeren van end-to-end testen zodra alle verhaalpunten zijn ontwikkeld. Sanity-ronde krijgt meestal snel vertrouwen als alle verhalen in een release onafhankelijk zijn ontwikkeld en getest.

Lees gedetailleerde stappen​ Test Uitvoeringsfase

# 7) Beoordeling door bedrijfsanalisten (BA)

Bedrijfsanalisten beoordelen de gevraagde functionaliteit door te verwijzen naar het testresultaat of door te verwijzen naar het testresultaat en door met de applicatie te spelen om een ​​echt gevoel te krijgen. Deze stap is opnieuw onderworpen aan verschillende acties tussen bedrijven.

De BA kan de reikwijdte van de volledige release in één keer of in stukjes bekijken. Afhankelijk van hetzelfde, kan deze stap plaatsvinden vóór de laatste geestelijke gezondheidstest of na de laatste geestelijke gezondheidstest door het testteam.

De bovenstaande 7 stappen gebeuren voor alle gebruikersverhalen / vereisten waaraan moet worden voldaan, in het bijzonder Release (verzending). Zodra al deze stappen zijn voltooid voor alle vereisten, is de release klaar voor verzending.

# 8) Verzending / vrijgave

De release is getagd als Klaar voor verzending na een succesvolle beoordeling door de Business Analyst.

Aanbevolen om te lezen​ Test vrijgaveproces

Soorten handmatige (lees menselijke) tests

Als we het moeten hebben over algemene soorten testen in cijfers, dan heb ik ergens gevonden 100 soorten testen met verschillende namen ​Om eerlijk te zijn ben ik niet slim genoeg om het onderscheid tussen al deze typen te begrijpen (bedoelde woordspeling).

Het is duidelijk en eenvoudig: Met menselijke inspanningen en intelligentie de functionaliteit van de applicatie toetsen aan de gegeven eis. Het wordt verder onderverdeeld in enkele typen op basis van de reikwijdte en de testagenda. Typen opgesomd in volgende par.

Het wordt verder onderverdeeld in enkele typen op basis van de reikwijdte en de testagenda. Typen opgesomd in volgende par.

Als ik mag, laat me dan een paar regels Human Testing spreken (wat ik elke tester aanmoedig om te doen in plaats van alleen handmatig functioneel testen). Raak nu niet in de war, naar mijn mening is handmatig functioneel testen een subset van menselijke tests. Omdat er zoveel dingen zijn die alleen de menselijke geest kan doen.

Hieronder vindt u de lijst met enkele van de populaire en belangrijke testtypen die kunnen worden onderverdeeld in menselijke tests:

  • Handmatig functioneel testen ​ Met menselijke inspanningen en intelligentie de functionaliteit van de applicatie toetsen aan de gegeven eis. Verder wordt onderverdeeld in een flink aantal typen op basis van de reikwijdte en agenda van testen, zoals systeemtesten, eenheidstesten, rooktesten, gezondheidstesten, integratietesten, regressietesten, UI-testen, etc.
  • Prestatietests ​ Dit wordt gecategoriseerd in niet-functionele tests, toch? Maar nogmaals, het is de mens die het implementeert, hoewel de uitvoering wordt gedaan door mens of gereedschap. De tester zou deze test in ieder geval moeten doen in termen van reactietijd (om te zien of het acceptabel is) als hij geen tool mag gebruiken voor het testen van de belasting en zo.
  • Browser / Platform compatibiliteitstesten: De te testen applicatie moet eruitzien en werken zoals verwacht (er kan uiteraard een klein verschil zijn, afhankelijk van de browser-engine) tussen browsers en platforms (of apparaten als het een mobiele applicatie is).
  • Bruikbaarheidstesten ​ Allereerst ben ik het ermee eens dat dit een enorm onderwerp op zich is en meestal eigendom is van specialisten in bruikbaarheidstests. Ik ben nog steeds van mening dat we als tester op zijn minst moeten rapporteren of markeren als we iets als minder bruikbaar vinden, of we moeten onze mening delen.
  • Beveiligingstests ​ Wederom een ​​enorm testtype en vereist natuurlijk veel praktische kennis. De tester moet proberen om op zijn minst basistests te leren en uit te voeren, zoals URL-sabotage, Cross-site scripting, SQL-injectie, Sessie-kaping, enz. Afhankelijk van de beschikbare kennis en waar van toepassing.
  • Multi-tenancy testen: Als uw applicatie multi-tenant is, d.w.z. een enkele instantie met gegevens van meerdere clients, dan is dit testen een must. Dit moet gebeuren, ongeacht of dit expliciet in de vereisten wordt vermeld. De gegevens van de ene klant die aan de andere wordt getoond, is een soort ontwikkelings- en testmisdaad.

Notitie​ Bovenstaande standpunten zijn mijn persoonlijke opvattingen. Ik raad je ook aan om voor je kennis de uitgebreide lijst met testtypes te bekijken en deze te volgen / gebruiken als je dat nodig vindt. Jarenlang heb ik begrepen dat of je nu iets gebruikt of niet, je gelooft in iets of niet, je nog steeds enige kennis moet hebben van veelgebruikte concepten in je vakgebied.

Dat is alles voor dit deel. Bedankt voor het lezen. Deel uw mening / feedback in opmerkingen.

In het volgende en laatste deel hiervan handleidingen voor handmatig testen , Ik zal proberen jullie allemaal te helpen welke voorbereiding u zou moeten doen als u in het testveld wilt komen en wat zijn mogelijke manieren om daar binnen te komen.

Aanbevolen literatuur

^