Menu

SRS-document bekijken en testscenario's maken - Training voor softwaretests voor een live project - Dag 2

how review srs document

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Dit is de tweede tutorial in ons ‘Gratis online softwaretesttraining voor een live project’ serie. Als je hier nieuw bent, bekijk dan de eerste introductiehandleiding: End-to-end softwaretesttraining voor een live project.

Laten we nu ingaan op een gedetailleerde analyse van hoe een SRS-walkthrough plaatsvindt, wat we uit deze stap moeten identificeren, welke voorbereidende stappen we moeten nemen voordat we beginnen, met welke uitdagingen we te maken kunnen krijgen, enz. In een gedetailleerde manier.

c ++ praktische vragen en antwoorden pdf

SRS-document bekijken en testscenario

De ontwerpfase van SDLC:

De volgende fase van de SDLC is 'Design' - hier worden de functionele vereisten vertaald naar de technische details. Bij deze stap zijn de ontwikkelaars, ontwerp-, omgeving- en datateams betrokken. Het resultaat van deze stap is doorgaans een technisch ontwerpdocument TDD.

De input is het SRS-document voor zowel de creatie van de TDD als voor het QA-team om te gaan werken aan het QA-aspect van het project, namelijk het beoordelen van de SRS en het identificeren van het testdoel.

Wat je leert:

Wat is een SRS-recensie?

SRS is een document dat is gemaakt door het ontwikkelteam in samenwerking met Business Analisten en omgeving / datateams. Meestal wordt dit document, zodra het is afgerond, gedeeld met het QA-team via een vergadering waar een gedetailleerde walkthrough wordt geregeld.

Soms hebben we voor een reeds bestaande toepassing misschien geen formele vergadering nodig en iemand die ons door dit document leidt. Mogelijk beschikken we over de nodige informatie om dit zelf te doen.

SRS-beoordeling is niets anders dan het doornemen van het specificatiedocument voor functionele vereisten en proberen te begrijpen hoe de doeltoepassing eruit zal zien.

Het formele formaat en een voorbeeld zijn in het vorige artikel met jullie gedeeld. Het betekent niet noodzakelijk dat alle SRS'en precies op die manier zullen worden gedocumenteerd. Altijd, de vorm is ondergeschikt aan de inhoud ​

Sommige teams zullen er gewoon voor kiezen om een ​​lijst met opsommingstekens te schrijven, sommige teams zullen gebruiksscenario's opnemen, sommige teams zullen voorbeeldschermafbeeldingen opnemen (zoals het document dat we hadden) en sommige beschrijven alleen de details in alinea's.

Pre-Steps to Software Requirements Specification Review

Stap 1) Documenten ondergaan meerdere revisies, dus zorg ervoor dat we de juiste versie hebben van het document waarnaar wordt verwezen, de SRS.

Stap 2) Stel richtlijnen op over wat er aan het einde van de beoordeling van elk teamlid wordt verwacht. Met andere woorden, beslis welke resultaten van deze stap worden verwacht - de output van deze stap is meestal om de testscenario's te identificeren. Testscenario's zijn niets anders dan een regel van ‘wat te testen’ voor bepaalde functionaliteit.

Stap 3) Stel ook richtlijnen op over hoe dit resultaat moet worden gepresenteerd, ik bedoel, de sjabloon.

Stap 4) Bepaal of elk lid van het team aan het hele document gaat werken of het onder elkaar gaat verdelen. Het wordt sterk aanbevolen dat iedereen alles leest, want dat voorkomt kennisconcentratie bij bepaalde teamleden.

Maar in het geval van een enorm project, waarbij de SRS-documenten bijna 1000 pagina's beslaan, is de aanpak om de documentmodule verstandig op te splitsen en toe te wijzen aan individuele teamleden het meest praktisch.

Stap # 5) SRS-beoordeling helpt ook om beter te begrijpen of er specifieke vereisten zijn die vereist zijn voor het testen van de software.

Stap # 6) Als bijproduct wordt een lijst met zoekopdrachten geïdentificeerd waarbij bepaalde functionaliteit moeilijk te begrijpen is of als er meer informatie moet worden opgenomen in functionele vereisten of als er fouten zijn gemaakt in SRS.

Wat hebben we nodig om te beginnen?

  • De juiste versie van het SRS-document
  • Duidelijke instructies over wie waaraan gaat werken en hoeveel tijd ze hebben.
  • Een sjabloon om testscenario's te maken.
  • Overige informatie over wie contact moet opnemen in geval van een vraag of met wie moet worden gerapporteerd in geval van inconsistentie in de documentatie

Wie zou deze informatie verstrekken?

Teamleiders zijn over het algemeen verantwoordelijk voor het verstrekken van alle items die in de bovenstaande sectie worden vermeld. De input van teamleden is echter altijd belangrijk voor het welslagen van deze hele onderneming.

