Bug Tracking proces

From Joomla! Documentation

This page is a translated version of the page Bug Tracking Process and the translation is 100% complete.
Other languages:
Deutsch • ‎English • ‎Nederlands • ‎español • ‎français • ‎português • ‎svenska • ‎русский • ‎বাংলা • ‎日本語

Dit artikel laat zien hoe het huidig bug tracking proces in Joomla! verloopt. Vanaf het moment dat een bug gerapporteerd wordt tot het moment dat deze gesloten wordt.

Bugs in Joomla! worden bijgehouden in de Joomla! Issue Tracker. Hier worden alle issues bijgehouden van de Joomla versies die ondersteund worden. De aanbevolen versie is J3.10.

Hoe u kunt helpen

U hoeft geen lid te zijn van de Joomla! Bug Squad om te helpen met het oplossen van bugs in Joomla. Iedereen kan bugs melden, patches testen of patches indienen. Als u wilt helpen met het oplossen van bugs, ga dan naar de Tracker. U kunt helpen met het oplossen van openstaande problemen zoals hieronder is aangegeven. U kunt patches maken en indienen voor bevestigde problemen of u kunt helpen door problemen in afwachting (pending) te testen. Om vast te leggen wat u heeft gedaan logt u in met een Github account en voegt u een commentaar toe. U zult versteld staan hoeveel verschil u kunt maken en hoe goed het voelt om bij te dragen aan het Joomla! project. Als u vragen heeft of u heeft interesse om lid te worden van de JBS, neem dan contact op met De Bug Squad Coördinatoren.

Pre-releases testen

Voor een stabiele versie van Joomla wordt vrijgegeven moet de update getest worden. Dit is een eenvoudig proces:

  1. Installeer de Staging release van Joomla https://github.com/joomla/joomla-cms in een map of in een lokale omgeving (u kunt een kopie van een website gebruiken, maar test nooit op een live website').
  2. Navigeer naar de Opties van het Joomla! Update component en stel de 'Update server' in op 'Test'. Componenten Joomla Update
  3. Wanneer een pre-release van Joomla klaar is om getest te worden logt u in op uw testsite en installeert u de update. Test vervolgens of de site werkt zoals verwacht. Rapporteer alle fouten of bugs die u vindt op de Joomla! Issue Tracker

Problemen melden

ReportingIssues.png

Het proces wordt normaal op een van de volgende twee manieren gestart: de bug wordt toegevoegd aan de respectievelijke tracker of een gebruiker meld de bug op het Joomla! Bug Forum voor de betreffende onderhoudsrelease.


Problemen melden op het forum

JBS leden scannen het forum om te bepalen wanneer problemen in de tracker moeten worden geplaatst. Als het probleem gereproduceerd kan worden, duidelijk een bug is en er een stap-voor-stap beschrijving is van hoe het probleem gereproduceerd kan worden, kan het opgenomen worden in de tracker met de status Confirmed (bevestigd). Als het niet zo duidelijk is kan het opgenomen worden met de status Open zodat andere JBS leden weten dat er meer onderzoek nodig is.

Problemen rechtstreeks in de tracker melden

Wanneer een probleem aan de tracker wordt toegevoegd hangt de status af van de situatie;

  1. New (nieuw)
  2. Confirmed (bevestigd)
  3. Pending (in afwachting)

Wanneer eer meer onderzoek nodig is naar een probleem, dan moet deze op New gezet worden. Als het probleem (1) een bug is en (2) gereproduceerd kan worden en (3) er goede testinstructies zijn, dan kan de status op Confirmed gezet worden. Als het probleem aan deze 3 criteria voldoet en er is een goede patch bijgevoegd, dan moet de status op Pending gezet worden. Zie hieronder voor meer informatie over de status codeds.

Prioriteit van probleem

Waarom de meeste problemen prioriteit 3 hebben, of Medium. De problemen worden geprioriteerd op basis van de volgende kenmerken:

Kritiek (1): Het werkt helemaal niet. Belangrijke delen van de code werken niet waardoor belangrijke handelingen niet mogelijk zijn. Voorbeelden hiervan zijn login, installatie, extensie installatie, java script foutmeldingen die voorkomen dat u kunt opslaan of soortgelijke acties kunt uitvoeren etc. Dit omvat ook fatale PHP fouten en belangrijke veiligheidsproblemen in een pre-release (veiligheidsproblemen voor een stabiele release moeten niet gemeld worden in de tracker maar aan het security team security@joomla.org).

Urgent (2): Delen van de code belemmeren de werking op ernstige wijze of veroorzaken een groot verlies in de functies. Voorbeelden zijn PHP kennisgevingen en waarschuwingen en gemelde JavaScript fouten. Grote problemen voorkomen over het algemeen ook dat de releasecyclus van Beta naar Release Candidate (RC) of van Release Candidate naar General Availability (GA) gaat.

Medium (3): Problemen die functies belemmeren, maar waarbij de applicatie nog wel werkbaar is. Voorbeelden zijn parameters die niet werken zoals bedoeld, taalbestanden die niet worden geladen etc.

