Menu

Wat te doen als er niet genoeg tijd is om te testen?

what do when there isn t enough time test

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Realiseert u zich halverwege uw testcyclus vaak dat u niet genoeg tijd heeft om te testen? Om te beginnen had je het allemaal onder controle, maar al snel bereik je het noodplan: 'Wat te doen als er niet genoeg tijd is om te testen?' sectie.

Ik ben er ook geweest en het is niet leuk.​

Ik heb hier lang en hard over nagedacht. Hoe kan iets dat zo goed begon, zo slecht, zo snel aflopen. En hier is mijn analyse.

​ Klik hier voor een complete serie testplannen

Wat je leert:

Waar is mijn testtijd gebleven?

Niet genoeg tijd om te testen

beste sites om anime online gratis te bekijken

Ten eerste: waarom gebeurt dit?Er zijn veel redenen - waarvan sommige zijn:

# 1) Onjuiste schatting ​

Als je met een onnauwkeurige verwachting bent begonnen, zullen de dingen zeker mislukken. Bij een goede testschatting moet rekening worden gehouden met:

  • Tijd voor voorbereidende taken - We hebben het over taken als:
    • Een regressiesuite identificeren en samenstellen
    • Testgegevens maken
    • Tijd om de testgereedheid te bepalen (bijv.: Rook- / gezondheidstest), enz.
  • Onderhoud van de testcase : Testcases zijn middelen voor langdurig gebruik. Ze zullen tijdens de uitvoering zeker kleine updates ondergaan. Het wordt aanbevolen om voor nieuwe producten tot 30% van uw testuitvoeringstijd te besteden aan deze kleine onderhoudstaken. Alle teams en projecten hebben misschien geen 30% nodig, maar besteed wel wat tijd en moeite voor deze taak.
  • Hierop / Verkennende toetsing - Het aantal scripttests is een belangrijke noemer voor schattingsaantallen. Geen enkel testteam ter wereld zal echter ontkennen dat u uw software heeft verkend, zelfs als het model overwegend scripted is.
  • Rapportage / communicatie - Dit omvat triage / stand up meetings, het updaten van werkmanagementtools etc.
  • Onvoorziene factor: Standaarden bevelen een buffer van 25-30% aan ten opzichte van uw oorspronkelijke schattingen. Maar teams kunnen het zelden betalen. Laat zelfs dan, indien mogelijk, een beetje ademruimte over.
  • Team en zijn mogelijkheden: Als je een nieuw team hebt of als ze een tool voor het eerst gebruiken, moet je misschien wat tijd vrijmaken voor training. Pas uw schattingen aan op basis van uw team waarmee u samenwerkt.

Aanbevolen om te lezen​ Bekijk dit voor meer informatie over het succes en de methoden van testschattingen

# 2) Onstabiele builds en andere technische problemen:

  • Mislukt rook- / gezondheidstest : Wanneer de basistests op de AUT mislukken na implementatie in de QA-omgeving, kan het QA-team vrijwel niets doen om de test uit te voeren. Het is waar dat we aan andere taken kunnen werken terwijl dit gebeurt, maar het vult het nog steeds niet testcyclus tijd. Dit levert dus een belangrijke bijdrage aan de verspilde tijd.
  • Testgegevens niet beschikbaar : Productieachtige data is een must voor elk testproject. Dit niet op tijd in de QA-omgeving krijgen is ook een andere blokkerende factor. Soms kunnen testers dit omzeilen door het maken en beheren van hun eigen testgegevens , maar het is tijdrovend en hoeft niet altijd even goed te zijn.
  • Milieukwesties - Het bouwen van mislukte implementaties, de server krijgt steeds een time-out, veel meer van dergelijke problemen verslinden uw testcyclus. Dit vloeit waarschijnlijk voort uit het feit dat sommige bedrijven (niet alle) het belang van een goede, live-achtige omgeving voor effectieve QA ondermijnen. Ze proberen vaak servers met een lage capaciteit en make-do-instellingen te verwijderen. Dit is echt een tijdelijke oplossing en doet niemand goed. Het kan hen zelfs de kwaliteit van het testen en het verlies van waardevolle testtijd kosten.

# 3) Gebrek aan overeenstemming tussen alle betrokken partijen:

Dit kan een zeldzaam probleem zijn bij teams die Agile of Veilig vanwege de nauwe kringen waarin ze werken, maar veel teams hebben nog steeds last van onenigheid of miscommunicatie over wanneer Dev, Ops en QA de resultaten van elkaar moeten ontvangen. Vandaar vertragingen.