Teamleiders vragen vaak: wat voor soort input? Zou het niet beter zijn om een ​​bepaalde module toe te wijzen aan iemand die erin geïnteresseerd is dan aan een teamlid dat dat niet is? Zou het niet leuk zijn om de streefdatum te bepalen op basis van de mening van het team, dan hen een beslissing te geven? Ook voor het slagen van een project zijn sjablonen belangrijk.

Over het algemeen hebben sjablonen een hogere efficiëntie wanneer ze zijn afgestemd op het gemak en comfort van het specifieke team. Daarom moet worden opgemerkt dat teamleiders vooral teamleden zijn. Uw team aan boord krijgen bij de dagelijkse beslissingen is cruciaal voor het vlotte verloop van het project.

Is een sjabloon vereist voor testscenario's?

Waarom een ​​sjabloon voor testscenario's - is het niet voldoende als we alleen een lijst maken?

Het is zeker. Softwareprojecten zijn echter geen 'eenmansshows'. Ze betrekken teamwerk ​

Stel je een team van vier voor als elk van hen besluit om elk een module van de specificatie van softwarevereisten te herzien. Teamlid A heeft een lijst op een vel papier gemaakt. Teamlid 2 gebruikte een Excel-sheet. Teamlid 3 gebruikte een notitieblok. Teamlid 4 gebruikte een word-doc. Hoe consolideren we aan het eind van de dag al het werk dat voor het project is gedaan?

En hoe kunnen we beslissen welke de norm is en hoe kunnen we zeggen wat juist is en wat niet als we om te beginnen de regels niet hebben opgesteld?

Dat is wat sjabloon is: Een set richtlijnen en een afgesproken format voor uniformiteit en overeenstemming voor het hele team.

Hoe maak je een sjabloon voor QA-testscenario's?

Sjablonen hoeft niet ingewikkeld of inflexibel te zijn.

Het enige dat ze nodig hebben, is een efficiënt mechanisme om een ​​nuttig testartefact te creëren. Iets eenvoudigs zoals hieronder:

sjabloon voor testscenario

De koptekst van deze sjabloon bevat de ruimte die nodig is om basisinformatie over het project, het huidige document en het document waarnaar wordt verwezen vast te leggen.

Met de onderstaande tabel kunnen we testscenario's maken. De meegeleverde kolommen zijn:

Kolom # 1) Testscenario-ID
Elke entiteit in ons testproces moet uniek identificeerbaar zijn. Aan elk testscenario moet dus een ID worden toegewezen. De regels die moeten worden gevolgd bij het toewijzen van deze ID, moeten worden gedefinieerd.

Omwille van dit artikel gaan we de naamgevingsconventie volgen als TS (prefix dat staat voor Test Scenario) gevolgd door ‘_’, modulenaam ME (Mijn Info-module van het Orange HRM-project) gevolgd door ‘_’ en vervolgens de subsectie ( Bijvoorbeeld, ME voor My Info Module, P. voor foto enzovoort) gevolgd door een serienummer. Een voorbeeld zou zijn: 'TS_MI_MIM_01'.

Kolom # 2) Vereiste
Het helpt dat wanneer we een testscenario maken, we het terug moeten kunnen koppelen aan het gedeelte van het SRS-document waaruit we het hebben gekozen. Als de vereisten ID's hebben, kunnen we die gebruiken. Zo niet, sectienummers of zelfs paginanummers van het SRS-document van waaruit we een testbare vereiste hebben geïdentificeerd, volstaan.

Kolom # 3) Beschrijving testscenario
Een oneliner waarin staat ‘wat te testen’. We noemen het ook wel het testdoel.

Kolom # 4) Belang
Dit is om een ​​idee te geven hoe belangrijk bepaalde functionaliteit is voor de AUT. Waarden als hoog, midden en laag kunnen aan dit veld worden toegewezen. Je kunt ook een puntensysteem kiezen, zoals 1-5, waarbij 5 het belangrijkst is en 1 minder belangrijk. Wat de waarde van dit veld ook mag zijn, het moet vooraf worden beslist.

Kolom # 5) Aantal testgevallen
Een ruwe schatting van hoeveel individuele testcases we uiteindelijk dat ene testscenario zouden kunnen schrijven. Bijvoorbeeld, Om de login te testen, nemen we de volgende situaties op: Correcte gebruikersnaam en wachtwoord. Juiste gebruikersnaam en verkeerd wachtwoord. Correct wachtwoord en verkeerde gebruikersnaam. Het valideren van de inlogfunctionaliteit resulteert dus in 3 testgevallen.

Notitie: U kunt deze sjabloon naar eigen inzicht uitbreiden of de velden verwijderen.

Bijvoorbeeld , kunt u 'Beoordeeld door' in de koptekst toevoegen of de aanmaakdatum verwijderen, enz. Ook kunt u in de tabel een veld 'Gemaakt door' opnemen om de tester aan te duiden die verantwoordelijk is voor een bepaald testscenario of het 'Nee. van Testcases ”. De keuze is aan jou. Kies wat het beste werkt voor het hele team.

Laten we nu ons Orange HRM SRS-document bekijken en de testscenario's maken