Laag (4): Gering functie verliest en over het algemeen hinderlijk gedrag. Bevat mogelijk minder vaak voorkomende platform- en browserspecifieke problemen die weliswaar technisch aanzienlijk kunnen zijn op die omgeving, maar een uitzondering vormen. Het omvat ook het ontbreken van vertaalstrings.

Zeer laag (5): Cosmetische problemen, verkeerd gespelde woorden, grafische fout uitgelijnde objecten, minder vaak voorkomende problemen met parameters, etc.

Problemen oplossen

De bug squad zorgt voor de Joomla releases. Dat betekent bijvoorbeeld de 3.4, 3.5 etc releases klaar maken door de problemen die ontdekt worden op te lossen. Hierdoor wordt de release steeds stabieler en worden problemen opgelost. Tegelijkertijd is het van het grootste belang dat er niets kapot gaat dat werkt. Dit heet softwareregressie en dat wilt u in dit stadium niet. Er zijn een aantal algemene statussen in de tracker, namelijk: new, confirmed, pending, ready to commit.

  • New betekent dat het gemeld is, maar er nog niet vast gesteld is of het een echte bug is of niet. Veel openstaande problemen zijn eigenlijk geen bugs. Als het probleem in een van de onderstaande categorieën past, zal de status aangepast worden zoals aangegeven en wordt de bug gesloten.
    • Kan niet gereproduceerd worden. We hebben hetzelfde geprobeerd als de melder aangaf, maar de software lijkt correct te werken. (In veel gevallen is er meer informatie nodig om de bug te reproduceren. Zie Benodigde informatie hier onder.) De status wordt gewijzigd naar Unconfirmed Report (onbevestigde melding).
    • Het is al eerder gemeld onder een ander nummer. De status wordt gewijzigd naar Duplicate report (dubbele melding) en het eerdere nummer wordt toegevoegd op het tabblad duplicates.
    • Het is een bekende beperking van de software. Status wordt gewijzigd in Known issue (bekend probleem).
    • Het is een functieverzoek, een fout gemaakt door de gebruiker of het is niet de manier waarop de software hoort te werken. Status wordt gewijzigd in Expected Behaviour (verwachte gedrag).
    • Het is een bug met een extensie of een ander extern programma, of een server probleem dat niet geadresseerd zal worden. Status wordt gewijzigd in Closed (gesloten) en de reden wordt in een commentaar geplaatst.
  • Information Required (Informatie nodig) wordt gebruik als er meer informatie nodig is van de persoon die het probleem heeft gemeld om te bepalen wat er met het probleem moet gebeuren. Bijvoorbeeld wanneer er vragen zijn over hoe het probleem gereproduceerd kan worden of er zijn andere vragen over het probleem. Wanneer de informatie die nodig is wordt ontvangen kan het verwerken van het probleem verder afgehandeld worden. Wanneer er binnen 2 weken geen extra informatie wordt verstrekt zal de status op Unable to confirm (Niet mogelijk te bevestigen) worden gezet (of een van de andere afgesloten statussen die van toepassing is).
  • Needs Review (Moet bekeken worden) wordt gebruikt wanneer een PLT lid of CMS onderhouder nodig is voor een review of beslissing. Dit verschilt van Informatie nodig wat betekend dat meer informatie nodig is van de melder.
  • Confirmed (Bevestigd) betekend dat JBS heeft bevestigd dat het gemelde probleem een bug is in Joomla! die opgelost moet worden. Dan probeert de JBS het op te lossen of overlegt met het development team over de oplossing. Op dit punt moeten er duidelijke stapsgewijze testinstructies zijn die aangeven hoe het probleem moet worden gereproduceerd.
  • Pending (In afwachting) betekend dat een patch (oplossing) is ingediend. Ieder probleem dat in afwachting is moet instructies hebben die de tester vertelt hoe het probleem gereproduceerd kan worden en dat de patch het probleem moet oplossen.
  • Ready to commit (klaar om toegepast te worden) betekent (over het algemeen) dat er 2 personen met succes de patch hebben getest en dat het correct werkt na toepassing van de patch. Het kan zijn dat voor meer complexe problemen of problemen met een grotere impact we meer dan twee testers nodig hebben en dat er op meerdere platformen getest moet worden. Voor eenvoudige problemen, zoals het oplossen van een typefout in een taalstring is een tester voldoende.
  • Fixed in Code Base (opgelost in codebasis) betekend dat, na het bekijken van de code, de JBS commit coördinatoren hebben besloten dat de patch goed is en dat de wijzigingen in de Joomla! codebasis kunnen worden opgenomen. Vanaf dan is het onderdeel van de volgende Joomla! onderhoudsrelease.

De Easy Test (eenvoudige test) markering is geen speciale status, maar meer een label om aan te geven dat het probleem eenvoudig te testen is.


Het onderstaande stroomschema laat zien hoe het proces voor het oplossen van bugs er visueel uit ziet.

ResolvingIssues.png