Controleer dit om de subtiliteiten van communicatie te begrijpen ​ Hoe Business, Development en QA kunnen samenwerken om het project te voltooien

Nu we de problemen kennen, volgen hier enkele manieren om het probleem op te lossen.

Hoe kunnen testers genoeg tijd krijgen om te testen?

# 1) Schat nauwkeurig. Bij twijfel overschat met een redelijke marge, maar niet onderschat. Vergeet niet om schattingen aan te passen op basis van uw team, tools en processen. Als je klaar bent, zoek dan naar een officiële afmelding, zodat iedereen op de hoogte is en op de hoogte blijft.

#twee) Houd rekening met historische gegevens - De Test Management tool is je beste vriend ​

  • Hoe lang hebben de testcycli van eerdere releases geduurd?
  • Wat voor problemen veroorzaakten onderbrekingen in de vorige testcyclus?
  • Hoeveel runs hebben de meeste testcases geduurd voordat ze slaagden?
  • Welke gebreken zijn er gemeld?
  • Door welke defecten werd het testen onderbroken?

# 3) Stel deze vragen en plan dienovereenkomstig in korte tijd:

  • Ontdek Belangrijke functionaliteit is uw project?
  • High-risk module van het project ontdekken?
  • Welke functionaliteit is het meest zichtbaar voor de gebruiker?
  • Welke functionaliteit heeft de grootste impact op de veiligheid?
  • Welke functionaliteit heeft de grootste financiële impact op gebruikers?
  • Welke aspecten van de applicatie zijn het belangrijkst voor de klant?
  • Welke delen van de code zijn het meest complex en dus het meest onderhevig aan fouten?
  • Welke delen van de applicatie zijn ontwikkeld in spoed- of paniekmodus?
  • Wat zijn volgens de ontwikkelaars de meest risicovolle aspecten van de applicatie?
  • Wat voor problemen zouden de ergste publiciteit veroorzaken?
  • Welke soorten problemen zouden de meeste klachten van de klantenservice veroorzaken?
  • Welke soorten tests kunnen gemakkelijk meerdere functionaliteiten omvatten?

Met het oog op deze punten kunt u het risico dat een project wordt vrijgegeven aanzienlijk verkleinen in minder tijd.

# 4) Gebruik een tool voor testbeheer. Dit zal de hoeveelheid voorbereiding, rapportage en onderhoudstijd en inspanning aanzienlijk verminderen.

​ Voor de lijst met de meest populaire keuze voor testbeheertools ​ kijk hier ​

# 5) Er is niet veel dat we kunnen doen aan onjuiste builds / technische problemen, maar het enige dat kan helpen, is kijken naar de testresultaten van de Unit. Dit geeft ons een idee of de build een succes was of niet en voor wat voor soort tests het mislukte - dus we vinden het wiel niet opnieuw uit.

hoe open je een eps-bestand

Als jouw Test Management Tool ondersteunt CI-integratie , heb je die informatie zonder poespas beschikbaar, zodat je de stabiliteit van de applicatie beter begrijpt.

# 6) Meet uw productiviteit en voortgang vaak ​Laat statusrapporten niet alleen een resultaat zijn ten behoeve van de externe teams. Zorg ervoor dat u uw dagelijkse doelen en uw vermogen om ze te bereiken nauwlettend in de gaten houdt.

Zorg er ook voor dat u niet in het klassieke raadsel van ‘Velocity vs. Quality’ komt. Omdat, wanneer u bijvoorbeeld 50 bugs per dag rapporteert, het lijkt alsof u superproductief bent. Maar als de meesten van hen terugkomen als ongeldige, heb je een probleem.

Dus monitor, monitor en monitor een beetje meer :)

Gevolgtrekking:

Eindelijk, ondanks alle voorzorgsmaatregelen en maatregelen, als u nog steeds merkt dat u door de tijd gekraakt bent, hulp vragen ​

De meeste teams zijn bereid deel te nemen aan een warroom-sessie om de zaken weer op de rails te krijgen.

Over de auteur: Deze handige testtips worden verstrekt door STH-teamlid Swati S.

Wat zijn nu uw trucs om op tijd te blijven en een kwaliteitstestservice te leveren? Welke punten in het bovenstaande artikel resoneren ook met jou?

We stellen uw feedback op prijs en koesteren uw lezerspubliek. Bedankt voor het lezen!

​ Bezoek hier voor een complete serie testplannen

Aanbevolen literatuur

^