Pro-tip: bekijk de inhoudsopgave in het SRS-voorbeeld dat we in de eerste tutorials hebben gegeven om een ​​goed idee te krijgen van hoe een document zal stromen en hoeveel werk het kan kosten.

Sectie 1 is het doel van het document. Geen toetsbare vereisten daar.

Sectie 2.1 : Projectoverzicht - Publiek - ook daar geen toetsbare vereisten.

Paragraaf 2.2 : Hardware en hosting - In dit gedeelte wordt besproken hoe de Orange HRM-site wordt gehost. Is deze informatie belangrijk voor ons testers? Het antwoord is Ja en Nee. Ja, want als we testen, hebben we een omgeving nodig die lijkt op de real-time omgeving.

Dit geeft ons een idee van hoe het moet zijn. Nee, want het is geen testbare vereiste, een soort voorwaarde voor het testen.

Sectie 3: Er is hier een inlogscherm en de details van het type account dat we nodig hebben om de site te betreden. Dit is een toetsbare vereiste. Het moet dus een onderdeel zijn van onze testscenario's.

Zie het testscenario-document waar testscenario's voor een paar secties van de SRS zijn toegevoegd. Voeg om te oefenen de rest van de scenario's op dezelfde manier toe. Ik ga echter meteen naar sectie 4 van het document.

Sectie 4: Esthetische / HTML-vereisten en richtlijnen - In deze sectie wordt het beste uitgelegd hoe sommige vereisten misschien niet logisch waren voor het testteam op het moment van de SRS-beoordeling, maar het team zou ze toch moeten noteren als testbare vereisten.

Hoe we ze kunnen testen en of we specifieke instellingen / hulp van een team nodig hebben om het te valideren, zijn details die we op dit moment misschien niet weten. Maar ze deel uitmaken van onze testscope is de eerste stap om ervoor te zorgen dat we ze niet missen.

Voorbeeldtestscenario's voor OrangeHRM-toepassing​ (klik om afbeelding te vergroten)

sjabloon testscenario

​ Raadpleeg en download het document Testscenario's voor meer informatie.

Enkele belangrijke opmerkingen met betrekking tot SRS-beoordeling

# 1) Er mag geen informatie onbedekt blijven.
#twee) Voer een haalbaarheidsanalyse uit om te zien of een bepaalde eis correct is of niet en ook of deze kan worden getest of niet.
# 3) Tenzij er een aparte prestatie / beveiliging of enige andere vorm van testteams bestaat, is het onze taak om ervoor te zorgen dat met alle niet-functionele vereisten rekening moet worden gehouden.
# 4) Niet alle informatie is gericht op de testers, dus het is belangrijk om te weten wat u wel en niet moet opmerken.
# 5) Het belang en nee. van testgevallen voor een testscenario hoeft niet nauwkeurig te zijn en kan worden ingevuld met een geschatte waarde of kan leeg worden gelaten.

Samenvattend resulteert SRS-beoordeling in:

  • Lijst met testscenario's
  • Beoordelingsresultaten - Documentatie- / vereiste fouten die zijn gevonden door het SRS-document statisch te doorlopen / verifiëren
  • Een lijst met vragen voor een beter begrip, in het geval van een
  • Het voorlopige idee van hoe de testomgeving eruit zou moeten zien
  • Test scope identificatie en een globaal idee van hoeveel testcases we zouden kunnen hebben, dus hoeveel tijd we nodig hebben voor documentatie en uiteindelijk uitvoering.

Belangrijke aandachtspunten:

# 1) Testscenario's zijn geen externe deliverables (niet gedeeld met Business Analysts of Dev-teams), maar zijn belangrijk voor interne QA-consumptie. Ze zijn onze eerste stap op weg naar een 100% testdekkingsdoelstelling. Zodra testscenario's zijn voltooid, ondergaan ze een peer review en zodra dat is gebeurd, worden ze allemaal geconsolideerd.

Bekijk het artikel voor meer informatie over hoe QA-documenten worden beoordeeld: Testdocumentatiebeoordelingen uitvoeren in 6 eenvoudige stappen.

#twee) We zouden een testmanagementtool kunnen gebruiken zoals HP ALM of qTest om de testscenario's te maken. Het maken van testscenario's in realtime is echter een handmatige activiteit. Naar mijn mening is het handmatig handiger. Aangezien het stap 1 is, hoeven we de grote kanonnen nog niet tevoorschijn te halen. Eenvoudige Excel-sheets zijn de beste manier om dit aan te pakken.

De volgende stap naar deze serie is dat - we werken aan het maken van testcases en komen verder in de testontwerpfase. Voordien zullen we ook ingaan op - Welke testplanning is?Waar past het in het hele QA-project? Werk zoals altijd met ons samen voor de beste resultaten.

QA-training dag 3: Hoe u vanuit het niets een SRS-document schrijft.

Houd alstublieft uw vragen en opmerkingen binnen. We waarderen uw lezers enorm!

Aanbevolen literatuur

^