Home Blog Trends In welke gevallen hebben bedrijven QA Testing services nodig? Tips van een Lead QA Engineer
blog

In welke gevallen hebben bedrijven QA Testing services nodig? Tips van een Lead QA Engineer

Posted Trends

Bedrijven die op zoek zijn naar professionele QA Engineers hebben vaak moeite om zich aan hun budget en deadlines te houden. Afzien van software testing kan je echter later in de ontwikkelingscyclus veel geld kosten, aangezien kwetsbaarheden in de software niet in een vroeg stadium worden opgelost. Hoe later dit soort problemen worden gevonden, hoe meer middelen en tijd het kost om ze op te lossen.

Om meer inzicht te krijgen in de rol van een QA Engineer in de verschillende stadia van het proces van software development hebben we gesproken met een Lead QA Engineer van Daxx en gevraagd op welke momenten bedrijven precies professionele software testing services nodig hebben.


Heb je QA Engineers nodig als alles in orde lijkt te zijn?

Deze vraag heb je jezelf waarschijnlijk al wel eens gesteld met het uitbrengen van de eerste versie van software, bij grote wijzigingen of bij het lezen van een rapport over fouten en defecten van een klant.

In het onderstaande voorbeeld van een leningaanvraag (REST API-backend en web UI-frontend) hebben we beschreven tijdens welke fase bedrijven QA Engineers zouden moeten inzetten en waarom. 

Fase 1. De eisen/taken zijn gedefinieerd

In deze fase moet je weten hoeveel taken tijdens elke iteratie kunnen worden uitgevoerd. Zodra alle taken zijn beschreven maken developers een schatting en stellen ze het optimale aantal taken vast dat moet worden ontwikkeld.

Omdat deze schattingen vrij ruw zijn, kun je taken toevoegen aan of verwijderen uit een iteratie. Meestal wordt de capaciteit van een team duidelijk na 2 tot 4 iteraties. 

Als het slechts een opbouwfase betreft, de architectuur bij het opzetten van een nieuw project, het configureren van frameworks, environments of systemen voor continue integratie, dan heb je geen QA Engineers nodig, tenzij het een verplichting is om continue integratie op te zetten. 

Fase 2. Project development is gestart

In deze fase worden gebruikersrollen en toegangsrechten gedefinieerd (in ons voorbeeld lener, uitlener en systeembeheerder) terwijl het UI-team first page markups levert (inloggen/registreren) zonder verzoeken te verzenden en serverreacties te verwerken. 

BELANGRIJK: Start een project altijd met het definiëren van gebruikersrollen. Beginnen met een systeembeheerder die alle rechten heeft en vervolgens rollen toevoegen met minder verantwoordelijkheden is vragen om technische problemen achteraf.

Op dit moment heb je een QA Engineer nodig om te controleren of:

  • Rollen en toegangsrechten goed zijn gedefinieerd (dit kan alleen met een code-review, dus bijbehorende expertise is nodig)
  • De mockups worden weergegeven in de browsers
  • Het ontwerp adaptief/responsief is en niet gecorrumpeerd raakt op andere apparaten

Er dient een nauwkeurige ontwikkelingsstroom (functievertakking) te worden opgezet om het aantal problemen te verminderen. 

Fase 3. Het plannen van de eerste flows

In ons geval omvat deze fase het plannen van een registratieformulier met een e-mailadres, gebruikersrol (lener/uitlener) en een volledige naam. Je formulier zou de volgende regels moeten aanhouden:

  • De volledige naam moet minimaal twee woorden bevatten
  • Het e-mailadres moet een punt bevatten na het apestaartje, en kan alleen alfanumerieke tekens bevatten
  • Een van de rollen moet worden geselecteerd (de rol van lener is standaard)

Op het eerste gezicht lijkt alles in orde. Een QA Engineer kan je echter vragen naar een aantal dingen die nog ontbreken, namelijk:

  • Mag een volledige naam niet-Latijnse tekens en apostrofs bevatten?
  • Wat is het maximum aantal toegestane tekens voor een volledige naam en een e-mailadres?
  • Moet je e-mailadressen van een topdomein accepteren (bijv. [email protected]), alleen omdat het technisch mogelijk is?
  • Moeten we escaping inbouwen, bijvoorbeeld om XSS te kunnen vermijden?

Op dit moment heb je niet per se QA Engineers nodig, omdat slechts zijdelingse betrokkenheid vereist is.

Fase 4. Eerste release

Als de eerste flows (registratie, login, algemene voorwaarden) zijn afgerond en de capaciteit nauwkeurig kan worden ingeschat, kun je je voorbereiden op de eerste release.

Als je product niet veel functionaliteit heeft, kan het door je developmentteam worden getest. Je zult na de release nog enkele fouten tegenkomen, maar in het algemeen zal alles naar behoren werken.

Wat gebeurt er als je QA Engineers betrekt?

Gewoonlijk zullen QA Engineers de teststrategie en het testplan definiëren en zorgen voor een succesvolle productlancering. Als de QA Engineers als vanaf het begin betrokken waren, is hun rol in deze fase kleiner.

Om mogelijke defecten te verminderen zal een QA Engineer regressietesten plannen, die alle functionaliteit dekken. Dit proces is behoorlijk tijdrovend, maar het helpt je de releases stabiel te maken en een product te leveren met een minimum aantal defecten. De defecten die niet worden verholpen worden gemarkeerd als 'bekende problemen', zodat je klanten weten dat je op de hoogte bent en dat er aan een oplossing wordt gewerkt. 

Tijdens regressietests zullen telkens een aantal flows worden herhaald. Wat de kernfunctionaliteit betreft is er slechts een kleine kans dat deze nu wijzigingen vereist. Toch is het goed om geautomatiseerde tests uit te voeren om er zeker van te zijn dat er geen fouten in de kern zijn geslopen door bugfixes die zijn uitgebracht voor het oplossen van eerdere fouten.

Release candidates testen en flows samenbrengen

Release candidates testen en flows samenbrengen

Verwacht je meteen een groot aantal gebruikers?

Zo ja, dan is het essentieel om performance testing in te stellen op basis van veelvoorkomende gebruikersscenario's. Op deze manier kun je de developmentomgeving, de piekbelasting en het aantal gebruikers vergelijken die wat je met de productie verwacht. 

Fase 5. Continue ontwikkeling en ondersteuning

Je krijgt een verzoek om een ​​CRM te bouwen voor leners. Het is voor financiële organisaties vrij moeilijk om toezeggingen bij te houden. Ook moet het gebruikersmodel worden aangepast (adressen toevoegen, koppelen aan een andere financiële organisatie).

Tijdens deze fase moet je ervoor zorgen dat eerder ontwikkelde functionaliteit blijft werken en geautomatiseerde tests bouwen om de werking van alle onderdelen te controleren. Met automatiseringstests duurt het maximaal 30 minuten om te controleren of alles naar behoren werkt en om eventuele gebreken tijdens de ontwikkeling van het CRM te detecteren. Op deze manier bent je snel op de hoogte van de defecten en kun je de situatie onder controle houden, terwijl je functies die tijdrovend zijn uitstelt. 

Als je applicatie zich in de ondersteuningsfase bevindt, zal een goede reeks geautomatiseerde tests de levering van releases met 1-2 uur verkorten (inclusief het uitvoeren van geautomatiseerde tests, het analyseren van het rapport, handmatige smoke tests, branching en updates).

Mis de beste artikelen niet!
Blog Verteren Abonneren

Blog Verteren Abonneren

Hoe kun je productkwaliteit kostenefficiënt testen?

Er is een groot aantal actieve projecten maar afhankelijk van de projectspecificaties heb je mogelijk niet alle QA-middelen nodig. Daarom heeft Daxx besloten om Quality Control as a Service en Software Testing as a Service te introduceren, waarmee je je testpakket op maat kiest en waar nodig QA Engineers kunt inschakelen.

Als je zelf QA Engineers hebt, kun je de capaciteit van je team uitbreiden door:

  • Automatiseringstesten installeren (inclusief continue integratie, systeemconfiguratie, en ondersteuning en teamtraining zonder nieuwe omgeving)
  • Prestatietests installeren (inclusief teamtraining, continue integratie en systeemconfiguratie)
  • Testen versnellen (regressietests)
  • Development flow installeren (features en release candidates afzonderlijk testen)

Als je geen QA Engineers in je team hebt, kun je onze service gebruiken om:

  • Release candidates te testen (regressietesten uitvoeren voor uitbrengen software)
  • Documentatie testen (ontbrekende punten en knelpunten vinden)
  • Functionaliteit testen (nieuwe functionaliteit testen)
  • Regressietests en smoke tests (zorgen dat zowel nieuwe als eerdere functionaliteit goed werkt)
  • Automatiseringstests voor “happy-paths” (zorgen dat bestaande functionaliteit niet wordt verbroken), configuratie continue integratiesysteem en rapportage inbegrepen
  • Correcte development stream installeren (functionaliteit afzonderlijke testen)
  • Prestatietests (zorgen dat de applicatie de verwachte belasting aankan), configuratie continue integratiesysteem en rapportage inbegrepen.

Nawoord

De gouden regel blijft van kracht: hoe eerder defecten worden gevonden, hoe goedkoper het is om ze te repareren. Deze tips helpen je bij het bepalen van de rol van een QA Engineer tijdens elke fase van je project en bij noodzakelijke procedures voor kwaliteitsborging. Onze kwaliteitscontrole en software testing services stellen je in staat binnen je budget te blijven en je testcapaciteit uit te breiden op momenten dat dat nodig is. 

name

Yustyna Velykholova

Content Marketing Manager

Yustyna Velykholova is an experienced Content Marketing Manager at Daxx. She produces insightful research-based content on various IT topics, including data science, blockchain, IoT, machine learning, virtual reality, information security, to name a few. 

Dit bericht delen